Work towards https://github.com/dart-lang/sdk/issues/50986
Various classes have mutable fields which should be final. Some of the
fixes require using factory constructors:
* _PSDependency, _PSEnvironment, _PSGitRepo, _PSHost, _Pubspec
* _PSNode: resourceProvider can be private and non-null
* Doc comments tidied here and there
Change-Id: Ib11a059e72670c80a4172e1c688493c1067328c8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/429582
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
In a recent discussion we decided to add an `experiment` key to the
entries in the analyzer's `messages.yaml` file with the same semantics
as they have in the front-end messages file. This is an initial attempt
to add them.
I'm reasonably confident that all of the markes diagnostics are related
to the specified experiment, but there might well be others. I'm happy
to update this CL to capture those as well, but we can always add the
map entry later as we discover diagnostics that were missed.
Change-Id: I31ec94bae905828e64a1769fdf905ef7a19a8d11
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/430120
Reviewed-by: Kallen Tu <kallentu@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This PR enables native assets on the main and dev channel by default,
and make native assets available on the beta channel.
This PR removes the flag from invocations.
The helper packages (`package:hooks` and `package:code_assets`) will
stay 0.x for now, until the SDK constraint can be bumped to a beta
release and we're happy with the Dart API.
`dart build` is also made available as preview (without a flag on
the main, dev, and beta channels). We're still finalizing the spec for
this command. (https://github.com/dart-lang/sdk/issues/60730)
`dart test` will need https://github.com/dart-lang/test/pull/2501.
This means users will need to update their `package:test` dependency.
This PR refactors the way that invalid `package_config.json`s are
handled: they are now loaded in the dartdev commands and handled there.
Bug: https://github.com/dart-lang/sdk/issues/50565
Project: https://github.com/orgs/dart-lang/projects/99/
Change-Id: I7db9ff6d7196750cab9379a4605c6bbf89a974d7
Cq-Include-Trybots: luci.dart.try:pkg-linux-debug-try,pkg-linux-release-arm64-try,pkg-linux-release-try,pkg-mac-release-arm64-try,pkg-win-release-arm64-try,pkg-mac-release-try,pkg-win-release-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/429920
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
The ElementDisplayStringBuilder crash when encountering a type parameter
without a name. This chance handles the case by using the empty string as
the name in the computation of unique type parameters.
Fixes b/418755155
Change-Id: I4fd1a6df64a31614e0c4548963d0c5507cc94ca8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/429640
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This makes it easier for me to find diagnostics that still need to be
documented because I can search for 'hasPublishedDocs: false'. It's
hard to search for places where it isn't specified.
In case you're interested, we currently have documentation for 70% of
the diagnostics represented in this file.
In almost every case the value is `false`, but there are two codes whose
documentation has already been published but which were not marked as
such. This means that we weren't associating a URL with the diagnostic,
but that's now been fixed.
Change-Id: I4e17671e319ec8e8887aacb6758594d7962bfc85
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/429202
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This was previously available as an extension on this class, but we
control the class quite directly. Seems like it should just be an API
of LinterContext.
Change-Id: I9fb61ab4471e859c39d9fa963eed2a3839fca617
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/428925
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
* All callers are migrated off of `AbstractAnalysisRule.lintCodes`
and `.reporter`.
* All callers are migrated off of `AnalysisRule.lintCode`.
Change-Id: I4123250c33ff1d0a488bd4457cfe5fc13160e829
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/429121
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
In VSCode, when the user hovers over a reference to `dart:core`
(e.g. an instance of a core type such as `String`), this triggers
VSCode to briefly open, and then close, one of the core files defining
the SDK; this in turn causes it to send notifications to the analysis
server to create and then destroy an overlay for the core SDK file.
This leads to a somewhat rare race condition: if the analyzer pumps
its event queue between receiving the notifications to create and
destroy the overlay, and there isn't adequate time in between these
two events for all active analysis drivers to re-build their library
readers, then what will happen is that
`LinkedElementFactory.removeLibraries` will get passed a `uriSet` that
contains `dart:core` but not `dart:async`. (The reason is because the
driver hasn't yet rebuilt the library cycles, so it doesn't know that
`dart:core` and `dart:async` are in the same cycle).
Before this change, `LinkedElementFactory.removeLibraries` contained a
safety check that would throw an exception if the `uriSet` ever
contained `dart:core` but not `dart:async`. Due to the race condition,
this safety check would occasionally fire, crashing the analyzer. (On
my machine, the crash would occur about once per day on average).
This safety check was incorrect (since it checked for a condition that
was thought never to occur, but in fact does occur). Also, it was not
necessary; since the only way for the race condition to occur is if
the driver hasn't yet rebuilt its library cycles, there is no harm in
removing just `dart:core` and not `dart:async`, as both have
previously been removed. And, indeed, the incorrect safety check has
always been followed by a (correct) safety check making sure that if
`dart:core` is ever removed, then after the removal, the set of
library readers is empty.
For the last month, I've been running a local build of the analyzer
with the incorrect safety check removed, and I haven't observed any
crashes.
Fixes https://github.com/dart-lang/sdk/issues/48051.
Bug: https://github.com/dart-lang/sdk/issues/48051
Change-Id: I611269ea7596cc63af5eb77d5baf641454a9d315
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/428902
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Konstantin Shcheglov