[compiler & language] Support builtin constant __COMPILE_FOR_TESTING__.
#17854
+361
−21
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This stack of pull requests is managed by Graphite. Learn more about stacking. |
wrwg
force-pushed
the
wrwg/compile-for-testing
branch
from
31a50fa to
0435463
Compare
wrwg
requested review from
georgemitenkov,
igor-aptos,
junxzm1990 and
rahxephon89
rahxephon89
approved these changes
Oct 13, 2025
wrwg
force-pushed
the
wrwg/compile-for-testing
branch
from
0435463 to
ca32913
Compare
junxzm1990
approved these changes
Oct 14, 2025
…__`. Allow code to branch over a compile time constant `__COMPILE_FOR_TESTING__`. The non-reachable branch will be optimized (or at least turned into dead code.) The name is under discussion. We should make the right decision here since any future compile time constants should be following this naming convention. I see compile constants as an equivalent to Rust attributes, at least if it comes to conditional compilation. This falls into the categorie of builtin constants which we already have for the spec llanguage. At the same time, we would enable `MAX_U64` et. all as builtin constants in the language. Builtin constants can be shadowed by the user, so no harm to existing move programs would be implied.
…of framework, because it may not compile with older compilers.
wrwg
force-pushed
the
wrwg/compile-for-testing
branch
from
ca32913 to
d46acdb
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
✅ Forge suite
|
✅ Forge suite
|
✅ Forge suite
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Allow code to branch over a compile time constant
__COMPILE_FOR_TESTING__. The non-reachable branch will be optimized (or at least turned into dead code.)The name is under discussion. We should make the right decision here since any future compile time constants should be following this naming convention. I see compile constants as an equivalent to Rust attributes, at least if it comes to conditional compilation. This will allow code to mock execution environment dependency in the context of tests:
The unit tests must link to locally compiled code for this to work.
The design uses the existing concept of builtin constants which we already have for the spec language, used for
MAX_U64et. al. This PR also enablesMAX_U64et. all in the programming language. Builtin constants can be shadowed by the user, keeping existing programs unchanged.How Has This Been Tested?
New tests
Type of Change
Which Components or Systems Does This Change Impact?