-
Notifications
You must be signed in to change notification settings - Fork 5.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Increase test coverage on std-lib #6087
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was skeptical of moving everything to separate libraries, but your reasoning for it is sound and it's actually easier to consume this way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work, LGTM
## Description As part of #6087, it was revealed that the current `use std::primitive_conversions::*;` line in the prelude does not import anything which a developer can use. To use any of the submodules in the primitive conversions library, users would need to import the individual submodule regardless of the prelude. This PR adds the submodules as an import to the prelude to stay consistent with the original intent. Both the core's and std-lib's primitive conversions modules are imported. Conversions between primitive types should not require additional imports. Example before: ```sway use std::primitive_conversions::u32::*; fn foo() { let my_u8 = 1_u8; let my_u16 = 1_u16; let my_u64 = 1_u64; let u32_1 = u32::from(my_u8); let u32_2 = u32::from(my_u16); let u32_3 = u32::try_from(my_u64); } ``` Example after: ```sway fn foo() { let my_u8 = 1_u8; let my_u16 = 1_u16; let my_u64 = 1_u64; let u32_1 = u32::from(my_u8); let u32_2 = u32::from(my_u16); let u32_3 = u32::try_from(my_u64); } ``` Closes #6088 Dependent on #6087 ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [x] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.
Description
Completes in-language tests for #6038.
Any tests in the std-lib have been moved into the
test/src/in_language_tests
folder. This has been done to ensure imports behave as expected and fields that should be public are.While many of the functions that have new tests are used elsewhere in the tests, there were no tests to explicitly check that it is behaving as expected.
The following tests have been added:
Address:
Assert
Asset Id
B512
Bytes
ContractId
Hash
Identity
Option
Result
String
U128
Primitive Conversions
b256
u16
u32
u64
u256
EvmAddrsss
Additional Edge cases have been added:
Address
Alloc
Assert
AssetId
B512
Bytes
ContractId
Hash
Identity
Option
Result
Revert
U128
Primitive Conversions
b256
u8
u16
u32
u64
u256
EvmAddress
evm ecr recover
The following issue have been discovered by writing these tests:
Into()
method crashes when converting from a generic type to a concrete type #6085Eq
forResult
#6077Eq
for arrays #6086From
implementation for tuple(b256, b256)
inB512
cannot be used without glob operator #6073AbiEncode
andAbiDecode
forString
#6037primitive_conversions
import from the prelude #6088Exponent
trait in the std-lib #6104Checklist
Breaking*
orNew Feature
labels where relevant.