sway/docs/reference
Igor Rončević 74282e2c7b
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.
2025-03-24 09:34:31 +11:00
..
src Defining, parsing, and checking #[attribute]s (#6986) 2025-03-24 09:34:31 +11:00
theme Updated the sway.js file by adding mod and type in keyword (#4427) 2023-04-12 22:39:45 +00:00
.gitignore Introduce the Sway reference, a more technical Sway source of documentation. (#2562) 2022-12-08 21:53:09 +00:00
book.toml Introduce the Sway reference, a more technical Sway source of documentation. (#2562) 2022-12-08 21:53:09 +00:00
README.md Struct field privacy (#5508) 2024-01-30 17:15:24 +04:00

The Sway Reference

Setup

If you wish contribute to this reference:

  1. Install Rust if it's not installed.

  2. Install mdbook.

    cargo install mdbook
    
  3. To build the book, ensure you are in /docs/reference and run:

    mdbook build
    
  4. To serve a hot-reloading instance of the book in your browser, run:

    mdbook serve --open