Max allocation on invalid string input

[Thomasvdam]

First of all thanks for all the work on this library, it's been incredibly useful to us!

We ran into an issue where AssemblyScript complained that we were allocating too much memory (Allocation too large in ~lib/rt/itcms.ts(261:31)) and after some digging we found that the error originated in the string parsing when a value was incorrectly typed as a string but the received JSON value was a single digit number.

While the fault ultimately was with us not typing the expected JSON correctly we think it might be useful to have the string deserialiser do some sanity checks on the input and abort with a more helpful error message.

If this is something you'd be interested in adding to the library we can work on it and submit a PR. :)

Reproduction scenario in a test file:

@json
class IncorrectlyTyped {
  value: string;
}
describe("Should not allocate max memory on invalid input", () => {
  expect(JSON.stringify(JSON.parse<IncorrectlyTyped>('{"value":0}'))).toBe(
    JSON.stringify(<IncorrectlyTyped>{ value: "" }),
  );
});

Outputs:

abort: Allocation too large in ~lib/rt/itcms.ts(261:31)
Error: failed to run main module `build/test.spec.wasm`

Caused by:
    0: failed to invoke command default
    1: error while executing at wasm backtrace:
           0: 0x4b7a - <unknown>!<wasm function 387>
           1: 0x1839 - <unknown>!<wasm function 59>
           2: 0xdd9b - <unknown>!<wasm function 513>
           3: 0xe1a9 - <unknown>!<wasm function 517>
           4: 0xe4e6 - <unknown>!<wasm function 518>
           5: 0x161bc - <unknown>!<wasm function 606>
           6: 0x16748 - <unknown>!<wasm function 607>
           7: 0x16931 - <unknown>!<wasm function 611>
           8: 0x174a3 - <unknown>!<wasm function 629>
           9: 0x19738 - <unknown>!<wasm function 655>
          10: 0x1afa9 - <unknown>!<wasm function 656>
          11: 0x48ff - <unknown>!<wasm function 383>
    2: exit with invalid exit status outside of [0..126)
undefined:1

[JairusSW]

@Thomasvdam, coming down the pipeline :)
@mattjohnsonpint, can I make this work-related?

[JairusSW]

@Thomasvdam, i'll release this in the next version. Should be dropping by end of week

[Thomasvdam]

Amazing, thank you for picking this up on such a short notice!

[JairusSW]

@Thomasvdam, for safety, I do recommend setting a default value for every type, so you should go ahead and do that. When parsing an incorrect type, it should just ignore it if not assignable.
I have implemented JSON.parseSafe() which will throw, but it is likely to have breaking changes. Eg. when implementing #58

[Thomasvdam]

@Thomasvdam, for safety, I do recommend setting a default value for every type, so you should go ahead and do that. When parsing an incorrect type, it should just ignore it if not assignable.

I'm not quite sure what you mean by this, I get errors on both JSON.parse and JSON.parseSafe for classes with or without default values:

@json
class InvalidAttributeWithDefault {
	value: string = "";
}

@json
class InvalidAttribute {
	value!: string;
}

Regardless, JSON.parseSafe is already super helpful so thanks a lot for that! We're looking forward to the improved error handling, that's such a great feature we don't mind the API changing when it lands 😄