## Description
Merges the two libraries. They were initially separate to separate the
core logic and fuel vm specific functionality, but that separation is no
longer maintained so having a merged library is better.
Closes#6708
## 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.
---------
Co-authored-by: Sophie <47993817+sdankel@users.noreply.github.com>
Co-authored-by: Igor Rončević <ironcev@hotmail.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
This PR introduces `string slices`.
The basic usage is at `test/src/ir_generation/tests/str_slice.sw`:
```sway
let a: str = "ABC";
```
Before this PR `a` would be of type `str[3]`, a string array.
Now both `string slices` and `string arrays` exist. This PR contains a
new intrinsic that converts from string literals to arrays.
```sway
let a: str = "ABC";
let b: str[3] = __to_str_array("ABC");
```
Runtime conversions can be done using
```sway
let a = "abcd";
let b: str[4] = a.try_as_str_array().unwrap();
let c = from_str_array(b);
```
string slices to string arrays can fail, so they return
`Option<str[N]>`; and because of this `try_as_str_array` lives in `std`.
The inverse, `from_str_array` only fails if `alloc` fails and lives in
`core`.
At this PR `string slices` are forbidden at `configurable`, `storage`,
`const`, and main arguments and returns. The reason for these
limitations is the internal structure of `string slices` having a `ptr`.
The optimized IR for initializing the slice is:
```
v0 = const string<3> "abc"
v1 = ptr_to_int v0 to u64, !2
v2 = get_local ptr { u64, u64 }, __anon_0, !2
v3 = const u64 0
v4 = get_elem_ptr v2, ptr u64, v3
store v1 to v4, !2
v5 = const u64 1
v6 = get_elem_ptr v2, ptr u64, v5
v7 = const u64 3
store v7 to v6, !2
v8 = get_local ptr slice, __anon_1, !2
mem_copy_bytes v8, v2, 16
```
## 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
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.
