This is similar to the analyzer backend's optimization for fields, but
it also supports private methods and accessors.
Also fixes#34769, checks were missing for explicit covariant fields
and those are now generated (this is for fields of the form
`covariant SomeType fieldName`--implicitly covariant fields in generic
classes were already checked correctly).
Change-Id: I5ce3ed7944bdc5a9799c731c5f95e199b461b079
Reviewed-on: https://dart-review.googlesource.com/c/79432
Commit-Queue: Jenny Messerly <jmesserly@google.com>
Commit-Queue: Alan Knight <alanknight@google.com>
Auto-Submit: Jenny Messerly <jmesserly@google.com>
Reviewed-by: Alan Knight <alanknight@google.com>
The new file pkg/dev_compiler/lib/src/analyzer/driver.dart handles
building the linked summary for a build unit, and then is capable of
doing analysis using LibraryAnalyzer.
The algorithm is very similar to analyzer_cli's build mode. The
biggest difference is that `dartdevc` has existing support for
discovering source files from the explicit source list (rather than
requiring every source to be listed on the command line). We don't want
to break that support, so there's a bit of logic to follow imports,
exports, and parts.
After the linked summary is produced, DDC gets the analysis results
(errors and resolved AST) for each library, and compiles it into a JS
module.
Change-Id: I7bf1ce1eca73fd036002e498de5924c488b534dc
Reviewed-on: https://dart-review.googlesource.com/c/82469
Commit-Queue: Jenny Messerly <jmesserly@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
The small diamond from `boolOrNull ?? false` can become a fast comparison:
boolOrNull == null ? false : boolOrNull --> boolOrNull == true
The straight-line code is then available for other optimizations, e.g. generate-at-use placement.
Change-Id: I7a14705a82eda4c716ee600ccca44e6658187649
Reviewed-on: https://dart-review.googlesource.com/c/56160
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
This reduce the memory footprint and cost of parsing these extensions. Another
advantage is a reduction on the size of the .map files. On a large customer
app, this was a 11% reduction, and the frames section was about 1Mb (excluding
the extra names and uris added on the existing tables).
The encoding works as follows:
- minified names are written as a list of names and indices, in pairs.
{'n1': 1, 'n2': 2} => 'n1,1,n2,2'
- frames are encoded using a sequence of values with markers for the different
kind of frames. Numbers are encoded using VLQ deltas. We use VLQ because it's
already available to any parser that deals with the mappings).
This change also uses the dart2js_tools parser implementation for all unit tests.
Change-Id: Iacc2833c6517eb473955cc618adec501c610870f
Reviewed-on: https://dart-review.googlesource.com/c/82780
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Changes include:
* Added a couple no-such-method decoders.
* Apply deobfuscation rules more than once per line
* Fixed pattern matched for minified names.
* Added support for expanding the call signature from call selectors
* Fix backward search to find the function declaration
* Refactor trace deobfuscation logic:
* add dependency on stack\_trace to parse frames
* add library to expose trace deobfsucation and keep that separate from
printing the results
* Fix off-by-one error when extracting the name of a function whose index is 0.
* Avoid crash if we can't get a function name.
Change-Id: I016a293efadbdd8ddf66a007b182d5485eb2311f
Reviewed-on: https://dart-review.googlesource.com/c/82711
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Auto-Submit: Sigmund Cherem <sigmund@google.com>
This reverts commit feba863557.
Reason for revert: for now, we want this change on the analyzer branch only.
Original change's description:
> Import path as p, in Workspace impl libraries
>
> In package_build.dart, there are several spots (builtFile(),
> builtPackageSourcePath(), ...) where `context` is called, in cases
> where I imagine the author thought there was a class member at hand
> (as is the case with PackageBuildPackageUriResolver), but these
> locations are actually using the top-level const `context` from the
> path package.
>
> I think it is super confusing to have class members, and local
> variables, that shadow an imported top-level const. Better to import
> with a prefix.
>
> Additionally, I unified relative/absolute checking in these files as
> assert() calls, with helpful messages.
>
> Change-Id: I6d409636dab41959cabf392c80f64c4ec5270f7b
> Reviewed-on: https://dart-review.googlesource.com/c/82560
> Commit-Queue: Samuel Rawlins <srawlins@google.com>
> Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
TBR=scheglov@google.com,brianwilkerson@google.com,srawlins@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: I03ee1a3d3f358f8a7ac6ddad5f1b3a2e5991468f
Reviewed-on: https://dart-review.googlesource.com/c/82900
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
In package_build.dart, there are several spots (builtFile(),
builtPackageSourcePath(), ...) where `context` is called, in cases
where I imagine the author thought there was a class member at hand
(as is the case with PackageBuildPackageUriResolver), but these
locations are actually using the top-level const `context` from the
path package.
I think it is super confusing to have class members, and local
variables, that shadow an imported top-level const. Better to import
with a prefix.
Additionally, I unified relative/absolute checking in these files as
assert() calls, with helpful messages.
Change-Id: I6d409636dab41959cabf392c80f64c4ec5270f7b
Reviewed-on: https://dart-review.googlesource.com/c/82560
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
The API change requires adding a "context" parameter to
NodeLintRule.registerNodeProcessors. If we did this naively it would
be a breaking change since the existing linter code overrides this
method with an implementation that doesn't accept such a parameter.
So to avoid making this a breaking change, we introduce a new
interface NodeLintRuleWithContext that extends NodeLintRule, and adds
the context to the registerNodeProcessors method as an optional
parameter. The analyzer will only pass in the new parameter if the
lint rule implements the new interface; otherwise it will call the
method in the old way. This will allow the linter to be migrated to
use the new API at its pace.
The next breaking change version of the analyzer will change both
NodeLintRule and NodeLintRuleWithContext so that the context parameter
is required, and will pass in a context unconditionally. At a later
date, after the linter has been fully migrated to the new analyzer
version, we will be able to switch back to NodeLintRule and deprecate
NodeLintRuleWithContext.
Change-Id: I75ada0e94e26f831d6f2cb82cddfa706100eb185
Reviewed-on: https://dart-review.googlesource.com/c/82522
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Mixin declarations cannot be instantiated or extended, so they should
not have constructors. Adding a compiler-generated constructor causes
us to try to add an invocation of the default superclass constructor.
Because the superclass constraint is encoded as a superclass this can
cause a spurious error that is impossible to fix.
Fixes https://github.com/dart-lang/sdk/issues/35011
Change-Id: Ia8f99d00b1a5b042da233d54f3cc1f0c6345e779
Reviewed-on: https://dart-review.googlesource.com/c/82447
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Before, e.g.
```
main() {
L: var x, y;
x = 42;
y = x;
}
```
would produce something like
```
static method main() → dynamic {
{
dynamic x;
dynamic y;
}
x = 42;
y = x;
}
```
i.e., the variable declaration was in another scope, and their usage
isn't legal.
This CL fixes that by either
a) (the normal case) not wrapping it --- the label is not used anyway.
b) (the case that cannot happen) put a label on the first part so the
output would be something like
```
L: dynamic x;
dynamic y;
x = 42;
y = x;
```
Fixes#34943.
Change-Id: I24132665dab53fb8fb024f73dd11e0d1f1945812
Reviewed-on: https://dart-review.googlesource.com/c/82063
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
This fixes a crash in dump-info. We should investigate more closely why are we
reaching the empty output units in the first place, since we expect dump-info
wouldn't need to report data about any entity that used to be there.
Change-Id: I8c996c4ea4a86531bec28f0f294fe48086177219
Reviewed-on: https://dart-review.googlesource.com/c/82280
Reviewed-by: Harry Terkelsen <het@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Updates to dartfix for publication including:
* add changelog, readme, and license
* update pubspec version and executables
along with a collection of smaller changes including:
* test cleanup
* remove duplicate time value from verbose output
* read dartfix pubspec version and pass that to analysis server
Change-Id: Ifa94df45e6cbcf9a98f7bf393c22e06eaab48c38
Reviewed-on: https://dart-review.googlesource.com/c/82240
Commit-Queue: Dan Rubel <danrubel@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Jenny Messerly