[Feature Request] Pass a MoveDialect container into move-compiler for better Move dialect support #9615
Labels
compiler-v2
enhancement
New feature or request
stale-exempt
Prevents issues from being automatically marked and closed as stale
🚀 Feature Request
In #9229 we add a "skip_attribute_checks" and "known_attributes" values which are set based on paths into the compiler to support different Move dialects (basic, Move, EVM, Async) precisely. The data paths pioneered there can be replaced by a container with those features and others as we want to support more dialect-specific Move language features.
Motivation
There are many paths into the move-compiler code. Aptos Move uses third-party/ to compile but has a few specializations. Currently there are a few hacks like extended_checks, but the capability of such hacks is limited. A more general container with functions and/or a dynamic trait such as MoveTestAdapter might be useful to thread extended functionality into the compiler that varies depending on language dialect.
When there is another language dialect feature we want to implement, we should build such a mechanism. Search for "skip_attribute_checks" and "known_attributes" in the code to find the paths to replace with a container passed through.
There are a few places where these values are carried by existing serializable structures, so a bit more work is needed to thread more general data through in parallel with BuildOptions, BuildConfig, ResolvedGraph/ResolutionGraph, Options, Flags, etc., so this is being postponed.
Pitch
A container which can carry non-serializable data such as specific functionality (similar to MoveTestAdapter's dialect-specific methods) to the compiler would allow a less specialized third-party/ Move compiler to support new Aptos extensions.
The text was updated successfully, but these errors were encountered: