| Code-Review | +1 |
The analysis_server changes lgtm.
var yamlMap = fileContent?.yaml.tryCast<YamlMap>();I don't understand the reason for changing from a getter to a method, but I also don't think it needs a lot of discussion. I mention it in case it's an artifact of the path taken to get to this point and could be simplified back to just being a getter.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
var yamlMap = fileContent?.yaml.tryCast<YamlMap>();I don't understand the reason for changing from a getter to a method, but I also don't think it needs a lot of discussion. I mention it in case it's an artifact of the path taken to get to this point and could be simplified back to just being a getter.
We replace `YamlMap? yamlMap` with `YamlNode? yaml`, because this is what YAML parser returns. We can keep `yamlMap` getter too.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
part of 'analysis_options_parser.dart';Add copyright.
part of 'analysis_options_parser.dart';Add copyright.
// [diag.invalidSectionFormat][column 7][length 5] Invalid format for the 'exclude' section.Why is this not using `^^^^^`?
// [diag.invalidSectionFormat][column 5][length 21] Invalid format for the 'errors' section.Ditto.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Commit-Queue | +2 |
part of 'analysis_options_parser.dart';Konstantin ShcheglovAdd copyright.
Done
part of 'analysis_options_parser.dart';Konstantin ShcheglovAdd copyright.
Done
// [diag.invalidSectionFormat][column 7][length 5] Invalid format for the 'exclude' section.Why is this not using `^^^^^`?
Because YAML parser returns for `a: b` a span that covers `a: b\n`.
I will add a fix for these spans separately.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
13 is the latest approved patch-set.
The change was submitted with unreviewed changes in the following files:
```
The name of the file: pkg/analyzer/lib/src/analysis_options/analysis_options_parse_model.dart
Insertions: 4, Deletions: 0.
The diff is too large to show. Please review the diff.
```
```
The name of the file: pkg/analyzer/lib/src/analysis_options/analysis_options_include_walker.dart
Insertions: 4, Deletions: 0.
The diff is too large to show. Please review the diff.
```
AO. Parse and validate at the same time.
See https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/
Current data flow:
1. AnalysisOptionsParseSession.parse() creates a _ParseRequest for the
initial file, SourceFactory, context root, and SDK constraint.
2. The request asks the session for a _FileNode. The session
reads/parses file content into _FileContent, then creates a
_ParsedFileNode, _MalformedYamlFileNode, or _UnreadableFileNode. For
parsed files, valid include directives are resolved into
_IncludeResolution edges, so parsed files form an include graph.
3. _ParsedFileData is computed per parsed file. This is where local YAML
facts are extracted and local diagnostics are recorded: invalid
sections, unsupported options, bad formatter values, bad linter rule
names / values, deprecated/removed lints, plugin option errors, etc.
4. _AnalysisOptionsIncludeWalker walks the include graph for
diagnostics. It reports initial-file diagnostics directly, translates
diagnostics from included files onto the initial include chain as
included-file warnings, and reports include-specific errors such as
missing includes, malformed included YAML, and recursive includes.
5. Linter conflict diagnostics are computed during the include walk from
_ParsedFileSemantics. Semantics combines included effective linter rules
with local linter rules, so it can report incompatible rules between
includes, between local and included rules, and respect local
overrides/disabled rules.
6. Legacy plugin multiple-plugin diagnostics are also computed during
the include walk. The walker compares the local legacy plugin entries
with the effective plugin entry inherited from includes, preserving the
current precedence behavior.
7. Separately, effective AnalysisOptionsImpl is built by recursively
applying included _ParsedFileData first, then the local _ParsedFileData,
through _ApplyState.
8. AnalysisOptionsParseResult returns the initial file, initial content
if readable, the built options object, and diagnostics computed from the
same include graph.
I believe that the implementation is more complicated than it could be,
around lint rules and plugins. But this is what is necessary to keep
existing tests pass. I will try to simplify in following CLs, by making
smaller changes to both tests and implementation. We need to establish
intentional behavior in these areas from accidental consequences of the
previous implementation (which I have for now to carry over).
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |