Two error messages are affected:
1. When the user tries to access a static member of an extension
through an instance of a class that mentions the extension's "on"
type, and that extension is unnamed, we now report
INSTANCE_ACCESS_TO_STATIC_MEMBER_OF_UNNAMED_EXTENSION instead of
INSTANCE_ACCESS_TO_STATIC_MEMBER. The new error message is the same
as the old one (and uses the same sharedName), but it omits the
correction message suggesting to the user that they try accessing the
static method directly via the extension name, since this advice
doesn't apply.
2. When we report AMBIGUOUS_EXTENSION_MEMBER_ACCESS, if one of the
ambiguous members comes from an unnamed extension, we now report the
unnamed extension as "unnamed extension on '$type'" rather than
referring it to as an extension named `<unnamed>`.
Change-Id: I3ca3a1ccc9399b26b083040de20db8e4f691be32
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/217102
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
The errors HintCode.INVALID_VISIBLE_FOR_OVERRIDING_ANNOTATION and
CompileTimeErrorCode.EXTENSION_CONFLICTING_STATIC_AND_INSTANCE didn't
really need to name the enclosing declaration, since the user can
easily find the enclosing declaration from the location of the error
message. Without this change, there are some situations where an
error message would awkwardly refer to an unnamed extension as having
the name `<unnamed>`.
Change-Id: I4ddec389f18e78167464b1b5c35556e92dd1c15f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/216860
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
I think the headings are now 'correct' in the sense that they are
singular when there's a single example and plural when there is more
than one.
In the process I noticed that we have a similar problem with 'Common
fixes' in that sometimes there's one fix and sometimes multiple. I
don't think it would read well to say 'Common fix', so I'm disinclined
to change those, but it makes me wonder whether I should have just
used 'Examples' everywhere.
Change-Id: Idbfc3354b52cf1da677db51f4c626bb3269465b8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/215983
Commit-Queue: Kathy Walrath <kathyw@google.com>
Reviewed-by: Kathy Walrath <kathyw@google.com>
Previously, `pkg/analyzer/test/verify_diagnostics_test.dart` and
`pkg/analyzer/tool/diagnostics/generate.dart` extracted documentation
from the code of the analyzer error classes. However, since this code
is generated from `messages.yaml`, it's much cleaner to just extract
the documentation directly from the YAML.
Change-Id: I7dc3eb73abbf5d72f203abbf04e43856b60d2a89
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/215648
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This change moves a lot of logic into `error_code_info.dart`. In a
follow-up CL I'll make use of this code to re-work
`verify_diagnostics_test.dart` and the code generator for the
analyzer's `diagnostics.md` file.
Change-Id: I0dca7d30a9def771f03c6a51d26335aeab1c964c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/215662
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Previously this logic was duplicated in two separate locations,
`verify_diagnostics_test.dart` and the code generator for
`diagnostics.md`. Unifying it will pave the way for a follow-up CL in
which I intend to parse the documentation directly from the
`messages.yaml` files (rather than from comments in the analyzer
classes that are generated from those files).
I've also taken this opportunity to add some more checks to the
parsing logic, so that mistakes in the documentation (e.g. misspelling
a section header) will be reported as errors rather than causing a
silent loss of functionality.
Change-Id: Icfcb52229eb94bb06bc57334e265ef4d6db299de
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/215580
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This change standardizes most of the analyzer to refer to problem
messages and correction messages using the names `problemMessage` and
`correctionMessage` (consistent with the naming convention used in the
analyzer and CFE `messages.yaml` files).
Change-Id: I72f078a368c65b346626f560cc721fcff4836452
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/215151
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This change updates the classes Message, MessageCode, Template,
LocatedMessage, and FormattedMessage so that they uniformly refer to
error message text using the terminology `problemMessage` and to
correction suggestions using the terminology `correctionMessage`.
This brings them into alignment with the names we've decided to use to
unify the structure of front_end and analyzer, and makes them match
the names used in the anlayzer and front end's `messages.yaml` files.
Change-Id: Idcbb7ccfff6bb4e99ca22a3ef3c19d83880cf3c7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/215154
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
For errors that are shared between the front end and the analyzer, we
move the `documentation` and `comment` fields from
`pkg/analyzer/messages.yaml` to `pkg/front_end/messages.yaml` (where
the rest of the information about the error is). This eliminates the
need to have any entries at all for these shared errors in the
`pkg/analyzer/messages.yaml` file, so we no longer need the boolean
flag `copyFromCfe` in this file.
This simplifies generation of analyzer error codes, so we go ahead and
take this opportuntity to remove the old `syntactic_errors.g.dart`
file, and instead code generate all the shared messages directly into
`syntactic_errors.analyzer.g.dart`.
In a follow-up CL I'll rename `syntactic_errors.analyzer.g.dart` back
to `syntactic_errors.g.dart` to reduce confusion.
Change-Id: I1e314e51c94ef595d9d6de8ba2b30e12a18382a8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/215155
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Change the terms `template`/`tip` in the analyzer and front end's
`messages.yaml` files to `problemMessage`/`correctionMessage`.
Rationale: these terms were previously agreed on for unifying the
analyzer and front end, and they are currently used in the
`Diagnostic` class, which is part of the analyzer public API.
Change-Id: Ifaed92ab5176bba7b7f4c3bb915e9839520330f6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/215149
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
I've included both the YAML file (`messages.yaml`) and the script I
used to create it (`extract_errors_to_yaml.dart`), so that we can keep
the YAML file up to date until we finish writing logic that code
generates the analyzer errors from the YAML file.
Change-Id: Icbdcaf63a37105b666b11f7356e3fa246a8d65cb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/214133
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Previously, these mappings were computed on the fly during generation
of syntactic_errors.g.dart. Moving the mappings to their own data
structure makes the logic easier to re-use.
Change-Id: I1c38649b8c4aa4a42a6aa560faf67502d1c6560f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/215001
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Our understanding improved, and out approach changed significantly.
So, this existing implementation is different enough to be not
very useful anymore. And it gets in my way while doing other changes.
Change-Id: If31c20a0a6f86c01a58d16390a989f77962396b0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/214760
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
In follow-up CLs I will build on this data structure to do more
sophisticated YAML error message processing, including generation of
existing analyzer error codes from YAML.
Change-Id: If5d22e2ac3d5c123e3700f8d46c327920a941689
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/214076
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The tool `pkg/analyzer/tool/diagnostics/generate.dart` is very
particular about the format of documentation it recognizes. This CL
corrects a few minor inconsistencies that were causing it to miss some
documentation.
Change-Id: Iac937666426e987d597323e314f60971c15371be
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/214421
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Previously, if a CFE error contained a placeholder (such as
`#string`), that wasn't converted to the equivalent analyzer
placeholder, which meant that analyzer error reporting logic needed to
know whether the error being reported came from the CFE or the
analyzer in order to report the error correctly, otherwise the
placeholder text would just show up verbatim in the analyzer output.
Change-Id: If875de3a1a80048700b0edf458377c5fc87a15d0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213281
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This error message was previously reported by the analyzer's parser,
which presumably supplied an argument describing the modifier. It is
now reported by the shared parser, which doesn't supply any additional
information. As a result, the error message was showing up for the
user as "The modifier '{0}' can't be applied to the body of a setter."
(with a literal `{0}` visible to the user).
Changed the error message text to match what the CFE reports. There's
no real need for the message to describe the modifier since the error
message location is the modifier itself.
Change-Id: I538d49c1b693fe6cfb190f584bb5c9ab5cd3cf39
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213732
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This code is a little weird because of how this type instantiation
works:
```
typedef Fn<T> = void Function(T);
var x = Fn<int>.foo;
var y = (Fn<int>).foo;
extension on Type {
int get foo => 1;
}
```
`x` is illegal under any circumstance, because calling a getter on a
type instantiation can _only_ resolve to a constructor, but function
types do not have constructors. But it's nice to resolve what we can,
and what the user may have meant, and we have to represent
`Fn<int>.foo` _somehow_. So it's a property access on a TypeLiteral.
Add two new codes because it is not correct to say that `foo` is not a
getter on 'Type' because that is beside the point. The issue is that
there is no possible getter on a type-instantiated type literal of
a function type alias (nor method, nor setter).
Add lots of tests, for calling a method, a getter, and a setter on a
function type alias literal. Add tests with prefixes, bounds, too
many and too few args.
Bug: https://github.com/dart-lang/sdk/issues/46020
Change-Id: Icdf17506a64b3382226c5e50786784130d9e3bf9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213287
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This requires adding `isConst` to the ConstructorReference AST node,
which I think is appropriate, as it they can be in a constant context,
and we choose to report errors based on this state.
Change-Id: I4649c73a8bb3c2651a0e28838f0fc82574ce1622
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/212603
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
* This message should only be reported by the parser; the
error raised in the analyzer was strictly duplicate.
* This message theoretically used to mention "async*" or
"sync*" depending on the modifier that the function in
question listed. However, listing one modifier or the
other is a red herring, and may confuse the user; any
function declared with one or the other is a "generator",
and the error applies equally to a "generator" using one
or the other modifier.
Bug: https://github.com/dart-lang/sdk/issues/43665
Change-Id: I6ef1f5c055473170e7563222f6f0a6c56a4ad5f5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/210801
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
A constructor without a name is an "unnamed" constructor. A class which
has no constructors explicitly specified implicitly has one "default
constructor". See from the spec:
> Iff no constructor is specified for a class _C_, it implicitly has a
> default constructor `C(): super() {}`, unless _C_ is the built-in
> class `Object`.
This is the singular reference in the spec to this "default
constructor." There is text which refers to the implicit
superinitializer which refers to the superclass's unnamed constructor
which must have zero arguments:
> If no superinitializer is provided, an implicit superinitializer of
> the form `super()` is added at the end of _k_'s initializer list,
> unless the enclosing class is class `Object`.
Change-Id: I3202c3923d2c561d40c2251c1b13ea4fde8bda48
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/208865
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
One of the examples is now producing two diagnostics when it used to
produce a single diagnostic, so it needs to be ignored for now.
Also regenerated the diagnostic documentation, which had been missed in
a previous CL.
Change-Id: Id3c26ea86b71b11a0b5179b70175d375ec1a6ca8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/203260
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Sam Rawlins