feat!: add support for dynamic configurables#1555
Conversation
segfault-magnet
left a comment
There was a problem hiding this comment.
We should probably hold off on merging this until the sway branch catches up with sway master.
I have a feeling it's a bit behind seeing how the configurables offset is 8..16 and not 16..24 seeing as we already support the latter.
Either wait or integrate with the work done in the PR mentioned above so that we detect the compiler version used to generate the sway binary and use 16..24 if it is a modern compiler or 8..16 if it is the older one.
| } | ||
|
|
||
| pub(crate) fn code(&self) -> Vec<u8> { | ||
| pub(crate) fn code(&self) -> Result<Vec<u8>> { |
There was a problem hiding this comment.
Wdyt about having with_code and with_configurables return a Result, trying to apply the old configurables to the new code or the new configurables to the old code.
If that passes then we can .expect on all the getters and not have Result everywhere.
Nice consequence is that it will fail closer to the thing that made it fail -- ie the code or the configurables that were invalid, not later on when you try and calculate the contract id.
improve tests with comments Co-authored-by: Ahmed Sagdati <37515857+segfault-magnet@users.noreply.github.com>
AurelienFT
left a comment
There was a problem hiding this comment.
I don't understand all the details of each line and interactions but I understood the tests and the main idea and didn't see anything that shocked me. If the tests added pass I think the PR answers the need from an un-educated point of view.
In any cases thank you to not let long time PR die !
| } | ||
|
|
||
| pub(crate) fn code(&self) -> Vec<u8> { | ||
| pub(crate) fn code(&self) -> Result<Vec<u8>> { |
| new_enum, | ||
| 6, | ||
| "sway-sway".try_into()?, | ||
| "forc".try_into()?, |
There was a problem hiding this comment.
Might be nice to explain why "forc" here. I understood that it's the default configurable in the sway contract but it requires a lot of context for this magic word
There was a problem hiding this comment.
It is just a random string we encode and decode. It is hard-coded in the binary and defined in the main.sw file
| } | ||
|
|
||
| pub fn extract_data_offset(binary: &[u8]) -> Result<usize> { | ||
| extract_offset_at(binary, 8) |
There was a problem hiding this comment.
Might not compile due to type of size_of returns but the idea :
| extract_offset_at(binary, 8) | |
| extract_offset_at(binary, size_of::<usize>()) |
| } | ||
|
|
||
| pub fn extract_offset_at(binary: &[u8], offset: usize) -> Result<usize> { | ||
| if binary.len() < offset + 8 { |
There was a problem hiding this comment.
Might not compile due to type of size_of returns but the idea :
| if binary.len() < offset + 8 { | |
| if binary.len() < offset + size_of::<usize>() { |
| @@ -3,53 +3,297 @@ pub mod traits; | |||
| pub mod types; | |||
There was a problem hiding this comment.
All the functions seems to use a lot of offset in a lot of different orders and modifying some buffers that doesn't make sense for a first-time reader. Can you maybe add some documentation at the top of this file for the module and maybe document the functions you created.
EDIT: The documentation on the tests helps a lot to understands the data we are editing here thanks a lot.
closes: #1481
closes: #1328 as we can read the configurables directly from the binary
BLOCKED until we have a compiler that supports both
abi-errorsanddynamic configurables.Release notes
In this release, we:
strconfigurables.abigenthat can read configurables directly form the binary.ConfigurablesReaderthat can be used to read direct and indirect configurables at runtime and compile time.Summary
Breaking Changes
ContractRegularandLoadermethodscode(),contract_id(),code_root,state_rootreturnResultExecutableRegularandLoadermethodscode(),data_offset_in_code,loader_codereturnResultConfigurables'supdate_constants_inreturnsResultPredicate'swith_configurablereturnsResultAbiFormatter'sdecode_configurablesargumentconfigurable_datanow accepts a&[u8]Checklist