-
Notifications
You must be signed in to change notification settings - Fork 68
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Keep testutils on/off state internal to the sdk (#1301)
### What Change how testutils code is generated to make it rely only on the state of the SDK testutils feature, and not influenced at all by the contract crate's feature set or test cfg. Today the SDK macros generate both non-testutils and testutils code and it is up to the contract crate to enable or disable it. With this change the SDK macros only generate testutils code if the SDK is compiled with testutils. ### Why Today both the SDK and the contract crate must be configured with the testutils feature (or the test cfg) to enable the testutils that are generated by the SDK macros. The SDK has a testutils feature that enables the testutils functions and types in the SDK. The contract crate generated code also has code behind a testutils feature, and the contract crate testutils feature (or test cfg) must be enabled for them to function as well. This largely works, but it results in an oddity in more complex workspace setups that you can be using a testutils SDK with a non-testutils compiled contract crate meaning that none of the types or functions in that crate can be used with testutils functions. This largely goes unnoticed because it is a bit of an edge case and definitely not apparent in simpler setups. Even larger setups may never notice this as an oddity if they always happen to configure their crates appropriately. This also goes unnoticed because when the test cfg is enabled (when building for tests) we also enable all that testutils generated code. This issue has become more apparent to me lately because I'm experimenting with Soroban contracts inside Jupyter notebooks, as one way that folks can experiment and learn Soroban. The Rust runtime kernel for Jupyter notebooks doesn't currently support enable features for code in the notebook so I end up with an odd situation where testutils are enabled in the SDK, but not in the contract. After looking at how to solve this problem it occurred to me that the way we implemented the generated testutils code is not ideal, even independent of this problem. Instead of implementing the generated code so it contains a new testutils feature for the contract crate, we should have made all the generated testutils code enabled/disabled based on the SDKs feature flag. The advantage of this is that in any workspace whenever you have testutils enabled on the SDK, all contracts will also have testutils enabled. Instead of having many levers to pull to get testutils enabled, there is just one. ### Reviewing I recommend reviewing with whitespace changes disabled, because a large portion of the diff is the change to indents when some code was moved inside if..else statements. ### Merging This change _should_ be practically non-breaking. While technically it is removing code from being generated when compiled with an SDK without testutils enabled, most of the testutils code in generated code would be unusable without it anyway. It might be warranted to hold this change until v22, just for the purpose of shipping it in a preview / rc and getting feedback before committing to it. But I think the change is also pretty straightforward and low risk. I'd like to merge this in a minor release, but it warrants some discussion.
- Loading branch information
1 parent
1f10e9a
commit cd541d0
Showing
8 changed files
with
440 additions
and
415 deletions.
There are no files selected for viewing
This file contains 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
Large diffs are not rendered by default.
Oops, something went wrong.
This file contains 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 file contains 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 file contains 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
Oops, something went wrong.