| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
Refactor `swayfmt` to support arbitrary lexed trees (#6806) ## Description This PR refactors `swayfmt` to be able generate code from arbitrary lexed trees. Arbitrary means a lexed tree that can be fully or partially created in-memory by manipulating the tree structure in code. It does not need to necessarily be backed by source code. This is needed to be able to reuse `swayfmt` for generating source code from tools that analyze and modify Sway code, as explained in #6779. This PR makes the `swayfmt` independent of spans backed by the source code, by doing the following changes: - Keywords are rendered by using theirs `AS_STR` associated constants. - The `Token` trait is extended with the `AS_STR` associated constant, and tokens are rendered by using that constant. - `Ident`s are rendered by using theirs `as_str()` methods. This method takes the textual implementation from `Ident::name_override_opt` if it is provided, and ignores the span in that case. - `Literal`s are rendered based on the literal value and not their spans. The exception are numeric literals that do not have empty spans. Those are considered to be backed by source code and are rendered as written in code, e.g., `1_000_000u64`. The PR also fixes some existing bugs in `swayfmt`: - `use path::{single_import,};` will be formatted as `use path::single_import;` - `use path::{a,b,};` will be formatted as `use path::{a, b};` - partial addresses #6802 by rendering annotations for final values. - partial addresses #6805 by properly rendering final values, but still not using the expected field alignment. The PR also removes the `path` parameter from the `parse_file`. It was used only to provide an unnecessary dummy `source_id` which was always pointing to the package root file. Closes #6779. ## 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). - [ ] 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. | 1 年前 | |
Defining, parsing, and checking `#[attribute]`s (#6986) ## Description This PR reimplements how `#[attribute]`s are parsed, defined, and checked. It fixes the following issues we had with attributes: - attributes were in general not checked for their expected and allowed usage. - when checked, checks were fixing particular reported issues and were scattered through various compilation phases: lexing, parsing, and tree conversion. - when checked, reported errors in some cases had bugs and were overalapping with other errors and warnings. - attribute handling was not centralized, but rahter scattered throught the whole code base, and mostly done at use sites. For concrete examples of these issues, see the list of closed issues below. The PR: - encapsulates the attributes handling within a single abstraction: `Attributes`. - assigns the following properties to every attribute: - _target_: what kind of elements an attribute can annotate. - _multiplicity_: if more then one attribute of the same kind can be applied to an element. - _arguments multiplicity_: a range defining how many arguments an attribute can or must have. - _arguments value expectation_: if attribute arguments are expected to have values. - validates those properties in a single place, during the `convert_parse_tree`. Note that this means that modules with attribute issues will now consistently not reach the type checking phase. This was previously the case for some of the issues with attributes where custom checks where done during the type checking phase. #6987 proposes to move those checks after the tree conversion phase, allowing the continuation of compilation. - adds the `AttributeKind::Unknow` to preserve unknown attributes in the typed tree. - removes redundant code related to attributes: specific warnings and errors, specialized parsing, repetitive and error-prone at use site checks, etc. - removes the unused `Doc` attribute. The PR also introduces a new pattern in emitting errors. The `attr_decls_to_attributes` function will always return `Attributes` even if they have errors, because: - we expect the compilation to continue even in the case of errors. - we expect those errors to be ignored if a valid `#[cfg]` attribute among those evaluates to false. - we expect them to be emitted with eventual other errors, or alone, at the end of the tree conversion of the annotated element. For more details, see the comment on `attr_decls_to_attributes` and `cfg_eval`. Closes #6880; closes #6913; closes #6914; closes #6915; closes #6916; closes #6917; closes #6918; closes #6931; closes #6981; closes #6983; closes #6984; closes #6985. ## Breaking changes Strictly seen, this PR can cause breaking changes, but only in the case of invalid existing attribute usage. We treat those breaking changes as bug fixes in the compiler and, thus, do not have them behind a feature flag. E.g., this kind of code was possible before, but will now emit and error: ```sway #[storage(read, write, read, write)] struct Struct {} ``` ## 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). - [ ] 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. | 1 年前 | |
Parse raw identifiers (`r#<identifier>`) in expressions (#7137) | 1 年前 | |
Better checks at `type_check_analyze` (#6410) ## Description Fix https://github.com/FuelLabs/sway/issues/6342 and https://github.com/FuelLabs/sway/issues/6370. https://github.com/FuelLabs/sway/issues/6342 occurs because when the type checker unifies `Numeric` with an unsigned integer, it never checks if the original literal actually fits into the new "unified" type. https://github.com/FuelLabs/sway/issues/6370 happens because we never go back to the array and check if every item actually is valid. This PR is now doing these two tests at `type_check_analyze`. ## 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: Joshua Batty <joshpbatty@gmail.com> | 2 年前 | |
Apply Clippy's `uninlined_format_args` lint (#7361) ## Description This PR improves the readability of `format!`, `write!`, etc. macros by rolling out the Clippy fixes for the `uninlined_format_args` lint. `cargo clippy` started showing this lint after locally switching to Cargo v1.88.0. Additionally, the PR: - replaces a few occurrences of `io::Error::new(std::io::ErrorKind::Other, <msg>)` with `io::Error::other(<msg>)`. - replaces a single occurrence of `if params.iter().any(|&p| p == "all")` with `if params.contains(&"all")`. ## 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. - [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. | 1 年前 | |
Fix SourceEngine cache to refresh buffers after file edits (#7399) ## Description - Update `SourceEngine::get_or_create_source_buffer` to replace the cached buffer when the caller supplies different text. - Fixes an LSP bug where diagnostics/token spans stayed stuck on the initial buffer, causing erroneous results after text edits. ## Checklist - [ ] 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). - [ ] 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. - [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. | 11 个月前 | |
Compile runtime backtracing to ASM and compile-time to ABI JSON (#7387) ## Description This PR implements the compilation of the ABI backtracking, as described in the [ABI Backtracking RFC](https://github.com/FuelLabs/sway-rfcs/blob/ironcev/abi-backtracing/rfcs/0016-abi-backtracing.md). The PR closes two remaining implementation steps listed in the #7276: - Compile runtime backtracing to ASM and compile-time to ABI JSON - Support backtracing in forc test ### Changes in the ABI JSON and IR Compilation #### `panickingCalls` section in the ABI JSON Each panicking call is identified by a unique number and provided in the new `panickingCalls` section in the ABI JSON. E.g., for this panicking call in a module `some_module` of a package `some_package`: ```sway fn some_function() { let _ = this_function_might_panic(42); } ``` the following ABI JSON entry is created: ```json "panickingCalls": { "1": { "pos": { "function": "some_package::some_module::some_function", "pkg": "some_package@0.1.0", "file": "src/some_module.sw", "line": 4, "column": 8 }, "function": "some_other_package::module::this_function_might_panic" }, } ``` #### Encoding error code and backtrace in a `panic` revert code The generation of the `panic` revert code is changed. A `panic` revert code now encodes: - the information that the revert is generated by a `panic` expression, - the actual error code that can be located in the `errorCodes` section of the ABI JSON, - up to five panicking call IDs, encoded in the order of calling, that can be located in the `panickingCalls` section of the ABI JSON. The encoding of the `u64` revert code works as following: ```console 1_pppppppp_CCCCCCCCCCC_CCCCCCCCCCC_CCCCCCCCCCC_CCCCCCCCCCC_CCCCCCCCCCC ``` - The leading `1` denotes a revert code generated by a `panic` expression. Arbitrary user-defined revert codes will must have the starting bit set to `0` or in other words be less then or equal to `9223372036854775807₁₀ = 7FFFFFFFFFFFFFFF₁₆`. - The `pppppppp` denotes the error code in the `errorCodes` section of the ABI JSON, that identifies the actual `panic` location. - Each `CCCCCCCCCCC` section denotes a panicking call code in the `panickingCalls` section of the ABI JSON. The calls represent the callstack, where the right-most code is the code of the immediate function call in which the `panic` occurs. If all `C`s a zero it means no-call. This will happen if the actual call-depth is less then five calls. #### Calculating backtrace Ever non-entry function that can panic gets an additional function argument: `__backtrace: u64`. The `__backtrace` to pass to a panicking call is calculated at runtime by left-shift the existing `__backtrace` provided by the caller function and append/bitwise OR the unique panicking call ID of the exact panicking call. The ID of that exact panicking call is a compile-time, compiler-generated constant as explained above. The detailed mechanism with examples is provided in the "Runtime execution and bytecode and gas overhead" chapter of the [ABI Backtracking RFC](https://github.com/FuelLabs/sway-rfcs/blob/ironcev/abi-backtracing/rfcs/0016-abi-backtracing.md). ## Additional Changes The `panickingCalls` section of the ABI JSON can differ between `debug` and `release` builds which required adding support for different ABI JSON oracle files in test that `validate_abi`. The requirement to display a fully qualified function name in the panicking call and the backtrace resulted in adding flexibility to displaying functions and types in general. Adjusting affected tests was used as opportunity to remove unnecessary dependencies to the `std` and reduced `std` libraries in a large number of tests. Also, a cleanup is done in some parts of the code, like, e.g., removing code duplications. The PR implements these additional changes: - Implements `TyFunctionDisplay` and `TypeInfoDisplay` for configurable displaying of functions and types. Replacing current various custom implementations of displaying with these two types, mostly in error messages, will be done in separate PRs, with low priority. Also, display might be improved in some edge cases. There are TODOs left in code for such, and improvements will be done in separate PRs, with lower priority. - Displays full type names in warnings and errors, where expected. The PR intentionally temporarily switches to full type names in all errors and warnings by making that a default behavior in `impl DisplayWithEngines for TypeInfo`. This is done so that we can easily spot errors and warnings that should use specific `TyFunctionDisplay` and `TypeInfoDisplay` (tests will break) and adapt those in the follow up PR that will address #7389. That follow up PR will also address usages of type names in LSP. - Implements expressive diagnostics for `CompileError::MethodNotFound` and utilize `TyFunctionDisplay` for displaying all matching candidates. - Implements `Value::new_u64_constant` and removing duplicated code for a common scenario of creating an IR Constant of type `u64`. - Removes several unnecessary `clone()`s and `String` allocations. - Renames fields postfixed with `typeid` to follow more general naming convention for `TypeId` fields and parameters. - Removes unnecessary dependencies to `std` or reduced `std` libraries in tests. - Adds support for different `json_abi_oracle` files for `debug` and `release` build profiles. The `panickingCalls` part of the ABI JSON can vary depending on the build profile. A test that verifies ABI JSON now *must provide* expected oracles for both build profiles, unless a profile is unsupported via `unsupported_profiles` test option. An alternative was considered, to allow just a single oracle file if both `debug` and `release` oracles are the same. The reasoning for having two as mandatory even in that case was to gain more explicit test setup. We can change this upon feedback if needed. The oracles have a suffix of either `.debug.json` or `.release.json` and the name part is, as before, one of the following: - `json_abi_oracle` for obsolete old encoding, - `json_abi_oracle.<experimental feature>` for experimental features, - `json_abi_oracle_new_encoding` for new encoding without other experimental features. - Fixes #7386. - Fixes #7388. ## 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). - [ ] 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. | 10 个月前 | |
CompileWarning -> sway_error (#2981) Moves `CompileWarning` into `sway_error`. This is work towards #2734. After this PR, we can integrate warnings into `Handler` so that it is functionally on par with `CompileResult`, and then remains to use `Handler` in various places, which can probably be done incrementally over a series of PRs. This also moves `style` and `IntegerBits` into `sway-types`. The former is also made more "pure". | 3 年前 | |
Removing verify-ir from the CLI (#7672) ## Description This PR removes "verify-ir" from the CLI, because we now run verify after each optimization pass. The performance impact seems to be minimal and it is well worthy the extra security it brings. This brought to attention a problem that the pass "arg-demotion" had with blocks with "never" as arguments. A better fix will be pushed later, but for now, the pass does not generate a miscompilation anymore. Otehr smal fixes were "filter-fn" not working with contracts, and the IR printer not correctly printings storage key address with 64 characters when they start with zero. ## 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. - [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. | 1 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 11 个月前 | ||
| 10 个月前 | ||
| 3 年前 | ||
| 1 个月前 |