All Perf Unit tests are run on the hardware agents to ensure stability of the metrics.
So the annotation is not needed anymore and it doesn't work on JUnit5 tests so the same test is run twice and since test execution time depends on the bucketing, metrics are jumping.
GitOrigin-RevId: fc83a368447d09d6ad1b269c88fe4f6c79067a91
Historically, we store enum's string representation inside the json mappings state. In turn, the string is assembled from a message bundle line used in several places across the project. Changing this line broke the deserialization process.
To preserve backward compatibility, we intentionally continue using the same approach, but provide a converter capable of reading the schema version tag both in new and in old formats
GitOrigin-RevId: 8813740318ede3c9bc5656ee46c847059760e3c5
`BrowseFolderRunnable` and `*WithBrowseButton` family: getting rid of separate "title" and "description" parameters in favor of the chooser descriptor object, to avoid cloning the latter down the road.
GitOrigin-RevId: 33ec5968a1db953c60848974135055c288accf85
If you see any problems with your spellchecking strategy, please feel free to remove DumbAware from it. Or, you can make it dumb-aware by avoiding using indexes in dumb mode
The only strategies that are not DumbAware at the moment are:
- JavaSpellcheckingStrategy
- JSSpellCheckingStrategy
GitOrigin-RevId: 74781cf1ebd9b58669396bf7b1c03a839019f12b
- JSON becomes a true plugin instead of a bundled module.
- New plugin's ID is intentionally set equal to the old module name so that external dependent plugins would not face difficulties migrating to the new layout.
- All discovered internal plugins that implicitly depended on the JSON module currently unconditionally depend on the plugin.
- Consider extracting optional modules in a subset of affected plugins: spring.boot, intellij.yaml, intellij.java
- Consider testing the following IDEs that bundle JSON extension using xml:include: writerside, rider
- Refactor PlatformLangXmlPlugin to avoid api breakages
GitOrigin-RevId: 7d92b0c5905154c4f6f25d55f3246e79da79e278
This validation has very limited support in the json plugin, it depends on the results of other validations, and must be applied only when IDE is really sure that the error exists. In case of complicated inherited schemas it should give up if any uncertainty occurs.
GitOrigin-RevId: 2ccc53306b27c114748d9a01ddedcd4636667bde
Unspecified type in the meta schema lead to treating many of the instance fields as either an object, or a boolean (as it is specified in the #meta schema node).
GitOrigin-RevId: 4c1441f161039eef502fd7e3e4b64295d04cffc3
- If requested, validation will stop as soon as any error is found. This is extremelly important performance optimisation that plays well with the recenty introduced if-else branch computation. The number of calls to JsonSchemaResolver.isCorrect() increased dramatically, even more json-schema subsystem refactoring was demanded.
The existing API didn't assume any kind of laziness or cancellability. The refactoring is performed in a way to cause minimal number of changes in code and API. It'd be great to rewrite the entire validation code to sequence/analogs once and drop complicated JsonAnnotationsCollectionMode
GitOrigin-RevId: 4e62f7db76ed6b4071accbe1b80151c4b4664342
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
