Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
The analysis exclude path base is from the source directory, not the package root #31344
(related to #31343)
The documentation suggests that the exclude file paths are relative to the package root (seeing that
analyzer: exclude: - 'testdata/directives_test/after.dart' - 'testdata/directives_test/before.dart' - 'testdata/double_quotes_test/after.dart' - 'testdata/double_quotes_test/before.dart'
[This doesn't work]
analyzer: exclude: - 'test/testdata/directives_test/after.dart' - 'test/testdata/directives_test/before.dart' - 'test/testdata/double_quotes_test/after.dart' - 'test/testdata/double_quotes_test/before.dart'
This was happening in a fuchsia dart package, in case it matters.
referenced this issue
Nov 9, 2017
Note: this is actually an issue of where a path is passed in to dartanalyzer other than the analysis_options path. I'm assuming this is:
it may not be super high priority for us since it has a workaround and is a bit nastier than I expected to fix, but I'm still looking into it.
I think, and please correct me if I'm wrong, you're experiencing the opposite issue with the analysis server.
If I load dartfmt_extras in intelliJ, the excludes don't work because they don't have the 'test/' prefix. Adding the test/ prefix fixes it -- this is also what the spec says should be done.
However, then if you run
For forwards compatibility with the fixes incoming, and to get it working with the current correct behavior of dartanalyzer, I'd recommend listing both:
referenced this issue
Feb 20, 2018
Here's the state of the options file: https://fuchsia-review.googlesource.com/c/topaz/+/125459/1/tools/dartfmt_extras/analysis_options.yaml
I'm still seeing errors in Atom. Note that they start showing up the moment I open an excluded file.
Yes, that's a known issue. Originally, the analysis server would not show any information for excluded files: not errors, highlighting, navigation, code completion, not anything. But our users expected that they could navigate, etc. in an excluded file if they opened it, so we "fixed" it by sending back information about excluded files if (and only if) they are opened in the client.
For the most part, this is innocuous because clients discard all of this information when the file is closed. Except for errors, which most clients keep until server tells them to update the list. What I think we really need is to introduce something to the API so that clients will know to discard errors for excluded files when the file is closed (and update clients to understand it). It just hasn't yet been high enough priority to get done.