## Description
This PR fixes a bunch of issues we had in generating access to the data
section. It also fixes#5876.
Reverts #5918.
---------
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
## Description
There's still a ton more to do but going to open this to get merged to
avoid conflicts. We can possibly add in some of these rules into CI in a
future PR.
## 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 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
fix some typos in comments
## 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.
Signed-off-by: yudrywet <yudeyao@yeah.net>
Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
## Description
This fixes https://github.com/FuelLabs/sway/issues/5474
This is the first part of #5612, which will be split into several
smaller PRs
## 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
Refer #5434
Found this issue when I tried to run `forc init --script` under a
directory(`/tmp/path_with_._dot`) that contains a dot ".". The value of
`project.name` in the generated file `Forc.toml` is truncated by the dot
"." as `path_with_`.
Since `project_dir` must be a directory(has checked before), we can use
`file_name` instead of `file_stem` to get the last-level dir name. Also,
I think it would be better to replace "." with "_", otherwise a
`project_name` that contains `.` would fail with validation
`validate_name(&project_name, "project name")?;`
## Screenshots
#### Before:
#### After:
## 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).
- [ ] 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 Dankel <47993817+sdankel@users.noreply.github.com>
This PR adds support to express line number mapping from assembly to
source using DWARF object files. Since there are offset details that are
specific to the Fuel ISA, I'm using the existing `SourceMap` that's
already being built, rather than generating directly from the
instructions.
An important point to note is that DWARF uses line-col to express
positions rather than an absolute offset-from-start format. To avoid
computing line-col from absolute positions (which requires re-reading
the source files), I'm changing the source position format everywhere to
line-col. This also simplifies our code at many places (for example, in
`forc-debug`). The only exception is the `addr2line` tool, where the use
of absolute positions is in a function that seemed quite complex to me
to attempt changes. So I have, temporarily, added code to compute
absolute positions from line-col information and then reuse the existing
functions. This is inefficient, but I think that's _okay_ since it's a
standalone tool and the whole thing runs just once for every command
invocation.
The DWARF information is written to a file specified by the `-g` flag
and can be verified using `llvm-dwarfdump --debug-line ./test.obj`. If
the argument to the `-g` flag is a filename that ends with `.json`, then
the existing JSON format is written out, otherwise it's a DWARF object
in an ELF container.
---------
Co-authored-by: Joao Matos <joao@tritao.eu>
Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
## Description
This PR implements the new encoding for contracts/scripts/predicates.
https://github.com/FuelLabs/sway/issues/5512 and
https://github.com/FuelLabs/sway/issues/5513
### Contract Calls
When the new encoding is turned on using `--experimental-new-encoding`,
contract calls like the example below will be "desugarized" differently
now.
```sway
let base_asset_id = BASE_ASSET_ID;
let other_contract_id = ContractId::from(0xa38576787f8900d66e6620548b6da8142b8bb4d129b2338609acd121ca126c10);
let test_contract = abi(ContextTesting, other_contract_id.into());
let returned_contract_id = test_contract.get_id { gas: gas, coins: 0, asset_id: BASE_ASSET_ID.value}(1, 2, 3);
```
and will be transformed to
```sway
let base_asset_id = BASE_ASSET_ID;
let other_contract_id = ContractId::from(0xa38576787f8900d66e6620548b6da8142b8bb4d129b2338609acd121ca126c10);
let test_contract = abi(ContextTesting, other_contract_id.into());
let returned_contract_id = contract_call::<ContractId, _>(other_contract_id.into(), "get_id", (1, 2, 3), coins, asset_id, gas);
```
And the important part is the `contract_call` function in the std
library. This function does all the encoding as necessary and delegates
the actual call to an intrinsic function `__contract_call`. Allowing the
protocol to evolve entirely in Sway.
```sway
pub fn contract_call<T, TArgs>(contract_id: b256, method_name: str, args: TArgs, coins: u64, asset_id: b256, gas: u64) -> T
where
TArgs: AbiEncode
{
let first_parameter = encode(method_name);
let second_parameter = encode(args);
let params = encode(
(
contract_id,
asm(a: first_parameter.ptr()) { a: u64 },
asm(a: second_parameter.ptr()) { a: u64 },
)
);
__contract_call::<T>(params.ptr(), coins, asset_id, gas)
}
```
### Contracts
On the other side, when the flag `--expiremental-new-encoding` is turned
on, the contract specification like the one below is being transformed
into all the decoding and encoding necessary.
The mains points are:
- The compiler generates a function called `__entry` that decodes the
method name and its arguments. The method is selected with a bunch of
`if`s at the moment, because we don´t have `match` for string slices.
Then we `decode` the arguments using the correct type, which is a tuple
with all the function arguments, and expand this tuple calling the
function;
- All the contract functions are converted to global functions prefixed
with `__contract_method`;
- Results are encoded and returned using the intrinsic call `__retd`.
Example:
```sway
abi SomeContract {
fn some_function(a: u64) -> u64;
}
impl SomeContract for Contract {
fn some_function(a: u64) -> u64 {
1
}
}
```
will be transformed into
```sway
fn __entry() {
let method_name = decode_first_parameter();
if method_name == "some_function" {
let args = decode_second_parameter::<(u64,)>();
let result = __contract_method_some_function(args.0);
__retd(encode(result));
}
__revert(0);
}
```
### Scripts and Predicates
The protocol to call scripts and predicates will also change and will be
very similar to contracts. See more above. Now when the flag is turned
on, the `main` function will not be entry point anymore. The compiler
will actually generate an `__entry` function that will decode arguments
and encode the result, like contracts.
For example:
```sway
fn main(a: u64) -> u64 {
1
}
```
will be transformed into
```sway
fn __entry() {
let args = decode_script_data::<(u64,)();
let result = main(args.0);
__retd(encode(result));
}
fn main(a: u64) -> u64 {
1
}
```
## Tests
To facilitate testing this PR introduces three changes to our test
harness:
1 - A new parameter can be called to update test output files (abi and
storage json). This facilitates when we only want to copy and paste
these output files to their respective oracles. Brings the framework
closer to a snapshot one.
```
> cargo r -p test --release -- --update-output-files
```
2 - Depending on the configuration at `test.toml` multiple executions of
the same test will be scheduled. At the moment, tests that depend on the
encoding will run with the `--experimental-new-encoding` flag
automatically. For example:
```
Testing should_pass/language/main_args/main_args_copy_copy ... ok
Testing should_pass/language/main_args/main_args_copy_copy (New Encoding) ... ok
```
3 - A new `script_data_new_encoding` was created because we want to
support and run tests with the two encoding for a time. This is also
what flags tests to run with the flag on automatically.
## 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
Related https://github.com/FuelLabs/sway-vscode-plugin/pull/166
Adds a [DAP](https://microsoft.github.io/debug-adapter-protocol//)
server as a new forc plugin, `forc-debug`. This enables a UI debugging
experience in IDEs such as VSCode.
For now, only debugging forc tests is supported. Users can:
- set breakpoints inside of forc tests
- step through the test, one VM instruction at a time, or continue to
the next breakpoint
- debug through multiple tests sequentially
- see the VM register values in the IDE while debugging
- see the current VM opcode, its inputs, and/or immediate value when
when the VM is stopped
### Screenshots
24e2016c-d96c-4ef6-931f-8a4ce4f1386b
5f0fed49-b278-4074-a1a1-d37de00776f8
### Local testing
1. Install `forc-debug`
2. Copy this sample launch.json in the VSCode workspace with sway code
to debug:
```json
{
"version": "0.2.0",
"configurations": [
{
"type": "sway",
"request": "launch",
"name": "Debug Sway",
"program": "${file}"
}]
}
```
3. Follow [the
steps](https://github.com/FuelLabs/sway-vscode-plugin/blob/master/docs/testing.md)
for testing the VSCode extension
### Limitations
- Breakpoints only work inside of the project/workspace being debugged
- Stack trace support is limited
- Not every line has source maps. Once debugging, "verified" breakpoints
will show red and "unverified" (no source maps) will be greyed out.
- Watch/repl expressions are not yet supported
- Step into/out of is not supported
- If you click "step over" many times in rapid succession, the server
takes a while to catch up.
Closes https://github.com/FuelLabs/sway/issues/5394
## Checklist
- [x] I have linked to any relevant issues.
- [x] 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).
- [ ] 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: Vaivaswatha Nagaraj <vaivaswatha.nagaraj@fuel.sh>
Co-authored-by: Vaivaswatha N <vaivaswatha@users.noreply.github.com>
Co-authored-by: IGI-111 <igi-111@protonmail.com>
Co-authored-by: João Matos <joao@tritao.eu>
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
Co-authored-by: Igor Rončević <ironcev@hotmail.com>
Co-authored-by: Sudhakar Verma <10460978+sudhackar@users.noreply.github.com>
Co-authored-by: Marcos Henrich <marcoshenrich@gmail.com>
Co-authored-by: jjcnn <38888011+jjcnn@users.noreply.github.com>
## Description
Closes https://github.com/FuelLabs/sway/issues/5607
Solves part [1] of https://github.com/FuelLabs/sway/issues/5607 by
making "release" the default build plan for forc-deploy. It can still be
overridden, i.e. for the test harness.
Other changes:
- removed the `--release` and `--error-on-warnings` options from
forc-deploy, since those aren't needed.
- refactored `BuildProfile` into its own file and added a test, since I
noticed some of the options weren't deserializing
## Checklist
- [x] 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).
- [ ] 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
Add macro to test argument parsing rather than testing the external
command through building and spawning a separated process. This is an
improved version of #5519
## 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
This PR does three things:
1. use Rust 1.76.0
2. enable the new `iter_over_hash_type` Clippy lint on relevant crates
3. use `indexmap::IndexMap` to replace any equivalent `HashMap` being
iterated upon with a deterministically ordered alternative
## 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
This PR does 3 optimizations. The timings below are measured against the
LSP benchmarking project.
1. Disable running DCA & control flow analysis, for did_change events
`39.544ms`
2. Disable running collect_types_metadata for did_change events
`3.522ms`
3. Only write the diagnostics res to self.diagnostics.write() on
did_open & did_save `21.135ms`
I also had to increase the frequency that we are calling GC to every 3rd
keystroke as during stress tests I was occasionally getting stack
overflows otherwise.
related to #5445
## Checklist
- [x] I have linked to any relevant issues.
- [x] 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).
- [ ] 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
cannonical -> canonical
## 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).
- [ ] 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: Joshua Batty <joshpbatty@gmail.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
This PR introduces a new `ParsedDeclEngine` which acts as the storage
place for parsed declarations. This is basically a clone of `DeclEngine`
but only used for untyped parsed declarations.
Declarations stored in this new engine are referenced by a
`ParsedDeclId` which again is analogous to our existing `DeclId`.
The rationale for introducing this is to be able to reference parsed
declarations during a multi-stage semantic analysis / type-checking
process. A cross-referencing mechanism between untyped/typed AST
declarations will still need to be implemented.
Just to note, `rustc` provides a similar architecture with their
`NodeId` / `DefId`, which provide a similar role to our `ParsedDeclId` /
`DeclId`, except we only support storing top-level AST entities, whereas
the system in Rust from what I understand can also be used to reference
individual expressions.
## 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
This PR is a continuation of https://github.com/FuelLabs/sway/pull/5306.
- I am fixing some code reviews issues that were raised in the other PR;
- I am incorporating the encoding version inside the JSON ABI as:
```json
{
"configurables": [],
"encoding": "1", <- look here
"functions": [
{
"attributes": null,
"inputs": [],
"name": "main",
"output": {
"name": "",
"type": 13,
"typeArguments": null
}
}
],
```
This field is a string to allow any kind of versioning we choose.
- This PR has also improved testing and making more explicit how each
type is being encoded.
## Dependencies
- [x] https://github.com/FuelLabs/fuel-abi-types/pull/17
## 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.
Fixes#5436
## Description
Replace chained `filter` and then `map` calls for a single `filter_map`
calls and other minor optimizations
## 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
Bumps repo to 0.49.0, made this a major one after some thought as we
longer support beta-4 as tooling with this release.
Also ran `cargo update` as this is a breaking change
---------
Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
## Description
This PR changes the output of `__log` to encoded values (see
https://github.com/FuelLabs/sway/issues/4769). A quick example of what
that means is
```sway
struct S {
a: u64,
b: u32,
c: u16,
d: u8,
e: Vec<u64>,
f: str,
g: u256
}
let mut e = Vec::new();
e.push(1);
e.push(2);
e.push(3);
__log(S{
a: 1,
b: 2,
c: 3,
d: 4,
e,
f: "sway",
g: u256::max()
});
```
will output
```
[0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 2, 0, 3, 4, 0, 0, 0, 0, 0, 0, 0, 3, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 2, 0, 0, 0, 0, 0, 0, 0, 3, 0, 0, 0, 0, 0, 0, 0, 4, 115, 119, 97, 121, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255]
^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^ ^^^^ ^ ^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^ ^^^ ^^^ ^^ ^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
s.a s.b s.c s.d s.e.len() s.e[0] s.e[1] s.e[2] s.f.len() s.f[0] s.f[1] s.f[2] s.f[3] s.g
```
This works in two steps:
1 - `__log(s)` is desugared into `__log(encode(s))`;
2 - call `encode`. Its impl can be found at
https://github.com/FuelLabs/sway/pull/5306/files#diff-ee5cebc963e841e8af05f3986de17dd266ee6e9b49dbe089a5eb64764f3b802eR307
It simply creates an append-only buffer and call `abi_encode` from a
special trait named `AbiEncode`.
To be encodable, a type must implement `AbiEncode`. In the example
above, `S` is auto-implemented by the compiler because all its fields
are `AbiEncode`. But we can also have custom impl like `Vec` here:
https://github.com/FuelLabs/sway/pull/5306/files#diff-b5d9688741fea479477f26ca44cd1d1ecbd2f003f3875292abb23df7fad85c58
All this is behind a compiler flag:
```
> forc build -h
Compile the current or target project
USAGE:
forc build [OPTIONS]
OPTIONS:
...
--experimental-new-encoding
Experimental flags for the "new encoding" feature
```
The same flag is available for the `e2e` tests:
```
> cargo r -p test --release -- should_pass/language/logging --verbose --experimental-new-encoding
```
## Limitations
1 - Now that __log demands a `fn` called `encode`, when something is
compiled with `implicit-std: false`, the intrinsic function `__log` does
not work out-of-box anymore. A function called `encode` must "visible"
and the worst part is that it needs to be functional to log anything.
2 - Arrays, string arrays and tuples will have limited implementations.
Currently up to five items.
## 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
Fixes#5398, #5374
Add examples to our `--help` cli. The examples are defined through the a
macro `forc::cli_examples { }` and each of these examples is part of the
the test suite of the crate. This is done to ensure the documentation is
always up to date or updated whenever the tests are not passing.
## 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: Braqzen <103777923+Braqzen@users.noreply.github.com>
## Description
Fixes#5396, #5402
The sorting is performed by the file_name instead of the full text to be
printed or full path
## 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
This PR just moves the dir helpers that were in `forc-util` to
`sway-utils`. I need access to these methods in an upcoming PR and
having them in `forc-util` introduces a mind field of circular
dependencies.
## Description
Fixes#1645 by checking if there are any duplicate keys in sections. Any
duplication of keys will generate a parsing error that will bubble up to
the final user with some context on how to fix it.
The following `Forc.toml` file will fail:
```
[project]
authors = ["Cesar"]
entry = "main.sw"
license = "Apache-2.0"
name = "invalid"
[dependencies]
foo = "bar"
foo = "xxx"
```
The error that will be bubble up to the CLI output reads as follow:
```
Error: failed to parse manifest: duplicate 'foo' for key `dependencies` at line 7 column 1.
```
## Description
Updates `forc new` and `forc init` welcome message to point to our new
documentation hub.
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
