Cases where `null` was being passed as an argument to formatting a
message have all been fixed in previous CLs; all that remains to do is
change the type system to reflect that, and insert `!`s in a few
places.
This brings us one step closer to being able to make analyzer message
formatting type safe.
Change-Id: Id9e0d0b32f29cde0fdc5227417b7a2e3fc3b443d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/216272
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This change adds a stack trace so that if the check fails, the user
sees the stack trace of the call to `checkUnassigned` prior to the
stack trace from the process of visiting the mini-AST. Usually teh
stack trace from the call to `checkUnassigned` is much more useful in
debugging, since it allows the user to see the location of the problem
relative to the code being analyzed.
Change-Id: I125b4059ec740850919798cfa66bf7e8c7490213
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/217283
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Since the check or the absence of the check for a named argument
appearing before a positional parameter is feature-specific
considering the language feature that allows placing the named
arguments anywhere, it should be performed by the listeners of the
parser and guarded by an experiment flag, in alignment with other
experimental featuers. This CL moves the check and the reporting of
the error from the parser into the Analyzer, so that later this check
can be skipped if the corresponding experiment flag is enabled.
Part of https://github.com/dart-lang/sdk/issues/47451.
Change-Id: Ib795d418af429ee04ecfff6dfa71ec1e836fe798
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/216640
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Chloe Stefantsova <dmitryas@google.com>
- Allows FfiNative annotation to be attached to non-static
methods of classes.
- Transforms non-static instance methods to static, adding
wrappers with the receiver as an extra, implicit first paramters.
- Transform all parameters and arguments to Pointer if the object
being passed supports it (i.e. extends NativeFieldWrapperClass1).
- Adds compile time errors for cases where the FfiNative annotation
doesn't align with the annotated function. Taking into account
implicit receivers and converted Pointers.
- Adds complimentary Analyzer checks for the above errors as well.
- Adds tests for the transforms, compile time errors and analyzer
changes.
TEST=Adds new tests for instance methods, analyzer changes.
Change-Id: Idf54430acf2728a650008333b149b254941290ad
Cq-Do-Not-Cancel-Tryjobs: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213773
Commit-Queue: Clement Skau <cskau@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Adds @staticInterop annotation to allow users to declare static interop
classes. Also adds errors for erroneous usage of static interop
classes, like including instance members or using a non-static
supertype.
Change-Id: I21abafbf6ea6c2eb7cd0425f0a54c1ba35d6ec6c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/215010
Reviewed-by: Sigmund Cherem <sigmund@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>
Previously we had identified this error with the analyzer error code
CompileTimeErrorCode.WRONG_NUMBER_OF_TYPE_ARGUMENTS_CONSTRUCTOR, but
they're not the same error at all. As a result, code like this:
var x = new a.b.c<C>();
would lead to the bogus analyzer error text "The constructor '{0}.{1}'
doesn't have type parameters." (with the placeholders "{0}" and "{1}"
visible to the user).
With this change, the error text is the same as that from the CFE: "A
constructor invocation can't have type arguments after the constructor
name."
Change-Id: Ib69d1ff8f7089e59b71d2dcd9a8ec51edffd94dc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213621
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
These behaviors were introduced during the fix for
https://github.com/dart-lang/language/issues/1785, and at the time
they were tested using both unit tests and language tests. But it was
not possible to write ID tests for them, because ID tests don't
support turning on experimental language feature flags.
Now that the "constructor-tearoffs" feature has been turned on we can
test these behaviors using ID tests.
Change-Id: I6e1ccda4b5837ab61de80f15d2f31a82a90b4a22
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/212265
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
E.g. if reporting a missing ";" after a SyntheticStringToken (e.g. a
inserted identifier) before this CL it would go to the next token and
say we expected the ";" after that, when really we expected it *before*
that token.
Change-Id: I2c358e017edb2f661e307eba03dddaee889086d9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/205799
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
When the parser encounters a `<` after an expression, it must choose
whether to interpret it as a relational operator or a <typeArguments>
selector. The disambiguation rule is: if the `<` and the tokens
following it *can* be parsed as <typeArguments>, and the token that
follows is a member of a privileged set of tokens, then it is treated
as a <typeArguments> selector; otherwise it is treated as a relational
operator.
This change reduces the privileged set of tokens to the following:
- the "continuation tokens" `(`, `.`, `==`, and `!=`
- the "stop tokens" `)`, `]`, `}`, `;`, `:`, and `,`
The names "continuation tokens" and "stop tokens" reflect the
rationale for choosing these tokens:
- Continuation tokens are tokens that we can reasonably imagine a
programmer wanting to place after a type argument selector to
*continue* the expression. For example, `if (List<int> == T) ...`
is allowed.
- Stop tokens are tokens that can't possibly follow a `>` that is a
relational operator, because they *stop* the expression that's in
progress. For example, `var x = List<int>;` is allowed.
If a user wants to follow a <typeArguments> selector with a token
other than the ones above, they'll have to parenthesize the
expression. So for example, if they want to do `List<int> + 1` (which
could be meaningful if an extension method defined `operator +` for
the type `Type`), they will have to use parentheses, and instead write
`(List<int>) + 1`.
Bug: https://github.com/dart-lang/language/issues/1806
Change-Id: I2816cdac24e55eac3cb3e9920e276404c1228d46
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/210941
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Previously, the analyzer and CFE were responsible for two pieces of
logic that arguably should be in the shared flow analysis engine:
- Deciding whether or not it's necessary to tell flow analysis about
initializer expressions.
- Deciding whether or not to promote the variable at the time of
initialization (we do this when the variable is implicitly typed,
and the initializer is a promoted type variable type).
It's better to just always tell flow analysis about the initializer
expression and let it decide what to do about it.
This paves the way for fixing
https://github.com/dart-lang/language/issues/1785 (which results from
initializer expressions sometimes being ignored when they shouldn't
be), by consolidating the broken logic into the flow_analysis library,
where it will be easy to unit test the fix.
Bug: https://github.com/dart-lang/language/issues/1785
Change-Id: Iec832e92995eb4f8d0c1fbd4e9be6c897e0917b5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/211180
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This flag prepares for the removal of the special case of implicit
creation syntax, `foo<bar>.baz()`, which with constructor-tearoffs
doesn't have to be a creation expression. Since both the analyzer
and the CFE needs to support parsering without special casing
before it can be removed, the flag is added to ensure both
implementations will agree on what the future parser behavior will be.
The CL hard-wires the CFE use of the parser to a single constant value.
Change-Id: I04724f039d2e698f3cf67e8b0b56dfa7e96ed3b4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/211000
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
* Force depot_tools to use python3 results (USE_PYTHON3=True).
* Fixes the dart format presubmit check.
* Remove broken DOM tools presubmit check.
TEST=Manually provoked errors and ran git cl presubmit -v -f.
Cq-Include-Trybots: luci.dart.try.shared:presubmit-try
Change-Id: I8ba46e2ae1640f1b2f82e18bc8024e0aa4838b2b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/210123
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: William Hesse <whesse@google.com>
Johnni Winther