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>
Also, fix the one package that didn't have one, and regenerate the
config.
Change-Id: Id7f210e9a3f73b2070e52df6ae9d4b1c4d4aeae3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/172081
Commit-Queue: Leaf Petersen <leafp@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Auto-Submit: Bob Nystrom <rnystrom@google.com>
This is the first checked-in SDK with null-safety enabled by default.
Change-Id: I8f6fcdfd8856483f4737eb200ed4623a244cb0cd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/170085
Reviewed-by: Leaf Petersen <leafp@google.com>
Commit-Queue: Alexander Thomas <athom@google.com>
Change naming value classes -> value class
Change-Id: Ifab5e0be8b816192b5716fd3433afb721bd9394c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/156881
Commit-Queue: Javier López-Contreras <jlcontreras@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Follow-up to 84ca34bf8b
Change-Id: I87d2bf0a77dc70f15a378a149dc95be6f33ee3c9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/147803
Commit-Queue: Kevin Moore <kevmoo@google.com>
Commit-Queue: Karl Klose <karlklose@google.com>
Reviewed-by: Karl Klose <karlklose@google.com>
This is done by setting the SDK constraint min version in the package's
pubspec to 2.9.0 which is the version that CFE currently uses to mean
"opt in".
However, the pre-built SDK currently checked into the repo can't handle
that version. To work around that, this CL has a gross hack to simply
omit the language version in the generated package config if the
pubspect's version is 2.9. This has the effect of telling CFE to use
the current language version, which is what we want, while also allowing
us to put the right SDK constraint in the package's pubspec.
Change-Id: I51c2952003c83b74fb6f3344c93839fbd267a3ec
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/145020
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Leaf Petersen <leafp@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
This should enable strong mode tests to be fully NNBD opted in. At the
same time, legacy tests when run with the experiment off should
hopefully be able to still consume these libraries because they don't
actually use any NNBD features.
To do this, I changed the script that generates the SDK repo's package
config to not put in a language version for any package whose pubspec
has no SDK version. According to language versioning, that means the
package should be considered to be at the "current" version of the SDK
running the code.
In NNBD, that's opted in. With the experiment off, that is (presumably)
"opted out" in the sense that NNBD doesn't exist.
In order to *not* opt in some of the other packages that currently
lack SDK constraints, I put those in and pinned them to "^2.7.0" which
was what the package config script used to implicitly fill in for them.
I see a bunch of other changes in the generated package config too. The
update script probably hasn't been run in a while.
Change-Id: I55193d42eac0696a6b0105546551efa45a1f3252
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/144305
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Also include the generated output.
Change-Id: Ic2818f544972c737f69913122e366ea48375e950
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/135795
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Auto-Submit: Bob Nystrom <rnystrom@google.com>
