Explicit ordering of dep statements is required to resolve dependencies.
#409
Assignees
Labels
blocked
bug
Something isn't working
compiler: frontend
Everything to do with type checking, control flow analysis, and everything between parsing and IRgen
compiler: parser
Everything to do with the parser
P: critical
Should be looked at before anything else
Milestone
Comments
otrho
added
the
compiler
|
@nfurfaro Does |
|
@otrho No. In the example, it was just: |
mohammadfawaz
added
P: critical
mohammadfawaz
added
compiler: frontend
Closed
7 tasks
bitzoic
added a commit
that referenced
this issue
Sep 26, 2023
## Description Currently, `StorageVec` and `Vec` do not have any relation with one another. This PR takes advantage of the recent optimization and refactoring done to the Storage API `read()` and `write()` functions in #4795 and enables the storing of a `Vec` using the `StorageVec` type. To do this, the `StorageVec` now stores things sequentially rather than a different key for every element. Due to the optimizations done to the Storage API, this has become feasible as we can now load a single element of the sequential `StorageVec`. The storing of elements sequentially mimics the existing `Vec`, allowing us to store it as a `raw_slice` with a ***single*** read/write to storage as opposed to looping over the `Vec` and having ***n*** read/writes. It should be noted that due to #409, the storing of a `Vec` is written in the `StorageVec` file. This is the resulting syntax: ```sway let my_vec = Vec::new(); storage.storage_vec.store_vec(my_vec); // Store the Vec let other_vec = storage.storage_vec.load_vec(); // Read the Vec ``` When this issue is resolved, this should be changed to a `From` implementation changing the syntax to: ```sway let my_vec = Vec::new(); storage.storage_vec = my_vec.into(); // Store the Vec let other_vec = Vec::from(storage.storage_vec); // Read the Vec ``` Closes #2439 ## 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). - [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: bitzoic <bitzoic.eth@gmail.com>
tritao
added a commit
to tritao/sway
that referenced
this issue
Dec 11, 2023
This PR implements a new module evaluation system to allow
order-independent mod statements when importing modules.
It allows this sort of mod patterns to work:
`a.sw`:
```rust
library;
use ::b::*;
pub fn a() { b::b(); }
```
`b.sw`:
```rust
library;
pub fn b() {}
```
`lib.sw`:
```rust
library;
mod a;
mod b;
fn main() -> u32 {
b::b();
0
}
```
To make this work, we now analyze the submodule structure first,
creating a dependency graph that we later use to inform the module
evaluation order.
We also now check for cyclic dependencies using the same graph, and
report them when they are found.
Closes FuelLabs#409.
7 tasks
tritao
added a commit
to tritao/sway
that referenced
this issue
Dec 11, 2023
This PR implements a new module evaluation system to allow
order-independent mod statements when importing modules.
It allows this sort of mod patterns to work:
`a.sw`:
```rust
library;
use ::b::*;
pub fn a() { b::b(); }
```
`b.sw`:
```rust
library;
pub fn b() {}
```
`lib.sw`:
```rust
library;
mod a;
mod b;
fn main() -> u32 {
b::b();
0
}
```
To make this work, we now analyze the submodule structure first,
creating a dependency graph that we later use to inform the module
evaluation order.
We also now check for cyclic dependencies using the same graph, and
report them when they are found.
Closes FuelLabs#409.
IGI-111
pushed a commit
that referenced
this issue
Dec 12, 2023
## Description
This PR implements a new module evaluation system to allow
order-independent mod statements when importing modules.
It supports these sort of mod patterns to compile:
`a.sw`:
```rust
library;
use ::b::*;
pub fn a() { b::b(); }
```
`b.sw`:
```rust
library;
pub fn b() {}
```
`lib.sw`:
```rust
library;
mod a;
mod b;
fn main() -> u32 {
b::b();
0
}
```
To make this work, we now analyze the submodule structure first,
creating a dependency graph that we later use to inform the module
evaluation order.
We also now check for cyclic dependencies using the same graph, and
report them when they are found.
Closes #409.
## 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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Found by @nfurfaro:
The text was updated successfully, but these errors were encountered: