The user can change whether the VM attempts to inline a given function or method with the following pragmas.
@pragma("vm:prefer-inline")
Here, the VM will inline the annotated function when possible. However, other factors can prevent inlining and thus this pragma may not always be respected.
@pragma("vm:never-inline")
Here, the VM will not inline the annotated function. In this case, the pragma is always respected.
@pragma("vm:always-consider-inlining")
VM will keep trying to inline the function in new contexts, not giving up after encountered contexts where inlining wasn't effective. With this some compile time is traded for expectation that the function has signficant type specialization, resulting in highly efficient inlined results in contexts where arguments types are known to the compiler. Example of this is _List.of
constructor in dart core library.
The VM is not able to see across method calls (apart from inlining) and therefore does not know anything about the return'ed values of calls, except for the interface type of the signature.
To improve this we have two types of additional information sources the VM utilizes to gain knowledge about return types:
inferred types (stored in kernel metadata): these are computed by global transformations (e.g. TFA) and are only available in AOT mode
@pragma
annotations: these are recognized in JIT and AOT mode
This return type information is mainly used in the VM's type propagator.
Since those annotations side-step the normal type system, they are unsafe and we therefore restrict those annotations to only have an affect inside dart: libraries.
See also https://github.com/dart-lang/sdk/issues/35244.
@pragma("vm:exact-result-type", <type>)
Tells the VM about the exact result type (i.e. the exact class-id) of a function or a field load.
There are two limitations on this pragma:
The Dart object returned by the method at runtime must have exactly the type specified in the annotation (not a subtype).
The exact return type declared in the pragma must be a subtype of the interface type declared in the method signature.
Note: This limitation is not enforced automatically by the compiler.
If those limitations are violated, undefined behavior may result. Note that since null
is an instance of the Null
type, which is a subtype of any other, exactness of the annotated result type implies that the result must be non-null.
It is also possible to specify the type arguments of the result type if they are the same as the type arguments passed to the method itself. This is primarily useful for factory constructors:
@pragma("vm:exact-result-type", [<type>, "result-type-uses-passed-type-arguments"])
class A {} class B extends A {} // Reference to type via type literal @pragma("vm:exact-result-type", B) A foo() native "foo_impl"; // Reference to type via path @pragma("vm:exact-result-type", "dart:core#_Smi"); int foo() native "foo_impl"; class C { // Reference to type via type literal @pragma('vm:exact-result-type', B) final B bValue; // Reference to type via path @pragma('vm:exact-result-type', "dart:core#_Smi") final int intValue; } class D<T> { @pragma("vm:exact-result-type", [D, "result-type-uses-passed-type-arguments"]) factory D(); // returns an instance of D<T> }
@pragma("vm:non-nullable-result-type")
Tells the VM that the method/field cannot return null
.
There is one limitation on this pragma:
null
.If this limitation is violated, undefined behavior may result.
@pragma("vm:non-nullable-result-type") A foo() native "foo_impl"; class C { @pragma('vm:non-nullable-result-type"); final int value; }
@pragma("vm:recognized", <kind>)
Marks the method as one of the methods specially recognized by the VM. Here, is one of "asm-intrinsic"
, "graph-intrinsic"
or "other"
, corresponding to the category the recognized method belongs to, as defined in recognized_methods_list.h
.
The pragmas must match exactly the set of recognized methods. This enables kernel-level analyses and optimizations to query whether a method is recognized by the VM. The correspondence is checked when running in debug mode.