[S] Change in dart/sdk[main]: [vm,dynamic_modules] Add private FFI callables to dynamic_interface.yaml
Tess Strickland (Gerrit)
Tess Strickland voted Commit-Queue+1![]( "Open in Gerrit")
| Commit-Queue | +1 |
Related details
- Alexander Markov
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Alexander Markov (Gerrit)
Alexander Markov added 1 comment![]( "Open in Gerrit")
# Private members of `dart:ffi` and its classes used by the FFI transformer.We should not expect users to add our private implementation methods to the dynamic interface (they may not know about them and they can be changed without notice).
Instead, we have pragmas (`dyn-module:language-impl:callable`, `dyn-module:language-impl:extendable`, `dyn-module:language-impl:can-be-overridden`) which can be used to add certain classes and members from core library to the dynamic interface implicitly, if dynamic interface is specified.
Annotating with these pragmas have 2 downsides: size increase (incurred by all apps with dynamic interface, we can measure the impact) and a potential breach in the specified API surface - currently dynamic module validation guarantees that dynamic modules are not allowed to use dangerous dart:ffi APIs if they are not specified in the dynamic interface. This latter is probably a less of an issue for private APIs, which are not accessible directly anyway, but we should be careful to not expose potentially unsafe APIs.
If current dyn-module:language-impl:* pragmas would not work well for this case, then we should think about extending them or providing another mechanism.
Related details
- Tess Strickland
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Tess Strickland (Gerrit)
Tess Strickland added 1 comment![]( "Open in Gerrit")
# Private members of `dart:ffi` and its classes used by the FFI transformer.We should not expect users to add our private implementation methods to the dynamic interface (they may not know about them and they can be changed without notice).
Instead, we have pragmas (`dyn-module:language-impl:callable`, `dyn-module:language-impl:extendable`, `dyn-module:language-impl:can-be-overridden`) which can be used to add certain classes and members from core library to the dynamic interface implicitly, if dynamic interface is specified.
Annotating with these pragmas have 2 downsides: size increase (incurred by all apps with dynamic interface, we can measure the impact) and a potential breach in the specified API surface - currently dynamic module validation guarantees that dynamic modules are not allowed to use dangerous dart:ffi APIs if they are not specified in the dynamic interface. This latter is probably a less of an issue for private APIs, which are not accessible directly anyway, but we should be careful to not expose potentially unsafe APIs.
If current dyn-module:language-impl:* pragmas would not work well for this case, then we should think about extending them or providing another mechanism.
Yeah, hmm. Perhaps there should be something akin to the existing pragmas, but conditional on either the enclosing class and/or library being properly annotated, and if it isn't, then they aren't. That is, something like @pragma('dyn-module:language-impl:callable-with-enclosing') or something, I'm not sure of a pithy way of saying it that doesn't end up with a really long pragma name.
Or even make it more general, specifying the dependency explicitly, e.g. `@pragma('dyn-module:language-impl:callable-with-library', 'dart:ffi')` or something similar, to say something like "if the library 'dart:ffi' is annotated as callable, then this method should be callable, and if it isn't, this method isn't".
Any thoughts?
Related details
- Alexander Markov
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |