Previously used asText() method always returns empty string for object nodes, which makes using the readChildNode(..) API inconvenient. Currently, we use pretty rendered string here
GitOrigin-RevId: 4c22553db897e371d6013f8dd8a7be2aa782c431
With the introduction of if-then-else resolve that selects a branch depending on a given instance file element, the number of calls to JsonSchemaResolver.isCorrect method increased significantly. It is expected, as any validation/reference contribution/other editor features require a resolved schema node.
Resolve results are cached on language modification tracker because with the instance file updates, a previously valid if-else branch might become invalid
GitOrigin-RevId: f197203a3c53a7c4e7c1d502faaff3d50a9451e3
To fix it, we should make MatchResult store schemas in a set to avoid equal objects from being present in the resolve result. But this for some reason breaks ancient anyOf validation. The related code seems really hard to debug, so the merging test is currently disabled. The corresponding change is reverted in the previous commit.
GitOrigin-RevId: 08e7fd02cb6556044c3a80863bd29fa1d770155f
This reverts commit 14f06c419ff394383dd974da36c34da91b8c488a.
The change in the MatchResult cannot be used so far because ancient allOf/anyOf resolve relies on having several equal-by-pointer json schema objects in a collection.
GitOrigin-RevId: 48bda04351f25fd783d1e051bf61115876e0739e
Validation-related methods should not be inherited, only the methods providing access to the parent node should. Example: getPropertyByName
The reason: currently, every property step involves inheriting a parent's schema -> might result in incorrect validations applied to child nodes. A better fix would be to introduce inheritance strategy and inherit different options for if-then, one/any/allOf and other cases. See JsonSchema2020FeaturesTest#test adjacent if-then completion and comment for an example
GitOrigin-RevId: 3c3b790a2ee07529d7671a4f3d3866981926d75d
The resolved object will anyway be associated with the referenceOwner later during the propertyStep() method execution. There is no need to nest two inherited objects inside each other for no reason
GitOrigin-RevId: 8c1a9820d1e1eb976a2888998a44462287b309af
Inherited works as follows:
- it wraps parent and child JsonSchemaObjects
- it delegates composed schema access to child object (oneOf, anyOf, allOf, not, if-else)
- it combines other properties and prefers children's one if the property is present in both objects
This helps solve dynamicAnchor and dynamicRef problem where an anchor declared in a base schema could be overridden in the dependent one. References to the anchor must resolve to the overridden anchor location -> we have to keep track of both declarations via inheritance mechanics.
GitOrigin-RevId: f26f14735ff937326cd559ae05288d369477e1a6
- if-then-else tests for smart and basic completion with different resolve logic
- dynamic anchors with overridden values
- unevaluated properties
- prefix items
- dependent schemas
- various new validations tests
- yaml and json coverage
GitOrigin-RevId: 63ec3d8176ef368a8c80ebcd3687fb3732412df3
- Inheritance plays a crucial role in dynamicRefs resolve and makes it possible to override the dynamicAnchor declared in the base schema and overridden in a dependent one
GitOrigin-RevId: a87c59be41eda46454e99e50fd9eec557cb7ebcd
Now validations are provided by schema nodes themselves which sounds natural. Set of available validations highly depends on the node validation happens against.
GitOrigin-RevId: abfbdfda6025da5fff7b9b7670c7e9687cec4c9b
- Some large methods were split into several
- Inspected value adapters were reused to ensure correct resolve
- Old incorrect if-else validation was removed in favor of if-else expansion; The idea is that after resolve there wouldn't be any if-then-else expressions to process - we have to resolve to some final json schema node in the end, where plain validations would work perfectly without some special treatment. This is now unified with other applicators like oneOf or referenced schema nodes
GitOrigin-RevId: 6ad07cc467965c039ff29184be6c94e3f33d8b01
Now all available expansion types require passing a resolve request that provides access to the inspected PSI element. Since operations may nest, all of them should transfer the initial element's-wrapping adapter into their children
GitOrigin-RevId: 489718014e5eb3e83da207fafbed357b4cf202fe
To be able to work with if-else expressions met in the middle of the resolve path and to avoid various hacks related to inability to select the correct branch resulting frequently in incorrect validation results, the new IfThenElseBranchOperation is introduced.
It is responsible for choosing the right branch to resolve to and actually works during resolve phase, not during the resolved object consumption by any client extension like completion contributor or inspection.
To ensure correct branch selection, one must provide an inspected PSI element wrapper. Schema will try to process its content and select the branch depending on it. There is also a mode where all branches are considered valid - useful for completion purposes
GitOrigin-RevId: 103c7c0e97bebe1469e85b7b914be5264b4ca3af
Now it accepts an inspected PSI element adapter required for in-schema resolve against a validated instance file. Expressions like if-then-else would benefit a lot from such an improvement
GitOrigin-RevId: cc1e986786a7d68ad4666319b05a6662037af243
All keywords and specific behavioural patterns like reference resolve are to be extracted to separate abstractions provided by strategy instance. Many of the properties remain the same between different schema versions, though it's worth to ensure equally looking method implementations -> each method asks strategy about how a particular feature should work in the selected schema version.
GitOrigin-RevId: b04398007e1862f96d4dab95b79b814f3e3f7df1
A strategy is an abstraction to store version-specific schema reading/validation/resolve logic. Since the schema is most likely specified in the top-level $schema property or manually per file, it is enough to have a single strategy instance for all nodes corresponding to the same physical schema file
GitOrigin-RevId: 9ab9acc0e54714b4da8025180f40b22f97d13666
A minimal set of methods was added for the new features support, as well as some old signatures were updated to reflect the upcoming updates
GitOrigin-RevId: de66f9a354bf27b690be8fbd0fd092da0e406334
