The main contribution of this CL is unification of disparate handling of various functions like `Future.timeout`, `Future.wait`, `_SuspendState.createAsyncCallbacks` and `_SuspendState._createAsyncStarCallback` into a single `@pragma('vm:awaiter-link')` which allows Dart developers to specify where awaiter unwinder should look for the next awaiter. For example this allows unwinding to succeed for the code like this: Future<int> outer(Future<int> inner) { @pragma('vm:awaiter-link') final completer = Completer<int>(); inner.then((v) => completer.complete(v)); return completer.future; } This refactoring also ensures that we preserve information (including Function & Code objects) required for awaiter unwinding across all modes (JIT, AOT and AOT with DWARF stack traces). This guarantees users will get the same information no matter which mode they are running in. Previously we have been disabling awaiter_stacks tests in some AOT modes - which led to regressions in the quality of produced stacks. This CL also cleans up relationship between debugger and awaiter stack returned by StackTrace.current - which makes stack trace displayed by debugger (used for stepping out and determinining whether exception is caught or not) and `StackTrace.current` consistent. Finally we make one user visible change to the stack trace: awaiter stack will no always include intermediate listeners created through `Future.then`. Previously we would sometimes include these listeners at the tail of the stack trace, which was inconsistent. Ultimately this means that code like this: Future<int> inner() async { await null; // asynchronous gap print(StackTrace.current); // (*) return 0; } Future<int> outer() async { int process(int v) { return v + 1; } return await inner().then(process); } void main() async { await outer(); } Produces stack trace like this: inner <asynchronous suspension> outer.process <asynchronous suspension> outer <asynchronous suspension> main <asynchronous suspension> And when stepping out of `inner` execution will stop at `outer.process` first and the next step out will bring execution to `outer` next. Fixes https://github.com/dart-lang/sdk/issues/52797 Fixes https://github.com/dart-lang/sdk/issues/52203 Issue https://github.com/dart-lang/sdk/issues/47985 TEST=ci Bug: b/279929839 CoreLibraryReviewExempt: CL just adds @pragma to facilitate unwinding Cq-Include-Trybots: luci.dart.try:vm-aot-linux-product-x64-try,vm-aot-linux-debug-x64-try,vm-aot-linux-release-x64-try,vm-aot-obfuscate-linux-release-x64-try,vm-aot-dwarf-linux-product-x64-try Change-Id: If377d5329d6a11c86effb9369dc603a7ae616fe7 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311680 Reviewed-by: Alexander Markov <alexmarkov@google.com> Commit-Queue: Slava Egorov <vegorov@google.com>
4.9 KiB
VM-Specific Pragma Annotations
Pragmas for general use
These pragmas are part of the VM's API and are safe for use in external code.
Pragma | Meaning |
---|---|
vm:entry-point |
Defining entry-points into Dart code for an embedder or native methods |
vm:never-inline |
Never inline a function or method |
vm:prefer-inline |
Inline a function or method when possible |
vm:notify-debugger-on-exception |
Marks a function that catches exceptions, making the VM treat any caught exception as if they were uncaught. This can be used to notify an attached debugger during debugging, without pausing the app during regular execution. |
vm:keep-name |
Will ensure we keep the name of the class/function - even if e.g. obfuscation mode is enabled. |
vm:external-name |
Allows to specify an external (native) name for an external function. This name is used to lookup native implementation via native resolver associated with the current library through embedding APIs. This is a replacement for legacy VM specific native "name" syntax. |
vm:invisible |
Allows to mark a function as invisible so it will not appear on stack traces. |
vm:always-consider-inlining |
Marks a function which particularly benefits from inlining and specialization in context of the caller (for example, when concrete types of arguments are known). Inliner will not give up after one failed inlining attempt and will continue trying to inline this function. |
vm:platform-const |
Marks a static getter or a static field with an initializer where the getter body or field initializer evaluates to a constant value if the target operating system is known. |
weak-tearoff-reference |
Declaring a static weak reference intrinsic method. |
vm:isolate-unsendable |
Marks a class, instances of which won't be allowed to be passed through ports or sent between isolates. |
vm:awaiter-link |
Specifying variable to follow for awaiter stack unwinding |
Unsafe pragmas for general use
These pragmas are available for use in third-party code but are potentially unsafe. The use of these pragmas is discouraged unless the developer fully understands potential repercussions.
Pragma | Meaning |
---|---|
vm:unsafe:no-interrupts |
Removes all CheckStackOverflow instructions from the optimized version of the marked function, which disables stack overflow checking and interruption within that function. This pragma exists mainly for performance evaluation and should not be used in a general-purpose code, because VM relies on these checks for OOB message delivery and GC scheduling. |
Pragmas for internal use
These pragmas can cause unsound behavior if used incorrectly and therefore are only allowed within the core SDK libraries.
Pragma | Meaning |
---|---|
vm:exact-result-type |
Declaring an exact result type of a method |
vm:recognized |
Marking this as a recognized method |
Pragmas ignored in user code
These pragma's are only used on AST nodes synthesized by us, so users defining these will be ignored.
Pragma | Meaning |
---|---|
vm:ffi:native-assets |
Passing a native assets mapping to the VM |
Pragmas for internal testing
These pragmas are used for inspecting or modifying internal VM state and should be used exclusively by SDK tests.
They must be enabled with the --enable-testing-pragmas
flag.
The names of these pragmas are prefixed with "testing".
Additionally, they are categorized into "safe" and "unsafe" forms: "safe" pragmas should not affect the behavior of the program and can be safely added anywhere, whereas "unsafe" pragmas may change the code's behavior or may cause the VM to crash if used improperly.
Pragma | Meaning |
---|---|
vm:testing.unsafe.trace-entrypoints-fn |
Observing which flow-graph-level entry-point was used when a function was called |
Flutter toString transformer pragmas
These pragmas are useful to exclude certain toString methods from toString transformation,
which is enabled with --delete-tostring-package-uri
option in kernel compilers and
used by Flutter to remove certain toString methods in release mode to reduce size.
Pragma | Meaning |
---|---|
flutter:keep-to-string |
Avoid transforming the annotated toString method. |
flutter:keep-to-string-in-subtypes |
Avoid transforming toString methods in all subtypes of the annotated class. |