We see (rarely, but still) situations when FileState attempts to read
a *.unlinked file, but the file is empty. We think that this happens
when the user's machine crashes, so files are created, but not fully
written to disk.
This change has its cost - increase of FileByteStore.put() CPU usage
from 7% to 10% on Mac.
R=paulberry@google.com, brianwilkerson@google.com
BUG=
Review-Url: https://codereview.chromium.org/2821683002 .
The type Map<T, Foo<Set<T>>> contains one type variable referenced twice,
so there are two inputs into the HTypeInfoExpression instruction.
If Foo is a typedef, T can be reused, e.g.
typedef E Foo<E>(E a, E b);
As the typedef is expanded (to Function(Set<T>, Set<T>) => Set<T>) it
should not consume additional types from the to-level input. We
prevent this by capturing the types and using the captured type
expressions inside the typedef expansion.
TODO: We should make the type subexpression Foo<...> be a second
HTypeInfoExpression, with Set<T> as its input (a third
HTypeInfoExpression). This would share all the Set<T> subexpressions
instead of duplicating them. This would require HTypeInfoExpression
inputs to correspond to type variables AND typedefs.
BUG= https://github.com/dart-lang/sdk/issues/28749R=efortuna@google.com
Review-Url: https://codereview.chromium.org/2812393003 .
Having an issue forwarding Symbol::InTypeCheck into dart and back;
without it, the exceptions that are thrown are `TypeError`s and not
`CastError`s.
Certainly a bit longform to read, as well.
Committing for feedback/suggestions/help
BUG=
R=rmacnak@google.com
Review-Url: https://codereview.chromium.org/2805903004 .
Had to allow a means of supplementing existing errors/line info, but
then also for where dart has no response whatsoever (like html), need a
way to provide analysis options and line info in addition to errors.
Happy to clean it up, but also not very motivated to make it perfect
since it should be temporary.
BUG=
R=brianwilkerson@google.com
Review-Url: https://codereview.chromium.org/2815643004 .
- [x] Produce an awaiter stack trace even when there is no awaiter.
- [x] Fix fetching the saved context from Closure.call (fixes --trace_debugger_stacktrace)
Fixes#29200
Example code:
```
main(List<String> args) async {
var f = new Foo();
print(f.a.length);
print('Should not get here');
}
class Foo {
String a;
}
```
BUG=
R=rmacnak@google.com
Review-Url: https://codereview.chromium.org/2815863002 .
This doesn't fix the entire problem, there's still a Chrome issue that it's not clear we can work around, but it helps some. https://bugs.chromium.org/p/chromium/issues/detail?id=676388
There are three distinct issues here affecting Chrome sourcemap usage for DDC programs with single-line lambdas.
1 - We may introduce a synthetic "as SomeType" in a parameter. The synthetic token ends up with a large negative length, from its offset to the beginning of the file, which can confuse sourcemaps.
2 - We have no entry for the blank line following the lambda. The devtools asks for the mapping from (selectedLine, 0) to (selectedLine +1, 0) and if there's no mapping for either it refuses to set the breakpoint. So this artificially forces the mapping from the last character on the line to be to the beginning of the next line instead.
3 - With a lambda we introduce a constructed Return JS node and make a block. Those nodes weren't getting annotated, so they had no source information.
BUG=
R=jmesserly@google.com
Review-Url: https://codereview.chromium.org/2815443003 .
This reverts commit d2a1bdff4a.
It causes an exception during pkg/analyzer analysis.
package:analyzer/src/fasta/mock_element.dart;package:analyzer/src/fasta/mock_element.dart;MockElement;accept
Unhandled exception:
NoSuchMethodError: Class 'CompilationUnitElementInDependency' has no instance getter 'typeParameterContext'.
Receiver: Instance of 'CompilationUnitElementInDependency'
Tried calling: typeParameterContext
R=brianwilkerson@google.com
BUG=
Review-Url: https://codereview.chromium.org/2814163002 .
We need to do this in order to associate resynthesized
GenericFunctionTypeElementImpl instances with these enclosing ElementImpl
instances. The same enclosing ElementImpl can also be used to get
the TypeParameterizedElementMixin for accessing type parameters.
R=brianwilkerson@google.com, paulberry@google.com
BUG=
Review-Url: https://codereview.chromium.org/2813543007 .
This is a step towards using data object rather than Compiler and
JavaScriptBackend in codegen. This is needed to support a shift in
element models between resolution and codegen.
R=efortuna@google.com
Review-Url: https://codereview.chromium.org/2811593006 .
