## Description
Continuation of https://github.com/FuelLabs/sway/pull/7030.
## 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).
- [ ] 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.
- [ ] 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.
---------
Co-authored-by: hey-ewan <ewanretorokugbe@gmail.com>
Co-authored-by: ewan ✦ <66304707+hey-ewan@users.noreply.github.com>
Co-authored-by: IGI-111 <igi-111@protonmail.com>
## Description
This PR introduces a comprehensive UNIX time handling library to the
Sway standard library, providing essential time manipulation
capabilities for smart contracts.
Time operations are fundamental for many smart contract use cases:
- Token vesting schedules
- Auction deadlines
- Time-locked transactions
- Subscription renewals
- Staking periods
Currently, Sway lacks standardized time utilities, forcing developers
to:
- Handle time conversions manually
- Implement custom time logic in every contract
- Risk errors in critical time calculations
This library solves these problems with a robust, well-tested time
abstraction.
### Duration Handling
```sway
// Create durations using natural units
let lock_period = Duration::days(90);
let auction_extension = Duration::minutes(15);
// Convert between units
log(lock_period.as_weeks()); // ≈12.857 weeks
log(auction_extension.as_seconds()); // 900 seconds
// Duration arithmetic
let total_lock = lock_period + Duration::weeks(2);
```
### Blockchain Time Operations
```sway
// Get current block time
let now = Time::now();
// Create future/past timestamps
let unlock_time = now.add(Duration::days(30));
let vesting_start = now.subtract(Duration::weeks(12));
// Measure time differences
let time_elapsed = now.duration_since(vesting_start).unwrap();
```
### TAI64 ↔ UNIX Conversion
Support for the existing TAI64 `timestamp()` functionality is
maintained.
```sway
// Native TAI64 from blockchain
let tai_timestamp = timestamp();
// Convert to UNIX time
let unix_time = Time::from_tai64(tai_timestamp);
// Convert back to TAI64
let converted_tai = unix_time.as_tai64();
assert(tai_timestamp == converted_tai);
```
### Benefits
- Safety: Prevents common time calculation errors
- Accuracy: Properly handles TAI64/UNIX conversion
- Productivity: Reduces boilerplate for time operations
- Consistency: Standardized approach across contracts
- Readability: Natural time unit expressions
### Future Extensions
Once support between different types for `Add`, `Subtract`, `Multiply`,
etc are implemented, we may be able to do the following:
```sway
let now = Time::now();
let future = now + Duration::DAY;
let three_weeks = Duration::WEEK * 3;
```
Closes https://github.com/FuelLabs/sway/issues/3945
## 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
This PR adds a page for external code execution in the Sway book.
## 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.
---------
Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
Co-authored-by: IGI-111 <igi-111@protonmail.com>
## Description
This PR sets the "new encoding" (from now on will be called "encoding
v1") as the default. We can still disable it using `no_encoding_v1`,
which switches back to "encoding v0".
Actions that needs to be done after this being merged will exist in
https://github.com/FuelLabs/sway/issues/5727
New features
- ABI Super traits;
- AbiEncode buffer dynamic sizing;
Bugs Fixed
- `ContractCall` intrinsic interaction effect was not set correctly;
Fixing warnings and error messages
- Better error message when core-lib is not available for
scripts/contracts/predicates;
- Better error message when main inputs/outputs are unknown or error
types;
- Better error message when main inputs/outputs do not implement
AbiEncode/AbiDecode;
- Don't warn impurity attributes on the "__entry" fn;
- Don't warn CEI on the "__entry" fn. Our CEI analysis, currently, does
not recognize `Never`. This means it does not realize it is impossible
to call two contract functions;
Test Disabled (needs to be enabled again in the future)
- should_pass/language/name_resolution_after_monomorphization
- should_pass/language/shadowing/shadowed_glob_imports
- should_pass/language/name_resolution_inside_intrinsics
- sdk-harness/external_proxy test is not working. I am assuming it is
the LDC bug that is already fixed on version 0.25. What is happening is
that the literal "double_value" has the correct length, but some random
data. Which makes the method selector fails. Only after we call LDC. The
proxy contract is working.
Test generating more warnings than before
- should_pass/dca/contract/superabi_contract_calls
What happens here is that when we implement a trait for `Contract`, we
actually generate two functions: one prefixed `__contract_entry` that is
called by the method selector; and another one normal, that can be
called freely. So, if the trait method is never called manually, it is
marked as dead.
- should_pass/dca/contract/abi_fn_params
I actually think the new warning is correct and nothing here needs to be
done.
Test with fewer warnings than before
- should_pass/dca/unused_fields
auto-impl is making all fields being used. so no dead code warnings are
being generated. We need to fix this.
Changes to std-lib
- Functions that return data about call context changed the semantic.
`first_param` and `second_param` return the value as the VM sees them.
We now have `called_method` and `called_args`. This means that we can
change the protocol later and still keep these four functions always
working and with meaningful names.
-
- predicate_data also was updated to use encoding v1 protocol.
ICE
- increase_buffer_if_needed implementation is a little bit strange
because does not work as a method inside `Buffer`. For some reason, it
is generating an ICE. I need to create an issue so we can fix, and
improve the implementation here.
- `Buffer` used by AbiEncode needs a `push_bytes` so we can be more
efficient when encoding Bytes and others.
## Checklist
- [ ] I have linked to any relevant issues.
- [ ] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [ ] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [ ] 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).
- [ ] I have requested a review from the relevant team or maintainers.
## Description
There have been a number of questions on the forum regarding storage and
the section needed and update. The following changes have been made:
- Simplified basic storage examples
- Added examples that include structs
- Added basic examples that include `StorageMap`
- Added basic examples that include `StorageVec`
- Added basic examples that include `StorageString`
- Added basic examples that include `StorageBytes`
- Added advanced nested examples using `StorageVec` and `StorageMap`
- Added advanced nested examples using `StorageString` and `StorageMap`
- Added advanced nested examples using `StorageBytes` and `StorageVec`
- ~~Added table of contents~~ Removed due to CI errors not accepting TOB
format
- Fixed inline docs on `StorageString`
- Fixed inline docs on `StorageBytes`
- Fixed inline docs on `StorageKey`
## 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] 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.
---------
Co-authored-by: Sarah Schwartz <58856580+sarahschwartz@users.noreply.github.com>
## Description
This PR makes struct fields private by default and introduces explicit
public struct fields:
```
pub struct Struct {
pub public_field: u8,
private_field: u8,
}
```
Private fields can be accessed only withing the module in which their
struct is declared.
Error messages are properly orchestrated so that no conflicting or
duplicated messages are emitted. Since the change is a breaking change,
relevant suggestion on how to fix the particular issue are given.
To avoid an abrupt breaking change, the errors are temporarily turned
into warnings. These warnings will become errors in the upcoming
versions of Sway. The demo section below demonstrate how the errors will
look like, and how a one warning equivalent looks now.
Standard library structs like `Vec` or `String`, are adapted where
needed by adding the `pub` keyword to the fields that are accessed
outside of the struct declaration module. Some of these fields should
very likely remain public, but some, like e.g., `RawBytes::ptr` or
`Vec::buf` should be private. Adjusting the standard library to properly
utilize private fields is out of scope of this PR and will be done
separately. I expect breaking changes in the STD once we start modeling
structs keeping encapsulation in mind.
In addition, the PR:
- migrates
[annotate_snippets](https://github.com/rust-lang/annotate-snippets-rs)
crate to its latest version (breaking changes)
- removes a redundant non-existing field error and orchestrates
non-existing field error with privacy errors
- replaces an invalid and misleading error when accessing fields on
storage elements that are not structs
Closes#4692.
## Known limitations
There is an issue in displaying multi-line code snippets, which is
independent of these changes, but wasn't apparent before. The issue is
visible in the demo section below, where the struct bodies are sometimes
not fully shown, and they should be. This issue is reported in #5499 and
will be solved in a separate PR.
## Demo (an excerpt 😄)
### Private struct field is inaccessible
### Struct cannot be instantiated
### Struct pattern must ignore inaccessible private fields
### Struct pattern has missing fields
### Errors temporarily turned into warnings
## 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] 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
As a continuation of https://github.com/FuelLabs/sway/pull/5461 and
improving the clarity of Native Assets on Fuel vs tokens, the legacy
Subcurrency example has been removed.
The Subcurrency example showed an implementation of a token using a
`StorageMap` to store addresses to balances. This sort of implementation
should not be promoted in Sway as it is a counterproductive example and
takes away from Native Assets on Fuel.
## 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] 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.
---------
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
## Description
We currently use the following terminology in the standard library when
discussing native assets on Fuel:
- Asset
- Coin
- Token
This can be incredibly confusing for new developers. A naming convention
that is consistent across the standard library, docs, and examples is
critical for clarity.
In the following PR I formalize the use of the words "Asset" and "Coin".
- An "Asset" is a Native Asset on Fuel and has the associated `AssetId`
type. Assets are distinguishable from one another.
- A "Coin" represents a singular unit of an Asset. Coins of the same
Asset are not distinguishable from one another.
The changes made reflect the distinction that Fuel does not use tokens
like other ecosystems such as Ethereum and uses Native Assets with a
UTXO design instead.
The Asset and Coin terminology is also consistent the fuel-vm's input
and outputs types. This is already seen in the `input.sw` file with the
`Input::Coin` enum and `output.sw`'s `Output::Coin` enum in the standard
library respectively.
## Breaking Changes
Imports using the `token` import should now use the `asset` import.
Before:
```sway
use std::token::mint;
```
After:
```sway
use std::asset::mint;
```
## 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] 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.
---------
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
## Description
Closes#3681
I meant to tackle #3077 first, but tackling #3681 first cleans up a lot
of the code needed to make #3077 easier.
This PR is mostly cleanup:
- Completely removes usage of `ConfigTimeConstant` everywhere (in
forc-pkg, sway-core, sway-type)
- **(BREAKING)** Completely removes support for `[constants]` table in
the manifest, which was using the `ConfigTimeConstant` struct. This
change is breaking for app devs ([open
issue](https://github.com/FuelLabs/sway-applications/issues/375)) and
from a [quick
search](https://github.com/FuelLabs/sway-applications/search?l=TOML&q=%5Bconstants%5D)
on our sway-applications repo, there's a number of manifests still using
the old version of configuration time constants.
Consequentially, the above change also allowed us to cut down on other
constructs like `ConstInjectMap` within forc-pkg, since the only thing
we need to inject now are const CONTRACT_IDs - this cuts down quite a
bit of now-redundant code.
- As a result of the removal of `ConfigTimeConstant`, a few tests using
that feature were also deleted.
- Also updated the `configurable` example to be known as
`configurable_constants` instead of `config_time_constant`.
**This PR does not:**
- Fix the manual creation of `CONTRACT_ID` const. To create the const,
we still undergo manual parsing and type-checking and finally inserting
into a `SymbolMap` manually. This will be handled in a separate PR to
tackle #3077
Other than removal of a lot of code to do with CTC, the main change here
that allows contract dependencies to still work here is instead of
relying on the `ConstInjectMap` which we used to inject both constants
and contract dependencies, there is now only a single contract ID value
that we require (this is abstracted as `ContractIdConst`) to inject into
the contract for tests.
## 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).
- [ ] 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
Closes#4223
Basically just showing that associated methods do actually work.
## Checklist
- [x] I have linked to any relevant issues.
- [ ] 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] I have added tests that prove my fix is effective or that my
feature works.
- [ ] 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.
Added the Result type to the same page where Identity, ContractId, and
Address are covered. Definition was taken from standard library repo -
https://github.com/FuelLabs/sway/blob/master/sway-lib-std/src/result.sw
---------
Co-authored-by: Camila Ramos <camiinthisthang@Camilas-MacBook-Pro-3.local>
Co-authored-by: Mohammad Fawaz <mohammadfawaz89@gmail.com>
## Description
This moves the examples workspace manifest introduced in #4118 into the
`examples/` directory and cleans it up a bit.
We also now integrate the examples workspace into CI, making the old
`examples-checker` script redundant. This old script is also removed as
a part of this PR.
## 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] 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.
