Special-case literals in `parse_bottom_expr`.
This makes parsing faster, particularly for code with large constants,
for two reasons:
- it skips all the keyword comparisons for literals;
- it skips the allocation done by the `mk_expr` call in
`parse_literal_maybe_minus`.
r? @petrochenkov
Allow attributes in formal function parameters
Implements https://github.com/rust-lang/rust/issues/60406.
This is my first contribution to the compiler and since this is a large and complex project, I am not fully aware of the consequences of the changes I have made.
**TODO**
- [x] Forbid some built-in attributes.
- [x] Expand cfg/cfg_attr
Add deny(unused_lifetimes) to all the crates that have deny(internal).
@Zoxc brought up, regarding #61722, that we don't force the removal of unused lifetimes.
Turns out that it's not that bad to enable for compiler crates (I wonder why it's not `warn` by default?).
I would've liked to enable `single_use_lifetimes` as well, but https://github.com/rust-lang/rust/issues/53738 makes it unusable for now.
For the `rustfmt` commit, I used https://github.com/rust-lang/rustfmt/issues/1324#issuecomment-482109952, and manually filtered out some noise.
r? @oli-obk cc @rust-lang/compiler
Remove some legacy proc macro flavors
Namely
- `IdentTT` (`foo! ident { ... }`). Can be replaced with `foo! { ident ... }` or something similar.
- `MultiDecorator`. Can be replaced by `MultiModifier` (aka `LegacyAttr` after renaming).
- `DeclMacro`. It was a less powerful duplicate of `NormalTT` (aka `LegacyBang` after renaming) and can be replaced by it.
Stuff like this slows down any attempts to refactor the expansion infra, so it's desirable to retire it already.
I'm not sure whether a lang team decision is necessary, but would be nice to land this sooner because I have some further work in this area scheduled.
The documentation commit (a9397fd0d5) describes how the remaining variants are different from each other and shows that there's actually some system behind them.
The last commit renames variants of `SyntaxExtension` in more systematic way.
- `ProcMacro` -> `Bang`
- `NormalTT` -> `LegacyBang`
- `AttrProcMacro` -> `Attr`
- `MultiModifier` -> `LegacyAttr`
- `ProcMacroDerive` -> `Derive`
- `BuiltinDerive` -> `LegacyDerive`
All the `Legacy*` variants are AST-based, as opposed to "modern" token-based variants.
lexer: Disallow bare CR in raw byte strings
Handles bare CR ~but doesn't translate `\r\n` to `\n` yet in raw strings yet~ and translates CRLF to LF in raw strings.
As a side-note I think it'd be good to change the `unescape_` to return plain iterators to reduce some boilerplate (e.g. `has_error` could benefit from collecting `Result<T>` and aborting early on errors) but will do that separately, unless I missed something here that prevents it.
@matklad @petrochenkov thoughts?
This makes parsing faster, particularly for code with large constants,
for two reasons:
- it skips all the keyword comparisons for literals;
- it replaces the unnecessary `parse_literal_maybe_minus` call with
`parse_lit`, avoiding an unnecessary allocation via `mk_expr`.
Stabilize #![feature(repr_align_enum)] in Rust 1.37.0
On an `enum` item, you may now write:
```rust
#[repr(align(X))]
enum Foo {
// ...
}
```
This has equivalent effects to first defining:
```rust
#[repr(align(X))]
struct AlignX<T>(T);
```
and then using `AlignX<Foo>` in `Foo`'s stead.
r? @nagisa
It was commented out as part of
8a8e497ae7.
Done probably by accident, since the code in question was moved to a
match arm, along with newly introduced logic to detect bare CRs in raw
strings.
parser: Remove `Deref` impl from `Parser`
Follow up to https://github.com/rust-lang/rust/pull/61541
You have to write `self.token.span` instead of `self.span` in the parser now, which is not nice, but not too bad either, I guess.
Not sure.
Probably still better than people using both and being confused about the definition point of `span`.
r? @oli-obk @estebank
