Port `#[rustc_layout_scalar_valid_range_start/end]` to the new attrib…
Ports `rustc_layout_scalar_valid_range_start` and `rustc_layout_scalar_valid_range_end` to the new attribute parsing infrastructure for https://github.com/rust-lang/rust/issues/131229#issuecomment-2971353197
r? `@jdonszelmann`
Port `#[track_caller]` to the new attribute system
r? ``@oli-obk``
depends on https://github.com/rust-lang/rust/pull/142493Closesrust-lang/rust#142783
(didn't add a test for this, this situation should simply never come up again, the code was simply wrong. lmk if I should add it, but it won't test something very useful)
Add `#[loop_match]` for improved DFA codegen
tracking issue: https://github.com/rust-lang/rust/issues/132306
project goal: https://github.com/rust-lang/rust-project-goals/issues/258
This PR adds the `#[loop_match]` attribute, which aims to improve code generation for state machines. For some (very exciting) benchmarks, see https://github.com/rust-lang/rust-project-goals/issues/258#issuecomment-2732965199
Currently, a very restricted syntax pattern is accepted. We'd like to get feedback and merge this now before we go too far in a direction that others have concerns with.
## current state
We accept code that looks like this
```rust
#[loop_match]
loop {
state = 'blk: {
match state {
State::A => {
#[const_continue]
break 'blk State::B
}
State::B => { /* ... */ }
/* ... */
}
}
}
```
- a loop should have the same semantics with and without `#[loop_match]`: normal `continue` and `break` continue to work
- `#[const_continue]` is only allowed in loops annotated with `#[loop_match]`
- the loop body needs to have this particular shape (a single assignment to the match scrutinee, with the body a labelled block containing just a match)
## future work
- perform const evaluation on the `break` value
- support more state/scrutinee types
## maybe future work
- allow `continue 'label value` syntax, which `#[const_continue]` could then use.
- allow the match to be on an arbitrary expression (e.g. `State::Initial`)
- attempt to also optimize `break`/`continue` expressions that are not marked with `#[const_continue]`
r? ``@traviscross``
rewrite `optimize` attribute to use new attribute parsing infrastructure
r? ```@oli-obk```
I'm afraid we'll get quite a few of these PRs in the future. If we get a lot of trivial changes I'll start merging multiple into one PR. They should be easy to review :)
Waiting on #138165 first
Port `#[rustc_as_ptr]` to the new attribute system
It might make sense to introduce some new parser analogous to `Single`, but even more simple: for parsing attributes that take no arguments and may appear only once (such as `#[rustc_as_ptr]` or `#[rustc_const_stable_indirect]`). Not sure if this should be a single `impl` parsing all such attributes, or one impl per attribute. Or how it will play along with the upcoming rework of attribute validation. Or how these argumentless attributes should be called (I've loosely referred to them as `markers` in the name of the new module in this PR, but not sure how good it is).
This is a part of rust-lang/rust#131229, so
r? `@jdonszelmann`
---
For reference, the `#[rustc_as_ptr]` attribute was created back in rust-lang/rust#132732 as a followup to rust-lang/rust#128985.
- Remove dead link to `rustc_attr` crate.
- Add link to `rustc_attr_parsing` crate.
- Split up first paragraph so it looks better at crate-level summary
Adds `#[rustc_force_inline]` which is similar to always inlining but
reports an error if the inlining was not possible, and which always
attempts to inline annotated items, regardless of optimisation levels.
It can only be applied to free functions to guarantee that the MIR
inliner will be able to resolve calls.
