There are still lots of declarations whose name ends in a trailing
digit, but most of them are unrelated to the migration, and some
are required in order to not break internal code.
I'm happy to break this up into smaller CLs if it's hard to review.
Mostly it's just renaming some declarations, although there are one or
two places where I did a little more clean-up.
Change-Id: I50d32316e82e48c6a5a47aec630b4ffee2ead2c8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/410922
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Do not use the folder name as a proxy for the package name.
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-mac-release-try,pkg-win-release-arm64-try,pkg-win-release-try
Change-Id: I17664ea88a4e317d994d93ae84a5584078e5f94d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/410360
Commit-Queue: Moritz Sümmermann <mosum@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Auto-Submit: Moritz Sümmermann <mosum@google.com>
* document_ignores read each file once
* lines_longer_than_80_chars read each file for every line > 80 chars (!).
This follows the approach in
https://dart-review.googlesource.com/c/sdk/+/401424 where the same
pattern was identified as bad.
Before this CL, if a file had, say, 1000 lines > 80 chars (and having
the lint enabled), the lint would read the file - from disk - 1000
times. A somewhat saving grace is that for open files - which I guess is
where it's normally run a lot - it normally reads from an overlay file
and thus not from disk.
Except if you are editing a part in which case the open part is an
overlay, but the "parent" (which is for whatever reason also linted) is
read from file. So if you have 1000 lines > 80 chars in the "parent"
file, and is typing in a part file you're in for a really bad time.
This CL should reduce the number of reads in the lint to 0.
Change-Id: Iac6c78f50add1bc7a411c0c244a181f5ca2ea25b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/411300
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Closes https://github.com/dart-lang/sdk/issues/60109
Both getClassMetadata and getClassesInLibrary can be called before
main is called. In order to support this, libraries should be
initialized so that these debugger APIs can inspect them. Similarly,
SDK libraries that are needed before any code can run should be
initialized. In order to support this, they are initialized on the
first initializeAndLinkLibrary call and reinitialized during a
hotRestart (since the libraries are recreated).
Tests are added to evaluate these methods before main is called.
The debugger test helpers are amended to:
- Support breakpoints within the bootstrap script. This is done by
caching the script and querying to see if it has the breakpoint if
the input sources do not.
- Refactor shared test expectation logic.
- Remove an unused method.
Change-Id: I5534d7008436a51243cf51dba01bb8ad06adca69
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/410602
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
This test recently flipped back to flaky on vm-linux-debug-ia32. I
believe the problem is that calculating `fib(44)` takes a long time on
less powerful machines, which can cause enough samples to get collected
to fill up the sample buffer and cause data to get overwritten.
Issue: https://github.com/dart-lang/sdk/issues/54401
Change-Id: I63b0bdca5b04b066db098c12cfc22845a9b3c9dd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/410781
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Derek Xu <derekx@google.com>
Two new internal ASTs for the CFE representing the entire dot shorthand expression (DotShorthand) and the dot shorthand head (DotShorthandPropertyGet) without arguments.
Static method invocations/constructor calls will be handled later.
Setting up the ASTS first, there's no tests yet. I'll use these in the upcoming CLs.
Bug: https://github.com/dart-lang/sdk/issues/59758
Change-Id: I91a052a3c954a00a424426d3be5c3007aaebc775
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/410902
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Having quick links to pub.dev in pubspec.yaml is a long-standing request, but all of the API options to implemented it seemed bad.
However I was recently made aware that DocumentLinks (which we use for the Flutter example links) support HTTP links and this turns out to be a perfect fit (credit to https://github.com/orestesgaolin for the idea).
Links are built based on the kind of package, so `git` and `hosted` packages will be built accordingly (I special-cased GitHub SSH links but don't know if this could be generalised for other Git-hosting services). We use PUB_HOSTED_URL as the default base for standard Pub packages.
Packages that don't have URLs (such as `path`, `sdk: x` or other unknown kinds) will not produce links.
Fixes https://github.com/Dart-Code/Dart-Code/issues/2785
Change-Id: I1c9e704f67736bbc451866a9e10f7928e2246c7c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/409660
Commit-Queue: Phil Quitslund <pquitslund@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
After writing the new PE header and original section contents of the
dartaotruntime PE executable, pad to the expected file offset of the
new section being added, not just to file alignment.
Also fixes a case where the new section's file offset returned from appendSnapshotAndWrite could be incorrect if the header size changed, which causes the file offsets for all sections, including the new one,
to be updated.
TEST=pkg/dartdev/test/commands/compile_test.dart
Change-Id: I060176f6771e9138f8d1a99590d455fc76bb573e
Cq-Include-Trybots: luci.dart.try:pkg-win-release-try,pkg-win-release-arm64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/410720
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
**TL;DR**
In certain situations a new signature was created for every
analyzer start causing more work than needed to be done and filling up
the cache for no reason. The fix can cause the startup cost to improve
significantly.
**Details**
When merging analysis options yaml files (when one file includes
another), and both include data under "analyzer: errors:" we get
inconsistent signatures because of ordering issues. This causes "old
work" to be redone and more files to be written.
This CL fixes the issue by not introducing a semi-random order when
merging.
For the contexts I have open, the following files gives (gave) a bad
(inconsistent) signature:
pkg/analyzer/test/analysis_options.yaml
pkg/front_end/analysis_options.yaml
pkg/analysis_server/test/analysis_options.yaml
Looking at the time it takes from the first read/write until the last:
Before:
37.148419
37.273016
36.807384
Now:
14.164655
15.251373
15.108677
While the difference is easily visible, for good measure:
```
Difference at 95.0% confidence
-22.2347 +/- 1.0223
-59.9702% +/- 2.7573%
(Student's t, pooled s = 0.45103)
```
And from the column "time" in top (note that I'm running from source so
that this includes the initial dart compile of the analyzer):
Before:
1:10.84
1:09.81
1:26.98
Now:
0:38.03
0:38.72
0:37.79
Again the difference is easily visible, but for good measure:
```
Difference at 95.0% confidence
-37.6967 +/- 15.4529
-49.6815% +/- 20.3658%
(Student's t, pooled s = 6.81767)
```
If clearing the cache and opening (waiting for writes to complete),
closing and repeating, before this CL I got this with the contexts I
have open:
After 1st open:
```
$ du -chs ~/.dartServer/
186M total
```
After the 2nd open:
```
$ du -chs ~/.dartServer/
212M total
```
=> +26MB
After the 3rd open:
```
$ du -chs ~/.dartServer/
247M total
$ find ~/.dartServer/ | wc -l
25713
```
=> +35MB
After the 4th open:
```
$ du -chs ~/.dartServer/
272M total
$ find ~/.dartServer/ | wc -l
27769
```
=> +25MB; +2056 files
After the 5th open:
```
$ du -chs ~/.dartServer/
297M total
$ find ~/.dartServer/ | wc -l
29825
```
=> +25MB; +2056 files
After the 6th open:
```
$ du -chs ~/.dartServer/
321M total
$ find ~/.dartServer/ | wc -l
31881
```
=> +24MB; +2056 files
And we seem to have reached a point where we can guess the 7th if we want to.
And with the fix in this CL:
After 1st open:
```
$ du -chs ~/.dartServer/
186M total
$ find ~/.dartServer/ | wc -l
20816
```
After 2nd:
```
$ du -chs ~/.dartServer/
186M total
$ find ~/.dartServer/ | wc -l
20816
```
After the 3rd:
```
$ du -chs ~/.dartServer/
186M total
$ find ~/.dartServer/ | wc -l
20816
```
And it seems that it's stable.
We might also want to sort the strings as ordering (probably?) doesn't
matter, but I'll leave that for another CL.
Change-Id: Id06ca84e8b063bb31a261753f56620443f341a2e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/410700
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
The earliest supported language version in current SDK releases is 2.12.
Information about the first version supporting an API is not useful for
that or any earlier language versions. Remove the annotations to reduce
noise in API docs.
R=lrn@google.com
Change-Id: Ide0b2a7f02bba6f9c261a01c7b9d4a48f5c71c2b
CoreLibraryReviewExempt: No behavior changes.
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/405821
Auto-Submit: Nate Bosch <nbosch@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Brian Quinlan <bquinlan@google.com>
Danny Tuppeny