The issue derives from the fact that `parameterStructure` has only the preserved parameters,
however the SSA was emitting values for all arguments.
I fixed this by emitting all parameters. I also noticed that the parameter order should
probably be the native-ordering here as well (it doesn't matter for the factory, but it may
matter for other static native calls, if any)
Bug: https://github.com/dart-lang/sdk/issues/35916
Change-Id: I2e93c7f8e3baf5c9285107d23786bb3bf4f3a511
Reviewed-on: https://dart-review.googlesource.com/c/92626
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Currently assuming that the language team chooses option 2 for
https://github.com/dart-lang/language/issues/156#issuecomment-460525075.
To handle the case where the user does not specify a default value,
and all call sites supply the named parameter, there are two possible
heuristics:
- assumeNullable: mark the parameter as nullable, since the implicit
default is `null`, even though the implicit default is never used.
- assumeRequired: consider the parameter to be `@required`, ensuring
that the implicit default will never be used.
I've provisionally chosen `assumeRequired` as the default behavior.
Functionality not yet implemented:
- If `@required` is already present in the source code, this should
override the heuristic; also it should not be added again.
- If the parameter is already marked as nullable in the source code,
this should override the heuristic.
- Uses of `@required` should be translated to `required`.
- If `@required` is already present in the source code, and a default
value is supplied, the default value should be removed.
- If the parameter is used in a way that demonstrates it was intended
to be non-nullable (i.e. it appears in a place in unconditional
control flow that would cause an exception to be thrown if it was
null), this should override the heuristic and cause it to be marked
as `@required`.
Change-Id: I9f2ec63787fdb6215e6075ecfcc830ed9942b8b5
Reviewed-on: https://dart-review.googlesource.com/c/92532
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
To support separate compilation in DDC, the constant evaluator would
leave instantiations through unavailable constructors unevaluated.
These constructors were identified by being in an external library and
having no initializers. This check erroneously triggered on
"const Object()", breaking the bytecode generator.
Change-Id: I73c10982a36086a431e9fbd54d67cbcde90df68e
Reviewed-on: https://dart-review.googlesource.com/c/92721
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Sometimes there is no difference between 'relevance' and 'relevanceBoost',
for example for enum constants. But for primitive constants, there might
be multiple `double` constants, in different libraries with their own
different relevances. And it would be nice to keep relative relevances
of these libraries in primitive type constants.
R=brianwilkerson@google.com
Change-Id: I3641a4709e09f5c5dd979f5ca8df7b0235c708d2
Reviewed-on: https://dart-review.googlesource.com/c/92623
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Previously, if failing when trying to load from a dill it would say
something like
Warning: Tried to initialize from a previous compilation
(build/app.dill), but couldn't. Error message was
'NoSuchMethodError: The method 'getReference' was called on null.
Receiver: null
Tried calling: getReference()'. This might be a bug.
The Dart team would greatly appreciate if you would take a moment to
report this problem at http://dartbug.com/new.
Which really doesn't give us a lot to go on.
This CL changes that to also give us a little go to on, and report
something like
Warning: Tried to initialize from a previous compilation
(org-dartlang-test:///initializeFrom.dill), but couldn't.
Error message was 'NoSuchMethodError: The method 'getReference' was
called on null.
Receiver: null
Tried calling: getReference()'. Stacktrace included '#0 Object.noSuchMethod (dart:core/runtime/libobject_patch.dart:50:5)
#1 BinaryBuilder.readLibraryReference (package:kernel/binary/ast_from_binary.dart:692:9)
#2 BinaryBuilder.readLibraryDependency (package:kernel/binary/ast_from_binary.dart:837:25)
#3 BinaryBuilder._readLibraryDependencies (package:kernel/binary/ast_from_binary.dart:829:33)
#4 BinaryBuilder.readLibrary (package:kernel/binary/ast_from_binary.dart:803:5)
#5 BinaryBuilder._readOneComponent (package:kernel/binary/ast_from_binary.dart:634:7)
#6 BinaryBuilder.readComponent (package:kernel/binary/ast_from_binary.dart:441:7)
#7 IncrementalCompiler.initializeFromDill (package:front_end/src/fasta/incremental_compiler.dart:395:14)
<asynchronous suspension>
#8 IncrementalCompiler.computeDelta.<anonymous closure> (package:front_end/src/fasta/incremental_compiler.dart:126:23)
<asynchronous suspension>
#9 CompilerContext.runInContext.<anonymous closure>.<anonymous closure> (package:front_end/src/fasta/compiler_context.dart:120:46)
#10 new Future.sync (dart:async/future.dart:224:31)
#11 CompilerContext.runInContext.<anonymous closure> (package:front_end/src/fasta/compiler_context.dart:120:19)
#12 _rootRun (dart:async/zone.dart:1124:13)
#13 _CustomZone.run (dart:async/zone.dart:1021:19)
#14 _runZoned (dart:async/zone.dart:1516:10)
#15 runZoned (dart:async/zone.dart:1463:12)
#16 CompilerContext.runInContext (package:front_end/src/fasta/compiler_context.dart:119:12)
#17 IncrementalCompiler.computeDelta (package:front_end/src/fasta/incremental_compiler.dart:108:20)
<asynchronous suspension>
#18 initializedCompile (file:///usr/local/google/home/jensj/code/dart-sdk/sdk/pkg/front_end/test/incremental_load_from_dill_test.dart:397:51)
<asynchronous suspension>
#19 basicTest (file:///usr/local/google/home/jensj/code/dart-sdk/sdk/pkg/front_end/test/incremental_load_from_dill_test.dart:167:34)
<asynchronous suspension>
#20 RunCompilations.run (file:///usr/local/google/home/jensj/code/dart-sdk/sdk/pkg/front_end/test/incremental_load_from_dill_test.dart:101:15)
<asynchronous suspension>
#21 ChainContext.run.doStep.<anonymous closure> (package:testing/src/chain.dart:180:33)
<asynchronous suspension>
#22 new Future.<anonymous closure> (dart:async/future.dart:176:37)
#23 _rootRun (dart:async/zone.dart:1120:38)
#24 _CustomZone.run (dart:async/zone.dart:1021:19)
#25 _CustomZone.runGuarded (dart:async/zone.dart:923:7)
#26 _CustomZone.bindCallbackGuarded.<anonymous closure> (dart:async/zone.dart:963:23)
#27 _rootRun (dart:async/zone.dart:1124:13)
#28 _CustomZone.run (dart:async/zone.dart:1021:19)
#29 _CustomZone.bindCallback.<anonymous closure> (dart:async/zone.dart:947:23)
#30 Timer._createTimer.<anonymous closure> (dart:async/runtime/libtimer_patch.dart:21:15)
#31 _Timer._runTimers (dart:isolate/runtime/libtimer_impl.dart:382:19)
#32 _Timer._handleMessage (dart:isolate/runtime/libtimer_impl.dart:416:5)
#33 _RawReceivePortImpl._handleMessage (dart:isolate/runtime/libisolate_patch.dart:171:12)
'. This might be a bug. The Dart team would greatly appreciate if you would take a moment to report this problem at http://dartbug.com/new.
which will hopefully allow us to actually debug any such reports.
Change-Id: I13bdd4f96c1e4bb2dcce91e533442b48c87c9e0c
Reviewed-on: https://dart-review.googlesource.com/c/85348
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Main risk in this CL is that it deviates from the void work which I'm confident is exhaustive.
Particularly, operators on void are caught by the resolver as a special kind of missing method, hopefully I put all the syntactic checks in at all the necessary places.
I also hardcoded "toString()," "hashCode." I previously had hardcoded to allow "==" checks, however, the code in ErrorVerifier was tripping over that. So now it should be good.
Change-Id: I56abb0219feb7aa143159694b688be15ba29015c
Reviewed-on: https://dart-review.googlesource.com/c/92063
Commit-Queue: Mike Fairhurst <mfairhurst@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This CL also contains changes from another CL.
Add missing generics in FlowAnalysis.
I can wait until that CL lands, and rebase, if it helps.
This CL also switches to a different approach to handle try / finally,
using two parallel states instead of 'restrict'.
R=paulberry@google.com
Change-Id: I1ca5bed3b4362cb3bdca5abf36c849c59538e57e
Reviewed-on: https://dart-review.googlesource.com/c/92246
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
At this point the migration tool is beginning to make assumptions
about decisions the language team hasn't made yet, so I've created a
class to document those assumptions and allow us to test variants.
Change-Id: I4638d7f534cfa2dbd8460277351045c370377ff8
Reviewed-on: https://dart-review.googlesource.com/c/92394
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Paul Berry