| Age | Commit message (Collapse) | Author | Lines |
|---|
|
merge rustc_attr_data_structures into rustc_hir
this move was discussed on zulip: [#t-compiler > attribute parsing rework @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/attribute.20parsing.20rework/near/528530091)
Many PRs in the attribute rework depend on this move.
|
|
|
|
There are identical definitions in `rustc_type_ir` and `rustc_ast`. This
commit removes them and places a single definition in `rustc_ast_ir`.
This requires adding `rust_span` as a dependency of `rustc_ast_ir`, but
means a bunch of silly conversion functions can be removed.
The one annoying wrinkle is that the old version had differences in
their `Debug` impls, e.g. one printed `u32` while the other printed
`U32`. Some compiler error messages rely on the former (yuk), and some
clippy output depends on the latter. So the commit also changes clippy
to not rely on `Debug` and just implement what it needs itself.
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
|
|
|
|
Some `let chains` clean-up
Not sure if this kind of clean-up is welcoming because of size, but I decided to try out one
r? compiler
|
|
|
|
jplatte:matches-allow-non_exhaustive_omitted_patterns, r=Nadrieril
Disable non_exhaustive_omitted_patterns within matches! macro
Closes rust-lang/rust#117304.
I believe I can skip all of the bootstrap stuff mentioned in https://github.com/rust-lang/rust/issues/117304#issuecomment-1784414453 due to https://blog.rust-lang.org/inside-rust/2025/05/29/redesigning-the-initial-bootstrap-sequence/, right?
cc `@Jules-Bertholet`
|
|
Fix unused_parens false positive
Resolves rust-lang/rust#143653.
The "no bounds exception" was indiscriminately set to `OneBound` for referents and pointees. However, if the reference or pointer type itself appears in no-bounds position, any constraints it has must be propagated.
```rust
// unused parens: not in no-bounds position
fn foo(_: Box<(dyn Send)>) {}
// unused parens: in no-bounds position, but one-bound exception applies
fn bar(_: Box<dyn Fn(&u32) -> &(dyn Send)>) {}
// *NOT* unused parens: in no-bounds position, but no exceptions to be made
fn baz(_: Box<dyn Fn(&u32) -> &(dyn Send) + Send>) {}
```
|
|
Don't lint against named labels in `naked_asm!`
Naked functions are allowed to define global labels, just like `global_asm!`.
|
|
Do not run per-module late lints if they can be all skipped
We run ~70 late lints for all dependencies even if they use `--cap-lints=allow`, which seems wasteful. It looks like these lints are super fast (unlike early lints), but still.
r? `@ghost`
|
|
Naked functions are allowed to define global labels, just like
`global_asm!`.
|
|
|
|
|
|
don't link to the nightly version of the Edition Guide in stable lints
As reported in rust-lang/rust#143557 for `rust_2024_incompatible_pat`, most future-Edition-incompatibility lints link to the nightly version of the Edition Guide; the lints were written before their respective Editions (and their guides) stabilized. But now that Rusts 2021 and 2024 are stable, these lints are emitted on stable versions of the compiler, where it makes more sense to present users with links that don't say "nightly" in them.
This does not change the link for `rust_2024_incompatible_pat`. That's handled in rust-lang/rust#144006.
|
|
|
|
Allow volatile access to non-Rust memory, including address 0
This PR relaxes the `ub_check` in the `read_volatile`/`write_volatile` pointer operations to allow passing null. This is needed to support processors which hard-code peripheral registers on address 0, like the AVR chip ATtiny1626. LLVM understands this as valid and handles it correctly, as tested in my [PR to add a note about it](https://github.com/llvm/llvm-project/pull/139803/commits/6387c82255c56d3035d249eb54110695e76b8030#diff-81bbb96298c32fa901beb82ab3b97add27a410c01d577c1f8c01000ed2055826) (rustc generates the same LLVM IR as expected there when this PR is applied, and consequently the same AVR assembly).
Follow-up and implementation of the discussions in:
- https://internals.rust-lang.org/t/pre-rfc-conditionally-supported-volatile-access-to-address-0/12881/7
- https://github.com/Rahix/avr-device/pull/185;
- [#t-lang > Adding the possibility of volatile access to address 0](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/Adding.20the.20possibility.20of.20volatile.20access.20to.20address.200/with/513303502)
- https://discourse.llvm.org/t/rfc-volatile-access-to-non-dereferenceable-memory-may-be-well-defined/86303
r? ````@RalfJung````
Also fixes https://github.com/rust-lang/unsafe-code-guidelines/issues/29 (about as good as it'll get, null will likely never be a "normal" address in Rust)
|
|
According to
https://discourse.llvm.org/t/rfc-volatile-access-to-non-dereferenceable-memory-may-be-well-defined/86303/4,
LLVM allows volatile operations on null and handles it correctly. This
should be allowed in Rust as well, because I/O memory may be hard-coded
to address 0 in some cases, like the AVR chip ATtiny1626.
A test case that ensured a failure when passing null to volatile was
removed, since it's now valid.
Due to the addition of `maybe_is_aligned` to `ub_checks`,
`maybe_is_aligned_and_not_null` was refactored to use it.
docs: revise restrictions on volatile operations
A distinction between usage on Rust memory vs. non-Rust memory was
introduced. Documentation was reworded to explain what that means, and
make explicit that:
- No trapping can occur from volatile operations;
- On Rust memory, all safety rules must be respected;
- On Rust memory, the primary difference from regular access is that
volatile always involves a memory dereference;
- On Rust memory, the only data affected by an operation is the one
pointed to in the argument(s) of the function;
- On Rust memory, provenance follows the same rules as non-volatile
access;
- On non-Rust memory, any address known to not contain Rust memory is
valid (including 0 and usize::MAX);
- On non-Rust memory, no Rust memory may be affected (it is implicit
that any other non-Rust memory may be affected, though, even if not
referenced by the pointer). This should be relevant when, for example,
reading register A causes a flag to change in register B, or writing
to A causes B to change in some way. Everything affected mustn't be
inside an allocation.
- On non-Rust memory, provenance is irrelevant and a pointer with none
can be used in a valid way.
fix: don't lint null as UB for volatile
Also remove a now-unneeded `allow` line.
fix: additional wording nits
|
|
Fix false positive double negations with macro invocation
This PR fixes false positive double_negations lint when macro expansion has negation and macro caller also has negations.
Fix rust-lang/rust#143980
|
|
parse `const trait Trait`
r? oli-obk or anyone from project-const-traits
cc `@rust-lang/project-const-traits`
|
|
|
|
r=traviscross,jieyouxu
Reword mismatched-lifetime-syntaxes text based on feedback
Key changes include:
- Removal of the word "syntax" from the lint message. More accurately, it could have been something like "syntax group" or "syntax category", but avoiding it completely is easier.
- The primary lint message now reflects exactly which mismatch is occurring, instead of trying to be general. A new `help` line is general across the mismatch kinds.
- Suggestions have been reduced to be more minimal, no longer also changing non-idiomatic but unrelated aspects.
- Suggestion text no longer mentions changes when those changes don't occur in that specific suggestion.
r? ``@jieyouxu``
|
|
Rollup of 15 pull requests
Successful merges:
- rust-lang/rust#142304 (tests: Add `RUST_BACKTRACE` and `-Cpanic` revisions to `panic-main.rs` test)
- rust-lang/rust#143388 (Various refactors to the LTO handling code)
- rust-lang/rust#143409 (Enable xgot feature for mips64 musl targets)
- rust-lang/rust#143592 (UWP: link ntdll functions using raw-dylib)
- rust-lang/rust#143595 (add `const_make_global`; err for `const_allocate` ptrs if didn't call)
- rust-lang/rust#143678 (Added error for invalid char cast)
- rust-lang/rust#143820 (Fixed a core crate compilation failure when enabling the `optimize_for_size` feature on some targets)
- rust-lang/rust#143829 (Trim `BorrowedCursor` API)
- rust-lang/rust#143851 (ci cleanup: rustdoc-gui-test now installs browser-ui-test)
- rust-lang/rust#143856 (Linting public reexport of private dependencies)
- rust-lang/rust#143895 (Dont collect assoc ty item bounds from trait where clause for host effect predicates)
- rust-lang/rust#143922 (Improve path segment joining)
- rust-lang/rust#143964 (Fix handling of SCRIPT_ARG in docker images)
- rust-lang/rust#144002 (Update poison.rs)
- rust-lang/rust#144016 (trait_sel: `MetaSized` always holds temporarily)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Linting public reexport of private dependencies
Part of public/private dependencies rust-lang/rust#44663
Partially addresses rust-lang/rust#71043
I'm adding a warning for reexports of private dependencies into `rustc_resolve`. I get that this should not be a warning, but should instead be a lint to be controlled by the feature gate, but I did not figure out how exactly to do that at that point. I tried doing the same thing as is done in `rustc_privacy`, but the linting system is not ready yet as far as I understand the error I got, so I made a warning for now instead. Some guidance on how to emit lints with `dcx` would be appreciated.
This also sets the `std_detect` crate as a public dependency of `std` because some macros are reexported from there. I did not check closer, but the other option may be to allow the specific reexports instead.
|
|
Added error for invalid char cast
fixes rust-lang/rust#143597
not really sure if I did it right, but according to cast-char test -- it is right, also this code gave me false positive result
```
for _ in 0..(256 as u8) {}
```
so this is why I added this check `if lit_val <= 0xFF`
Also I believe that error message could be improved, but I'm not sure how exactly
cc ```@hkBst```
r? compiler
|
|
|
|
|
|
|
|
|
|
Key changes include:
- Removal of the word "syntax" from the lint message. More accurately,
it could have been something like "syntax group" or "syntax
category", but avoiding it completely is easier.
- The primary lint message now reflects exactly which mismatch is
occurring, instead of trying to be general. A new `help` line is
general across the mismatch kinds.
- Suggestions have been reduced to be more minimal, no longer also
changing non-idiomatic but unrelated aspects.
- Suggestion text no longer mentions changes when those changes don't
occur in that specific suggestion.
|
|
Port `#[automatically_derived]` to the new attribute parsing infrastructure
Ports `#[automatically_derived]` to the new attribute parsing infrastructure for https://github.com/rust-lang/rust/issues/131229#issuecomment-2971351163
r? `@oli-obk`
cc `@jdonszelmann`
|
|
|
|
|
|
Split up the `unknown_or_malformed_diagnostic_attributes` lint
This splits up the lint into the following lint group:
- `unknown_diagnostic_attributes` - triggers if the attribute is unknown to the current compiler
- `misplaced_diagnostic_attributes` - triggers if the attribute exists but it is not placed on the item kind it's meant for
- `malformed_diagnostic_attributes` - triggers if the attribute's syntax or options are invalid
- `malformed_diagnostic_format_literals` - triggers if the format string literal is invalid, for example if it has unpaired curly braces or invalid parameters
- this pr doesn't create it, but future lints for things like deprecations can also go here.
This PR does not start emitting lints in places that previously did not.
## Motivation
I want to have finer control over what `unknown_or_malformed_diagnostic_attributes` does
I have a project with fairly low msrv that is/will have a lower msrv than future diagnostic attributes. So lints will be emitted when I or others compile it on a lower msrv.
At this time, there are two options to silence these lints:
- `#[allow(unknown_or_malformed_diagnostic_attributes)]` - this risks diagnostic regressions if I (or others) mess up using the attribute, or if the attribute's syntax ever changes.
- write a build script to detect the compiler version and emit cfgs, and then conditionally enable the attribute:
```rust
#[cfg_attr(rust_version_99, diagnostic::new_attr_in_rust_99(thing = ..))]`
struct Foo;
```
or conditionally `allow` the lint:
```rust
// lib.rs
#![cfg_attr(not(current_rust), allow(unknown_or_malformed_diagnostic_attributes))]
```
I like to avoid using build scripts if I can, so the following works much better for me. That is what this PR will let me do in the future:
```rust
#[allow(unknown_diagnostic_attribute, reason = "attribute came out in rust 1.99 but msrv is 1.70")]
#[diagnostic::new_attr_in_rust_99(thing = ..)]`
struct Foo;
|
|
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
|
|
|
|
improve lint doc text
|
|
|
|
|
|
|
|
|
|
compiler: rename BareFn to FnPtr
At some point "BareFn" was the chosen name for a "bare" function, without the niceties of `~fn`, `&fn`, or a few other ways of writing a function type. However, at some point the syntax for a "bare function" and any other function diverged even more. We started calling them what they are: function pointers, denoted by their own syntax.
However, we never changed the *internal* name for these, as this divergence was very gradual. Personally, I have repeatedly searched for "FnPtr" and gotten confused until I find the name is BareFn, only to forget this until the next time, since I don't routinely interact with the higher-level AST and HIR. But even tools that interact with these internal types only touch on them in a few places, making a migration easy enough. Let's use a more intuitive and obvious name, as this 12+ year old name has little to do with current Rust.
|
|
Fix some comments and related types and locals where it is obvious, e.g.
- bare_fn -> fn_ptr
- LifetimeBinderKind::BareFnType -> LifetimeBinderKind::FnPtrType
Co-authored-by: León Orell Valerian Liehr <me@fmease.dev>
|
|
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
|
|
|
|
|
|
|
|
|
