This adds checks for three cases:
- error codes for diagnostics that are not being produced,
- error codes that can't be ignored (with a severity of error), and
- error codes that are already being ignored.
I originally also checked for names that are not defined as error codes
(which turned up at least one valid issue in the Flutter repo), but we
don't have a list of all valid names against which to compare because
plugins can add new diagnostics.
It should be noted that, as written, these diagnostics can't be ignored,
despite being hints. The reason is as follows: in order to detect
diagnostics that are not being produced, these checks need to have a
list of the diagnostics that _are_ produced. If an ignore comment
attempted to ignore one of these hints, this validation would occur
before the hint had been generated, so that comment would in turn appear
to be unnecessary.
If we need them to be ignorable, then we can special case them so that
they are never reported as being unnecessary.
And after running this over the Flutter repo I commented out two of the
three codes because there are violations. Many of the violations are
valid and need to be cleaned up. Some are the result of "ignore" being
used for other purposes. The Flutter team has said that we can replace
their use of "ignore" in order to enable these hints, but I don't have
time to do that right now and I'd like to get this landed before it bit
rots again.
Change-Id: I1704105621bef5a5c49202267c99aa1d950a26a9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/156402
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
If this diagnostic needs to be generated, then I can create an issue to
track that work, but I think we handle it by not defining the private
fields in our models, which means the issue is reported as an undefined
getter.
Change-Id: I8d220adf0d11b2c65f8953eec57a87f86f520d74
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/167100
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
The meta package does not yet have an `internal` constant;
this CL just adds one to the mock packages for testing.
Two checks are implemented:
* Hint if an @internal annotation is found on an element which is
already part of a package's public API (based on file path).
* Hint if an element annotated with @internal is exported from a
package's public API.
The notion of "public API" is also implemented for each type of Package:
BasicPackage, BazelPackage, GnPackage, PackageBuildPackage,
and PubPackage.
Bug: https://github.com/dart-lang/sdk/issues/28066
Change-Id: Ifc2709028afcd241f59e802f5952539f717704c3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/163126
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
* Add mechanisms to try out a recovery and only perform it if is
successful.
* Recover written out binary operators, e.g. "a xor b", "a or b" etc.
This fixes#26810 and is also how these operators are written in e.g.
Kotlin. This might be somewhat controversial though.
* Adds a mechanism to _replace_ a token by another token.
This might be controversial.
It is done because just inserting the operator causes the same rewrite
to be attempted on the same token stream several times (at least with
the way the token stream is parsed via the CFE) in turn causing it to
be recovered *sometimes*. This is now avoided by actually replacing
the token.
Change-Id: Icfa806045575d2aa2e5f35126708651b275bcf84
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/162003
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This reverts commit 50946855dc.
The bug that caused dartdoc to fail has been fixed by restoring the
creation of the invalid field. An issue has been created to update the
dartdoc package to stop using the invalid field, and the field will
need to be removed after dartdoc has been updated and pulled into the
SDK.
Change-Id: Ia7e282972e541a33b379872fbcd57a137a9c8a25
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/160120
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Although this error condition is not reported by the parser, the
language grammar does not it, so from a customer perspective it is a
parser error. Accordingly, it has been assigned a ParserErrorCode and
is reported by the AstBuilder, as we do for other similar errors.
Change-Id: I22aad9b0acd27bf6e60dfb393837d48a49fc336b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/158365
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
There are three ways to initialize a field/variable, so we have to
check for three error conditions:
- At the declaration site
- Via a field formal parameter
- Via a constructor initializer
Change-Id: I14caa38aaf2265966a19c68525f1458ff9d116f0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/158363
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Although these error conditions are not reported by the parser, the
language grammar does not permit them, so from a customer perspective
they are parser errors. Accordingly, they have been assigned
ParserErrorCodes and reported by the AstBuilder, as we do for other
similar errors.
Change-Id: I79d0ad1dcad518981b8b649c117df326279008f7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/157800
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
There are three ways to initialize a field, so we have to check for
three error conditions:
- At the declaration site
- Via a field formal parameter
- Via a constructor initializer
Fixes#42981
Change-Id: Ifc32a28ffb62d60fd2171d4980e88da9eebcb481
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/157664
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
As opposed to the parent CL which creates a new error for cases where no
non-generative constructor is available at all, these improvements
include a bugfix to the previous error message.
The previous message was incorrect in saying 'expected {0} but factory found',
because the argument passed to '{0}' was the factory constructor that
was found, rather than any kind of expected constructor signature.
Fixed.
Also, for implicit constructors, break out the error message to
deliberately explicitly describe that this affects the implicit
constructor.
I considered making an error code for implicit super initializers as
well, (ie `class Foo extends Bar { Foo(); }`), but don't think it is
necessary/common/etc.
Change-Id: I0643ad00abbfb2848cbd2f8f1f83e7c33d4fb846
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/155831
Commit-Queue: Mike Fairhurst <mfairhurst@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
In the case of extending Exception, the raised error is around the
configuration of the constructors. However, there is no valid
configuration of constructors to be found, and therefore, the better
user facing message is to say that the class cannot be extended as
written.
Change-Id: I5950d438877c450c44cdc914f9f20d7779a64768
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154126
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
I found literally zero tests for INVALID_CAST_FUNCTION_EXPR, and I was
unable to write any code that triggers it. :/
The rest are classified as compile-time errors in CFE; I am confident
that "compile-time error" is the correct classification.
Change-Id: Ib0cf543b983f8e28b45d40cc9cd4dc9f14b2f387
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/155302
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Fixes https://github.com/dart-lang/sdk/issues/29731
This change produces UNUSED_ELEMENT hints for optional parameters
for which no arguments are ever explicitly given, under the following
circumstances:
* parameter is for a constructor, method, or top-level function which
is not accessible outside the library,
* function is never torn-off (all bets are off once its been torn off),
* method does not override a method in which the matching parameter is
required,
* method does not override a method with a matching paramter, in which
an argument is given for the matching parameter.
Change-Id: Idabf051f55140b62a440dc63ca0234f22598a5e8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/152730
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Brian Wilkerson