This is in preparation to migrate package:kernel to null safety.
For the visitor interfaces to support non-nullable return types, the
implementations must avoid using `null` as return value in its base case.
TEST=Refactoring
Change-Id: Ie5e4153f8d3779d94957bb13b3d2d2a942040ff2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/179760
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
This CL:
* Adds a "reordering fuzzing step", i.e. it tries to sort the fields,
procedures etc in both ascending order and descending order
to verify that there are on crashes and no changes in error vs
no error. This has been tested on http://dartbug.com/34803
before the fix landed.
* Introduces an attempt at "visiting the outline" of the "direct from
parser ast".
Change-Id: Ic3f5a776839030bb48a35eeee8575b37c19be453
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/182504
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This CL updates the parser so that it allows annotations of the form:
`@` <constructorDesignation> <argumentPart>
Where <argumentPart> can contain type arguments. Previously this was
prohibited at parse time.
Generic annotations are still prohibited in the current language
version, but the error is now generated by the parser listener
(BodyBuilder in the case of CFE, AstBuilder in the case of analyzer);
this should open the door for future CLs to add support for generic
annotations when the `generic-metadata` experimental flag is supplied.
Bug: https://github.com/dart-lang/sdk/issues/44838
Change-Id: I90604f38bcb378fc798c5737e486fb26589d4d1e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/182668
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
This combines the creation of synthetic variables with registration
of the create variable in flow analysis.
The fixes the failing expectation tests that currently crashes with
assertion failures.
Change-Id: I0d581653775dab135abebdecd28c19c5712b8d88
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/182562
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
This CL implements the core flow analysis infrastructure for tracking
reasons why an expression was not promoted. It supports the following
reasons:
- Expression was a property access
- Expression has been written to since it was promoted
I expect to add support for other non-promotion reasons in the future,
for example:
- `this` cannot be promoted
- Expression has been write captured
- Expression was a reference to a static field or top level variable
These non-promotion reasons are plumbed through to the CFE and
analyzer for the purpose of making errors easier for the user to
understand. For example, given the following code:
class C {
int? i;
f() {
if (i == null) return;
print(i.isEven);
}
}
The front end now prints:
../../tmp/test.dart:5:13: Error: Property 'isEven' cannot be accessed on 'int?' because it is potentially null.
Try accessing using ?. instead.
print(i.isEven);
^^^^^^
Context: 'i' refers to a property so it could not be promoted.
Much work still needs to be done to round out this feature, for example:
- Currently the analyzer only shows the new "why not promoted"
messages when the "--verbose" flag is specified; this means the
feature is unlikely to be noticed by users.
- Currently the analyzer doesn't show a "why not promoted" message
when the non-promotion reason is that the expression is a property
access.
- We need one or more web pages explaining non-promotion reasons in
more detail so that the error messages can contain pointers to them.
- The analyzer and front end currently only show non-promotion reasons
for expressions of the form `x.y` where `x` fails to be promoted to
non-nullable. There are many other scenarios that should be
handled.
Change-Id: I0a12df74d0fc6274dfb3cb555abea81a75884231
Bug: https://github.com/dart-lang/sdk/issues/38773
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/181741
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Members declared in mixins are treated as if these were declared in
the class where they are mixed in. This means that use their types as
declared types, instead of including them in a combined member signature.
This failed in the case where a member was synthetically added to the
mixin class, because the types of these we wrongfully be handled as
declared types.
We now skip all synthetic members when reasoning about mixed in members
as declared members.
Change-Id: I9c2311b4472fe16162fcdc4c56fce8db2d946f4d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/181201
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
From the times where some of the type arguments should have been
reported as warnings, the procedure was run twice in two different
modes, in order to report some issues as errors and some as warnings.
This CL is a cleanup that invokes the procedure once. Additionally, a
refactoring of the return value discipline is made: it always returns
a list and never returns null. An empty list is returned if there are
no issues.
Change-Id: Id497216bf51f49c86517cf16a52f03da5b65b1fd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/180570
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Dmitry Stefantsov <dmitryas@google.com>
This converts `return e` in async methods in opt-in libraries into
return let v = e in v is Future<FTV> ? await v ; v
where FTV is the future value type of the enclosing function.
Closes#44395Closes#44396Closes#44397Closes#44399
TEST=existing tests
Change-Id: I59687039bfe4a97ffdaa55ac0f193ca4fb208f44
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175310
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
We now track the following additional information:
- All local variable reads and read captures (previously we only
tracked writes)
- For any conditional expression (`?:`) or if-test, the variables
written in the "then" branch
- For any logical and expression (`&&`), the variables written in the
right hand side of the expression
Tracking this information will allow us to implement legacy type
promotion as part of _fe_analyzer_shared, using the same API as flow
anaylsis, which will in turn allow a lot of front end and analyzer
code to be removed and simplified.
Change-Id: I01aaf64cefb989a4450c8e6d3a8373c1ca2b6dec
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/179980
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
A factory is saved as a procedure in kernel, and was thus also indexed
as a procedure for the purpose of experimental invalidation.
This caused trouble when having a "real" procedure and a factory with
the same name.
That is fixed by this CL by indexing factories ad constructors.
Fixes https://github.com/flutter/flutter/issues/74180
Change-Id: Ieef0421c29a61e26f2a7ee4bb4f196672afd8445
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/180148
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
The new implementation uses the same API as flow analysis. This
should allow us to significantly simplify the CFE and analyzer, by
dropping their implementations of legacy type promotion in favor of
the shared implementation.
This CL just introduces the new implementation and unit tests for it;
it does not integrate it with the analyzer or CFE. I will follow up
with a CL that does the integration.
Change-Id: Ie07b3b39604d6a022ad42f3ae6b648a317c8af28
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/179560
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
The only references that are promotable are references to variables,
however in the near future I'll be adding logic to flor analysis to
keep track of attempts to promote fields; this will require tracking
references to property gets as well as references to `this`, so we
need to start building up data structures to track those references.
Bug: https://github.com/dart-lang/sdk/issues/38773
Change-Id: I0e3fd44f580bb85db3e8f405675b66aa4069e455
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/179280
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This adds a new messages kind 'info' to the CFE for showing general
information during compilation. A 'configuration' options is added
to `CompilerOptions` for telling the CFE how it is run.
The configuration 'compile' is added for when the CFE is invoked to
produces an "executable" as when running `dart compile`. When
configuration is set, the CFE emits an info message about the
null safety compilation mode.
Support for `dart compile exe` and `dart compile js` is added in this
CL. Support for `dart compile kernel|app-jit|aot` is not included.
In response to https://github.com/dart-lang/sdk/issues/44234
TEST=pkg/dartdev/test/commands/compile_test.dart
Change-Id: I08f51e2a3f5ad4841c4d703bcd266b7afb63c7c6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/178982
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Adds helpers for extracting original name of a lowered late field, the
original initializer and the field used to hold the value of the lowered
field.
This helps backends to customize late field encoding while still using
the lowering provided by the cfe.
Change-Id: Ib42af539efad84a08a6e32acd29d2efaff129cd7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/178989
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Before this CL, the map we use to "reuse" references when doing
experimental invalidation mapped from String to Reference.
In bug #44523 two abstract member-signatures have the same textual
(String) name meaning that via the lookup one would get the correct
one, one would get the wrong one, they would get the same one
which eventually causes a crash when trying to serialize.
This CL fixes the issue by mapping via the Name instead, which
basically - for private names - wraps the name and the library
which disambiguates it.
This CL also includes the reproduction of #44523.
Fixes#44523.
TEST=Mostly relying on existing test coverage.
Change-Id: Ib62ebca0b7f5092f0b8410d3c458663c3032eca1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/177704
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Changes fields to be either mutable or immutable by construction.
This ensure that we don't create setter references for fields that
cannot be assigned to and is a prerequisite for replacing @fields/
@fields= canonical names with @getters/@setters.
TEST=existing expectation tests and verification
Change-Id: I70b9a504ee6f221b7c334ac02620feb0d5f7ae01
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/176665
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Johnni Winther