This method is (accidentally) not currently being called, but it will be soon. The codegen wasn't using the resolved base-type for the enum when writing the type check.
Change-Id: I025ed5109c70d8916f800295350a3f4eaf8f16f2
Reviewed-on: https://dart-review.googlesource.com/c/94294
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Previously we were only outputting the validation code if the value was required. This changes it to also validate in the case it's not required, but only if it's not-null.
Without this change, the test that parses `'overwrite': 1` fails (a boolean is expected), but with it, it passes.
Change-Id: Ic4afe1f6a8f78add2385831907b226022b7ecaec
Reviewed-on: https://dart-review.googlesource.com/c/94293
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This fixes a mistake where enum classes were resolved to their base types (string, num) before being output in canParse methods of their containing class. This meant for "restricted" enum types (those that should not allow any value), canParse would incorrectly return true for out-of-bound values as long as they were the correct type.
Change-Id: I44e37a60b49287cf7202d5a578ee9c08cf898078
Reviewed-on: https://dart-review.googlesource.com/c/94280
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Danny Tuppeny <dantup@google.com>
Previously we assumed enum classes could only be the values specified in the spec, but this was not correct - newer clients may know about values that we did not know about at the time we shipped(/last regenerated).
This makes the default for an enum class to support any class (avoiding deserialisation failures when new clients send newer values), and opts-out for those where the spec is explicit that the value set is fixed.
Also opened https://github.com/Microsoft/language-server-protocol/issues/686 for clarification that these "fixed set" values are explicitly intended to never be extended, or whether this is accidental.
Change-Id: I6243fc91c14ec0fa5622d3f6f29bf77cadf7da64
Reviewed-on: https://dart-review.googlesource.com/c/94220
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Danny Tuppeny <dantup@google.com>
The ResponseError.data field was typed `dynamic` (as in the LSP spec) but this allows us to accidentally put non-serializable classes in it which will result in server errors when we try to send them back.
This change forces them to Strings and it's up to the code constructing the error to convert any additional data to a string first.
In order to catch this in tests, the mocks now force serialisation of all types flowing from the server to the client (this already happened for client to server).
Change-Id: I5d7f322e1a4296b1479468e36d81daebdbb4ab52
Reviewed-on: https://dart-review.googlesource.com/c/89511
Commit-Queue: Danny Tuppeny <dantup@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
The README was missing some methods (recent additions?) and also not quite in the same order - this fixes that. Also re-generates the classes based on current spec (mostly comments updates, but also non-nullability for `targetSelectionRange`.
Change-Id: I0dd4e24daf51b659783058362339550ec46fa1c8
Reviewed-on: https://dart-review.googlesource.com/c/89641
Commit-Queue: Danny Tuppeny <dantup@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Auto-Submit: Danny Tuppeny <dantup@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This adds some custom code for serialising ResponseMessage to ensure that only one of result or error are ever specified, as required by JSON RPC.
Change-Id: I2736b83755553a906264b1e5251d1a535dc289fb
Reviewed-on: https://dart-review.googlesource.com/c/88953
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Danny Tuppeny <dantup@google.com>
Without this, some requests that don't return values (like shutdown) would omit the `result` field from the response and this wasn't strictly correct (and caused an issue in testing with the VIM plugin).
Change-Id: Id961135d326b997aea69e29d9d2a4a2c310fa60c
Reviewed-on: https://dart-review.googlesource.com/c/88839
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Nothing in the LSP spec supports arrays as params (let alone a union of a single item or array).
Since the new type is dynamic, this should be non-breaking even if LSP changes (though we'll want to put it back if we need to write a handler for something that accepts a union like this).
Change-Id: Id1af1d438fede94906ae76eaa8b9a959b0b62ccf
Reviewed-on: https://dart-review.googlesource.com/c/85396
Commit-Queue: Danny Tuppeny <dantup@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
The regex wasn't picking up generate type args (in interface definitions or usages in field definitions). This adds <> characters to the regex and handles them in mapping of types (as well as adds some additional tests to cover this).
Change-Id: I8187b3d2abb2b35c0d7638839e3116700cfbf9e0
Reviewed-on: https://dart-review.googlesource.com/c/81004
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Danny Tuppeny <dantup@google.com>
Also add a canParse() method that can check whether some provided JSON can be decoded into that type (used for detecting with type from a union to decode as).
Support equality checks on unions and a valueEquals() helper
Remove brittle tests that do exact comparisons on generated code
Fix deserialisation of lists to be cast and toList()'d
Add a more complete JSON test that includes lists, enums
Change-Id: Id56fdad9b1454e540e55907e0ff2608263a87c40
Reviewed-on: https://dart-review.googlesource.com/c/80580
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Danny Tuppeny <dantup@google.com>
Danny Tuppeny