2021-08-09 sgrekhov@unipro.ru 1126. Different roll failures fixed
2021-08-09 sgrekhov@unipro.ru 1100. Fix Link.watch() test to avoid flakiness
2021-08-09 sgrekhov@unipro.ru Fixes 1128. Remove check for '!identical(v1, v2)'
2021-08-06 sgrekhov@unipro.ru 1126. Some of the roll failures fixed or issue numbers added
2021-08-06 sgrekhov@unipro.ru 1127. Expect compile-time errors in CFE for cyclic redirecting factories participating in a loop
2021-08-06 sgrekhov@unipro.ru 1126. Some of the roll failures fixed
2021-08-04 irina.arkhipets@gmail.com Useless libraries removed.
2021-08-04 sgrekhov@unipro.ru 993. PointerPointer tests added
2021-08-03 sgrekhov@unipro.ru 993. IntPtrPointer tests added
2021-08-03 sgrekhov@unipro.ru 993. Work with memory fixed in FFI tests
2021-08-02 sgrekhov@unipro.ru 993. Int64Pointer tests added for FFI library
2021-07-30 sgrekhov@unipro.ru Fixes 993. IntXXPointer tests added for FFI library
2021-07-30 sgrekhov@unipro.ru 1087. More tests for tearing-off constructor of an abstract class
2021-07-29 sgrekhov@unipro.ru Fixes 993. DoublePointer tests added for FFI library
2021-07-29 sgrekhov@unipro.ru Fixes 993. More Union tests for FFI library added
2021-07-28 sgrekhov@unipro.ru Fixes 1125. Test for cascades contained explicitly instantiated tearoffs added
2021-07-28 sgrekhov@unipro.ru 1087. Header comment style fixes
2021-07-27 sgrekhov@unipro.ru 1087. Add tests for tearing-off constructor of an abstract class
2021-07-27 sgrekhov@unipro.ru Fixes 1124. Constructor tear-off tests fixed
2021-07-26 sgrekhov@unipro.ru 1124. Numerous errors and typos in Constructor tear-off tests fixed
2021-07-21 irina.arkhipets@gmail.com Issue 1119: test corrected.
2021-07-20 irina.arkhipets@gmail.com Issue 1109: Libraries_and_Scripts test updated, new tests added.
2021-07-20 sgrekhov@unipro.ru 1123. Constructor tear-off tests fixed to expect syntax errors
2021-07-20 sgrekhov@unipro.ru 1123. Expect syntax errors in tests which check syntax
2021-07-19 sgrekhov@unipro.ru Missed checks added to Language/Generics/syntax_t31 test
2021-07-19 sgrekhov@unipro.ru 1123. Expect syntax errors in tests which check syntax
2021-07-19 sgrekhov@unipro.ru 1123. Syntax error fixed in unnamed constructor tear-off tests
2021-07-19 sgrekhov@unipro.ru 1122. nonfunction-type-aliases tests moved out of type-aliases directory
2021-07-16 sgrekhov@unipro.ru 1122. nonfunction-type-aliases experimental flag removed
2021-07-16 sgrekhov@unipro.ru 1122. nonfunction-type-aliases experimental flag removed
2021-07-15 sgrekhov@unipro.ru Fixes 1121. Update Symbol tests according to the changed specification
2021-07-14 sgrekhov@unipro.ru 932. Issue number added
2021-07-14 irina.arkhipets@gmail.com Fixes 1109: test expectations corrected according to dart-lang/sdk44161, dart-lang/sdk44163 evaluations.
2021-07-14 sgrekhov@unipro.ru 1120. Added test which uses type aliases
2021-07-13 sgrekhov@unipro.ru 993. NativeFunction test added
2021-07-12 sgrekhov@unipro.ru Fixes 1107. Replace multitests by static errors tests
2021-07-12 sgrekhov@unipro.ru 1120. Tests for mixin static members added
2021-07-09 sgrekhov@unipro.ru Fixes 1120. Tests for function object canonicalization added
2021-07-08 sgrekhov@unipro.ru Fixes 1087. More constructor tear-offs tests added
2021-07-07 sgrekhov@unipro.ru 1087. More constructor tear-offs tests added
2021-07-06 sgrekhov@unipro.ru 1087. Added tests that checks factory constructor tear-offs and use of tear-offs in a factory constructors
2021-07-06 sgrekhov@unipro.ru Fixes 1118. Expect an error for Union/Struct subclasses created by generative constructor
2021-07-05 sgrekhov@unipro.ru Fixes 1111. Expect an error for zero-sized arrays
2021-07-05 sgrekhov@unipro.ru Fixes 1116. Expect a compile error for empty setOrMapLiteral for Iterable<Object> context type
2021-07-05 sgrekhov@unipro.ru Fixes 1112. Expect a compile error if mixin is derived from a class other than Object
2021-07-05 sgrekhov@unipro.ru Fixes 1105. Function tear-offs tests fixed
2021-07-05 sgrekhov@unipro.ru Fixes 1106. Use runtime check 'is int' VS 'is String' to check that runtime type is 'int', not 'dynamic'
2021-07-01 irina.arkhipets@gmail.com Fixes 1113: Method signature corrected.
2021-07-01 irina.arkhipets@gmail.com Fixed Issue 1115: test expectation corrected.
2021-07-01 irina.arkhipets@gmail.com Fixes Issue 1117: test corrected.
2021-06-29 irina.arkhipets@gmail.com Issue 1094: Merge changes from pre-nnbd branch.
2021-06-25 sgrekhov@unipro.ru 1087. Added tests for static invocations and type object member ambiguity
2021-06-25 sgrekhov@unipro.ru 1104. Fix type used in onError
2021-06-24 sgrekhov@unipro.ru 1087. Added more tests for resolving ambiguities
2021-06-23 sgrekhov@unipro.ru 1087. Added more tests for resolving ambiguities
2021-06-22 sgrekhov@unipro.ru 1087. Added more tests for resolving ambiguities
2021-06-22 sgrekhov@unipro.ru Fixes 1103. Change expected error range for analyzer according to the changed behaviour
2021-06-22 sgrekhov@unipro.ru Fixes 1102. Change test expected results according to the changed behavior
2021-06-21 sgrekhov@unipro.ru 1087. Added more tests for resolving ambiguities
2021-06-21 sgrekhov@unipro.ru Issue number added to the failing test
2021-06-21 sgrekhov@unipro.ru Fixes 1101. Expect less compile errors
2021-06-18 sgrekhov@unipro.ru 1087. Resolving ambiguities tests added
2021-06-17 sgrekhov@unipro.ru 1087. Resolving ambiguities tests added
2021-06-17 sgrekhov@unipro.ru 1087. Call-method tests added
2021-06-15 sgrekhov@unipro.ru Fixes 1100. Expect file system event not on link itself but on directory it points to
2021-06-15 sgrekhov@unipro.ru 1099. Fixed co19 roll failures
Cq-Include-Trybots: dart/try:analyzer-nnbd-linux-release-try,dart2js-nnbd-linux-x64-chrome-try,ddc-nnbd-linux-release-chrome-try,front-end-nnbd-linux-release-x64-try,vm-kernel-nnbd-linux-debug-x64-try,vm-kernel-nnbd-linux-release-simarm64-try,vm-kernel-nnbd-linux-release-x64-try,vm-kernel-nnbd-mac-release-arm64-try,vm-kernel-nnbd-win-release-x64-try,vm-kernel-precomp-nnbd-linux-release-simarm64-try,vm-kernel-precomp-nnbd-linux-release-x64-try,vm-kernel-precomp-nnbd-win-release-x64-try
Change-Id: Ib18e48d31771b2b70e607951577b9ac90d0b40a6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/209547
Reviewed-by: William Hesse <whesse@google.com>
pkg/dart2js_info will soon contain a checked-in version of dart2js_info
that will eventually replace third_party/pkg/dart2js_info. Until that
happens, pkg/dart2js_info should be ignored.
Change-Id: I337d69b6ee58b1ec0f436a199c81828dfd391ec8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/209900
Auto-Submit: Alexander Thomas <athom@google.com>
Commit-Queue: Alexander Thomas <athom@google.com>
Commit-Queue: William Hesse <whesse@google.com>
Reviewed-by: William Hesse <whesse@google.com>
This should handle all cases of constructor reference w/ explicit type
args; there aren't too many cases:
* named and unnamed constructors
* referencing class and referencing type alias
* prefixed class names and not-prefixed
* null-aware access (weird)
* bound on type parameter of class, and on type parameter of alias
error cases:
* cascade
* wrong number of type arguments
Bug: https://github.com/dart-lang/sdk/issues/46020
Change-Id: If257eb561a9ad854709b6e9a7d81faa9d084d6ee
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/209622
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This fixes a huge performance regression (introduced in [0]) of a
synthetic microbenchmark - MicroClosureCreateTearoffClassSecondTime -
that happens to have a gigantic function with a large number of call
sites in them.
All of those call sites stay monomorphic but all of them will have to
go to runtime for miss handler because the target code was disabled (the
unoptimized code got disabled, since optimized target code was
installed). The particular target function in question is
`_GrowableArray.add()`.
The cause for the regression is that the miss handler will lookup the
ICData based on linearly walking PcDescriptors to find deopt-id which it
uses to get ICData from function's ic-data array.
Interestingly enough it only regresses ia32 but not x64 (the only two
architectures this benchmark is run on). The reason for that is that
x64 uses exactness tracking and therefore doesn't switch to
monomorphic calls.
This CL:
If a monomorphic call site had a miss because the cached old target
was disabled, we go to runtime to find the real target. Another thread
may have transitioned the call site already from monomorphic to
polymorphic.
When resolving the target function we take advantage of a back reference
from the `ICData::entries()` back to the `ICData` to avoid the O(N)
lookups.
[0] https://dart-review.googlesource.com/c/sdk/+/206373
TEST=Existing test suite.
Change-Id: Ia066a846f5f50e5a575f0734c9453d2368f80780
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/207133
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
This does not handle more specific function types (those represented
using FunctionType objects), but just Type::DartFunctionType().
TEST=vm/cc/TTS_Function
Change-Id: I42ddd8818da5331eed748784b051cd2c78547b5b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/209703
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
Of the two classes that inherit from ScopedVisitor (ResolverVisitor
and ScopeResolverVisitor), only ResolverVisitor needs to know about
the currently enclosing class, extension, and function. So we move
this tracking logic to the ResolverVisitor itself. This will help
pave the way for a cleaner separation between the ResolverVisitor and
ScopeResolverVisitor.
(The ScopeResolverVisitor *does* need to know the currently enclosing
closure, so that it can detect improper break/continue statements and
so that it can detect when a local variable is mutated in a closure,
but the tracking logic needed for this is much simpler than what the
ResolverVisitor needs for the "enclosing function". So a new
_enclosingClosure member has been added to ScopeResolverVisitor to
track this.)
Change-Id: I768c15ff4ffcabf564388f5471a6e8f88e677148
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/209665
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
This is the beginning of an arc of work to move the responsibility of
all the analyzer's scope-based resolution into a single class.
VariableResolverVisitor will become that class, so accordingly it's
being renamed to ScopeResolverVisitor.
In the long term, this shift of responsibility will bring the analyzer
and the CFE into better alignment by removing scope resolution logic
from the type analysis phase (the CFE performs all scope resolution
during parsing, and then has a single visit pass to do type analysis).
This should allow analyzer and CFE logic to be more readily shared.
Also, it should improve the performance of the analyzer by allowing
Scope objects to be built up in just a single visitor pass rather than
in multiple visitor passes.
Change-Id: I037346d28de6485cac783e2bc65e0de9d3a2ada6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/208661
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This CL refactors the scope lookup logic for simple identifiers so
that it happens in three phases:
- The actual lookup, handled by Scope.lookup
- Choosing which element is being referred to, handled by the
LexicalLookup class
- If lexical lookup failed, falling back on implicit `this` lookup,
handled by the ThisLookup class
In a future CL, this will allow us to consolidate the first phase,
along with all other scope-related operations, into a single visitor
so that the ResolverVisitor no longer needs to maintain scopes. This
should simplify the analyzer's scoping logic and help prepare for
sharing more code with the CFE (since it will make the analyzer's
visitors more closely parallel the analysis phases of the CFE).
Change-Id: I0c8a2aa60bfc5a935b6060adf64e5a4504bc268f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/209664
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Document that only `const` invocations are guaranteed to work.
(But leave open the door that some platforms might allow `new`.)
Thanks to @irvine5k for the initial work (see #46846).
Change-Id: I16ad26186e91898cf1dc2922a492ce4eb0dac207
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/209543
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Previously, the code in the TypeCheck runtime entry assumed that if a
lazily specialized type testing stub (TTS) returned a false negative in
JIT mode, that it should always be regenerated and that regeneration
would always result in different code. In AOT mode, false negatives
instead always cause the stub to go to runtime, even if that false
negative had been seen before, because the assumption is that false
negatives shouldn't happen when the whole class hierarchy is known at
compile time.
However, even in the current implementation of optimized TTSes, there
are cases where this assumption is false. For example, the code
generated by BuildOptimizedSubclassRangeCheckWithTypeArguments allows
for provided type arguments to be type parameters. When this happens,
the type parameter is instantiated at runtime using the instantiator or
function type arguments, and the instantiated type parameter must be
identical to the result retrieved from the type arguments of the
instance. That means that if the instantiated type parameter is not the
same type, but a supertype, of the result, then a false negative is
generated.
This CL changes TypeCheck's handling of false negatives from lazily
specialized TTSes as follows: in JIT, if the regenerated stub is the
same as the old stub, or in AOT, a false negative causes the same fall
back to SubtypeTestCaches as unoptimized stubs. This way, further
checks with the same false negative will be caught via the STC before
going to runtime, assuming the STC hasn't already filled up with false
negatives.
Currently, we only generate false negatives for reasons that will not
change when respecialization occurs due to additions to the hierarchy,
so we do not need to clear affected STCs during respecialization.
However, the previous approach to resetting STCs on reload (in
CallSiteResetter::ResetCaches) is insufficient, since there may be
caches containing reloaded types in non-reloaded code (like the TTS
invoker stub created by the TTS testing framework). Instead, clear
all caches on reload using the same ObjectVisitor as deoptimizing type
testing stubs.
Since we now have to check instruction equality to determine whether
to add to the STC, we now only replace the existing stub if the
instructions are different. This makes it easier to test whether a
TTS invocation on a false positive caused respecialization or not.
This CL also reworks the testing framework for type testing stubs,
1) creating a test case object that stores the particulars of a given
invocation, including expectations, and 2) moving most checks and
access to appropriate data structures into a state object that handles
setup and performing invocations given test cases.
TEST=vm/cc/TTS_Partial
Cq-Include-Trybots: luci.dart.try:vm-kernel-linux-release-x64-try,vm-kernel-precomp-linux-release-x64-try,vm-kernel-precomp-nnbd-linux-release-x64-try,vm-kernel-nnbd-linux-release-x64-try,vm-kernel-tsan-linux-release-x64-try,vm-kernel-linux-product-x64-try,vm-kernel-precomp-linux-product-x64-try,vm-kernel-linux-release-simarm-try,vm-kernel-linux-release-simarm64-try
Change-Id: I139608c5a0f2442a85a1cf39d1c04104db7a5593
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/208653
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
The transitive copy algorithm was missing support for [WeakProperty]s,
thereby ensuring that we only copy the values if the keys are reachable.
Furthermore we might need to re-hash [Expando]s - since the copied
objects start with no identity hash codes.
The CL also makes us avoid calling to Dart for each [Expando]
separately and instead use a list - just as we do in the re-hashing of
maps/sets.
We also move the C++ code to invoke rehashing logic into
DartLibraryCalls::*.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=vm/dart{,_2}/isolates/fast_object_copy{,2}_test
Change-Id: I836745feef8a6d7573faa94e29a19c1eca0c39f2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/209106
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Currently, if a type parameter of a class, mixin, or extension
declaration has an annotation, that annotation is resolved in the type
parameter scope of the class, mixin, or extension declaration (meaning
that static methods are not in scope), however if scope lookup fails,
then static methods are accessible via implicit `this`.
AFAICT, this odd behavior is not spec compliant, so I've filed
https://github.com/dart-lang/language/issues/1790 to discuss the
possibilty of changing it. However, for now I want to unit test the
behavior in order to ensure that if we make any changes to the
analyzer that affect it, the change won't go unnoticed.
Bug: https://github.com/dart-lang/language/issues/1790
Change-Id: I02df7e6e8939ecc6222085f28a6d6b7d072179c1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/209662
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Cloning of InstanceInvocation kernel ast nodes was dropping the
isInvariant and isBoundSafe flags, causing the nested List.generate
expansion to not be as well optimized. `-O3` and `-O4` were 'hiding'
the problem by removing the checks anyway.
Change-Id: Id20f2eb4ef5396691a2dd5cbdd847e2d361a21d0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/209442
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Alexander Thomas