Properly handle annotations everywhere in swayfmt
#6802
Labels
Comments
8 tasks
IGI-111
pushed a commit
that referenced
this issue
Jan 7, 2025
## 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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There are cases in which
swayfmtdoes not handle annotations at all, but just strips them away from the formatted code. One example would be stripping them from the last enum variant. Considering the upcoming language development, e.g. the ABI errors or derives, and the more prominent use of thecfgattribute for experimental features, having proper support for annotations everywhere in theswayfmtwill become a necessity.The text was updated successfully, but these errors were encountered: