| Age | Commit message (Collapse) | Author | Lines |
|---|
|
From `#[align]` -> `#[rustc_align]`. Attributes starting with `rustc`
are always perma-unstable and feature-gated by `feature(rustc_attrs)`.
See regression RUST-143834.
For the underlying problem where even introducing new feature-gated
unstable built-in attributes can break user code such as
```rs
macro_rules! align {
() => {
/* .. */
};
}
pub(crate) use align; // `use` here becomes ambiguous
```
refer to RUST-134963.
Since the `#[align]` attribute is still feature-gated by
`feature(fn_align)`, we can rename it as a mitigation. Note that
`#[rustc_align]` will obviously mean that current unstable user code
using `feature(fn_aling)` will need additionally `feature(rustc_attrs)`,
but this is a short-term mitigation to buy time, and is expected to be
changed to a better name with less collision potential.
See
<https://rust-lang.zulipchat.com/#narrow/channel/238009-t-compiler.2Fmeetings/topic/.5Bweekly.5D.202025-07-17/near/529290371>
where mitigation options were considered.
(cherry picked from commit 69b71e44107b4905ec7ad84ccb3edf4f14b3df69)
|
|
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
|
|
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
|
|
|
|
Port `#[may_dangle]` to the new attribute system
Very similar to rust-lang/rust#142498.
This is a part of rust-lang/rust#131229, so
r? `@jdonszelmann`
|
|
|
|
|
|
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
|
|
|
|
Right now it's used for functions with `fn_align`, in the future it will
get more uses (statics, struct fields, etc.)
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
Refactor `rustc_attr_data_structures` documentation
I was reading through `AttributeKind` and realized that attributes like `InlineAttr` didn't appear in it, however, I found them in `rustc_codegen_ssa` and understood why (guessing).
There's almost no overall documentation for this crate, I've added the organized documentation at the top of `lib.rs`, and I've grouped the Attributes into two categories: `AttributeKind` that run all through the compiler, and the ones that are only used in `codegen_ssa`, such as `InlineAttr`, `OptimizeAttr`, `InstructionSetAttr`.
Also, I've added documentation for `AttributeKind` that further explains why attributes like `InlineAttr` don't appear in it, with examples for each variant.
r? ```@jdonszelmann```
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
Tracking the old name of renamed unstable library features
This PR resolves the first problem of rust-lang/rust#141617 : tracking renamed unstable features. The first commit is to add a ui test, and the second one tracks the changes. I will comment on the code for clarification.
r? `@jdonszelmann`
There have been a lot of PR's reviewed by you lately, thanks for your time!
cc `@jyn514`
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
lint on duplicates during attribute parsing
To do this we stuff them in the diagnostic context to be emitted after
hir is constructed
|
|
|
|
|
|
|
|
|
|
It was only temporarily used by pin!(), which no longer needs it.
|
|
|
|
r=onur-ozkan,jieyouxu
Use `RUSTC_LINT_FLAGS` more
An alternative to the failed #138084.
Fixes #138106.
r? ````@jieyouxu````
|
|
Improve `-Zunpretty=hir` for parsed attrs
0. Rename `print_something` to `should_render` to make it distinct from `print_attribute` in that it doesn't print anything, it's just a way to probe if a type renders anything.
1. Fixes a few bugs in the `PrintAttribute` derive. Namely, the `__printed_anything` variable was entangled with the `should_render` call, leading us to always render field names but never render commas.
2. Remove the outermost `""` from the attr.
3. Debug print `Symbol`s. I know that this is redundant for some parsed attributes, but there's no good way to distinguish symbols that are ident-like and symbols which are cooked string literals. We could perhaps *conditionally* to fall back to a debug printing if the symbol doesn't match an ident? But seems like overkill.
Based on #138060, only review the commits not in that one.
|
|
It's no longer necessary now that `-Wunreachable_pub` is being passed.
|
|
Revert <https://github.com/rust-lang/rust/pull/138084> to buy time to
consider options that avoids breaking downstream usages of cargo on
distributed `rustc-src` artifacts, where such cargo invocations fail due
to inability to inherit `lints` from workspace root manifest's
`workspace.lints` (this is only valid for the source rust-lang/rust
workspace, but not really the distributed `rustc-src` artifacts).
This breakage was reported in
<https://github.com/rust-lang/rust/issues/138304>.
This reverts commit 48caf81484b50dca5a5cebb614899a3df81ca898, reversing
changes made to c6662879b27f5161e95f39395e3c9513a7b97028.
|
|
|
|
|
|
depend more on attr_data_structures and move find_attr! there
r? ``@oli-obk``
This should be an easy one. It just moves some imports around. This is necessary for other changes that I'm working on not to have import cycles. However, it's an easy one to just merge on its own.
|
|
(Except for `rustc_codegen_cranelift`.)
It's no longer necessary now that `unreachable_pub` is in the workspace
lints.
|
|
|
|
- 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
|
|
|
|
note: compiler compiles but librustdoc and clippy don't
|
|
fixup docs in parser
|
|
|
|
|
|
Co-authored-by: Waffle Lapkin <waffle.lapkin@gmail.com>
|
|
|
|
the unstable module name is used
|
|
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.
|
|
Before this commit, replace-version-placeholder hardcoded the path
defining CURRENT_RUSTC_VERSION (to avoid replacing it). After a refactor
moved the file defining it without changing the hardcoded path, the tool
started replacing the constant itself with the version number.
To avoid this from happening in the future, this changes the definition
of the constant to avoid the tool from ever matching it.
|
|
|
