| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
r=traviscross,workingjubilee
Remove `i128` and `u128` from `improper_ctypes_definitions`
Rust's 128-bit integers have historically been incompatible with C [1]. However, there have been a number of changes in Rust and LLVM that mean this is no longer the case:
* Incorrect alignment of `i128` on x86 [1]: adjusting Rust's alignment proposed at https://github.com/rust-lang/compiler-team/issues/683, implemented at https://github.com/rust-lang/rust/pull/116672.
* LLVM version of the above: resolved in LLVM, including ABI fix. Present in LLVM18 (our minimum supported version).
* Incorrect alignment of `i128` on 64-bit PowerPC, SPARC, and MIPS [2]: Rust's data layouts adjusted at https://github.com/rust-lang/rust/pull/132422, https://github.com/rust-lang/rust/pull/132741, https://github.com/rust-lang/rust/pull/134115.
* LLVM version of the above: done in LLVM 20 https://github.com/llvm/llvm-project/issues/102783.
* Incorrect return convention of `i128` on Windows: adjusted to match GCC and Clang at https://github.com/rust-lang/rust/pull/134290.
At https://github.com/rust-lang/lang-team/issues/255#issuecomment-2088855084, the lang team considered it acceptable to remove `i128` from `improper_ctypes_definitions` if the LLVM version is known to be compatible. Time has elapsed since then and we have dropped support for LLVM versions that do not have the x86 fixes, meaning a per-llvm-version lint should no longer be necessary. The PowerPC, SPARC, and MIPS changes only came in LLVM 20 but since Rust's datalayouts have also been updated to match, we will be using the correct alignment regardless of LLVM version.
`repr(i128)` was added to this lint in https://github.com/rust-lang/rust/pull/138282, but is also removed here.
Part of the decision is that `i128` should match `__int128` in C on platforms that provide it, which documentation is updated to indicate. We will not guarantee that `i128` matches `_BitInt(128)` since that can be different from `__int128`. Some platforms (usually 32-bit) do not provide `__int128`; if any ABIs are extended in the future to define it, we will need to make sure that our ABI matches.
Closes: https://github.com/rust-lang/rust/issues/134288
[1]: https://github.com/rust-lang/rust/issues/54341
[2]: https://github.com/rust-lang/rust/issues/128950
|
|
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#141554 (Improve documentation for codegen options)
- rust-lang/rust#141817 (rustc_llvm: add Windows system libs only when cross-compiling from Wi…)
- rust-lang/rust#141843 (Add `visit_id` to ast `Visitor`)
- rust-lang/rust#141881 (Subtree update of `rust-analyzer`)
- rust-lang/rust#141898 ([rustdoc-json] Implement PartialOrd and Ord for rustdoc_types::Id)
- rust-lang/rust#141921 (Disable f64 minimum/maximum tests for arm 32)
- rust-lang/rust#141930 (Enable triagebot `[concern]` functionality)
- rust-lang/rust#141936 (Decouple "reporting in deps" from `FutureIncompatibilityReason`)
- rust-lang/rust#141949 (move `test-float-parse` tool into `src/tools` dir)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Decouple "reporting in deps" from `FutureIncompatibilityReason`
The reason should just be it -- the reason. It never felt right to me that it was also responsible for whatever we include the warning in cargo's reports.
It gets especially unruly if you want to add non-`FutureReleaseError*` warnings which are included in the reports.
I just added a field to `FutureIncompatibleInfo` to control whatever the diagnostic is included in the cargo's reports.
|
|
Add `visit_id` to ast `Visitor`
This helps with efforts to deduplicate the `MutVisitor` and the `Visitor` code. All users of `Visitor`'s methods that have extra `NodeId` as parameters really just want to visit the id on its own.
Also includes some methods deduplicated and cleaned up as a result of this change.
r? oli-obk
|
|
|
|
`UsePath` contains a `SmallVec<[Res; 3]>`. This holds up to three `Res`
results, one per namespace (type, value, or macro). `lower_import_res`
takes a `PerNS<Option<Res<NodeId>>>` result and lowers it into the
`SmallVec`. This is pretty weird. The input `PerNS` makes it clear which
`Res` belongs to which namespace, but the `SmallVec` throws that
information away.
And code that operates on the `SmallVec` tends to use iteration (or even
just grabbing the first entry!) without knowing which namespace the
`Res` belongs to. Even weirder! Also, `SmallVec` is an overly flexible
type to use here, because it can contain any number of elements (even
though it's optimized for 3 in this case).
This commit changes `UsePath` so it also contains a
`PerNS<Option<Res<HirId>>>`. This type preserves more information and is
more self-documenting. The commit also changes a lot of the use sites to
access the result for a particular namespace. E.g. if you're looking up
a trait, it will be in the `Res` for the type namespace if it's present;
it's silly to look in the `Res` for the value namespace or macro
namespace. Overall I find the new code much easier to understand.
However, some use sites still iterate. These now use `present_items`
because that filters out the `None` results.
Also, `redundant_pub_crate.rs` gets a bigger change. A
`UseKind:ListStem` item gets no `Res` results, which means the old `all`
call in `is_not_macro_export` would succeed (because `all` succeeds on
an empty iterator) and the `ListStem` would be ignored. This is what we
want, but was more by luck than design. The new code detects `ListStem`
explicitly. The commit generalizes the name of that function
accordingly.
Finally, the commit also removes the `use_path` arena, because
`PerNS<Option<Res>>` impls `Copy` (unlike `SmallVec`) and it can be
allocated in the arena shared by all `Copy` types.
|
|
|
|
This helps with efforts to deduplicate the `MutVisitor` and the
`Visitor` code. All users of `Visitor`'s methods that have extra
`NodeId` as parameters really just want to visit the id on its
own.
Also includes some methods deduplicated and cleaned up as
a result of this change.
|
|
Hir item kind field order
A follow-up to rust-lang/rust#141675.
r? `@fee1-dead`
|
|
Report text_direction_codepoint_in_literal when parsing
The lint is now reported in code that gets removed/modified/duplicated by macro expansion, and spans are more accurate so we don't get ICEs from trying to split a span in the middle of a character.
This removes support for lint level attributes for `text_direction_codepoint_in_literal` except at the crate level, I don't think that there's an easy way around this when the lint can be reported on code that's removed by `cfg` or that is only in the input of a macro.
Fixes #140281
|
|
Use `cfg_attr_trace` in AST with a placeholder attribute for accurate suggestion
In rust-lang/rust#138515, we insert a placeholder attribute so that checks for attributes can still know about the placement of `cfg` attributes. When we suggest removing items with `cfg_attr`s (fix rust-lang/rust#56328) and make them verbose. We tweak the wording of the existing "unused `extern crate`" lint.
```
warning: unused `extern crate`
--> $DIR/removing-extern-crate.rs:9:1
|
LL | extern crate removing_extern_crate as foo;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ unused
|
note: the lint level is defined here
--> $DIR/removing-extern-crate.rs:6:9
|
LL | #![warn(rust_2018_idioms)]
| ^^^^^^^^^^^^^^^^
= note: `#[warn(unused_extern_crates)]` implied by `#[warn(rust_2018_idioms)]`
help: remove the unused `extern crate`
|
LL - #[cfg_attr(test, macro_use)]
LL - extern crate removing_extern_crate as foo;
|
```
r? `@petrochenkov`
try-job: x86_64-gnu-aux
|
|
Specifically `TyAlias`, `Enum`, `Struct`, `Union`. So the fields match
the textual order in the source code.
The interesting part of the change is in
`compiler/rustc_hir/src/hir.rs`. The rest is extremely mechanical
refactoring.
|
|
Rust's 128-bit integers have historically been incompatible with C [1].
However, there have been a number of changes in Rust and LLVM that
mean this is no longer the case:
* Incorrect alignment of `i128` on x86 [1]: adjusting Rust's alignment
proposed at https://github.com/rust-lang/compiler-team/issues/683,
implemented at https://github.com/rust-lang/rust/pull/116672.
* LLVM version of the above: resolved in LLVM, including ABI fix.
Present in LLVM18 (our minimum supported version).
* Incorrect alignment of `i128` on 64-bit PowerPC, SPARC, and MIPS [2]:
Rust's data layouts adjusted at
https://github.com/rust-lang/rust/pull/132422,
https://github.com/rust-lang/rust/pull/132741,
https://github.com/rust-lang/rust/pull/134115.
* LLVM version of the above: done in LLVM 20
https://github.com/llvm/llvm-project/issues/102783.
* Incorrect return convention of `i128` on Windows: adjusted to match
GCC and Clang at https://github.com/rust-lang/rust/pull/134290.
At [3], the lang team considered it acceptable to remove `i128` from
`improper_ctypes_definitions` if the LLVM version is known to be
compatible. Time has elapsed since then and we have dropped support for
LLVM versions that do not have the x86 fixes, meaning a per-llvm-version
lint should no longer be necessary. The PowerPC, SPARC, and MIPS changes
only came in LLVM 20 but since Rust's datalayouts have also been updated
to match, we will be using the correct alignment regardless of LLVM
version.
`repr(i128)` was added to this lint in [4], but is also removed here.
Part of the decision is that `i128` should match `__int128` in C on
platforms that provide it, which documentation is updated to indicate.
We will not guarantee that `i128` matches `_BitInt(128)` since that can
be different from `__int128`. Some platforms (usually 32-bit) do not
provide `__int128`; if any ABIs are extended in the future to define it,
we will need to make sure that our ABI matches.
Closes: https://github.com/rust-lang/rust/issues/134288
Closes: https://github.com/rust-lang/rust/issues/128950
[1]: https://github.com/rust-lang/rust/issues/54341
[2]: https://github.com/rust-lang/rust/issues/128950
[3]: https://github.com/rust-lang/lang-team/issues/255#issuecomment-2088855084
[4]: https://github.com/rust-lang/rust/pull/138282
|
|
PR 138515, we insert a placeholder attribute so that checks for attributes can still know about the placement of `cfg` attributes. When we suggest removing items with `cfg_attr`s (fix Issue 56328) and make them verbose. We tweak the wording of the existing "unused `extern crate`" lint.
```
warning: unused extern crate
--> $DIR/removing-extern-crate.rs:9:1
|
LL | extern crate removing_extern_crate as foo;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ unused
|
note: the lint level is defined here
--> $DIR/removing-extern-crate.rs:6:9
|
LL | #![warn(rust_2018_idioms)]
| ^^^^^^^^^^^^^^^^
= note: `#[warn(unused_extern_crates)]` implied by `#[warn(rust_2018_idioms)]`
help: remove the unused `extern crate`
|
LL - #[cfg_attr(test, macro_use)]
LL - extern crate removing_extern_crate as foo;
LL +
|
```
|
|
Make two transmute-related MIR lints into HIR lint
Make `PTR_TO_INTEGER_TRANSMUTE_IN_CONSTS` (rust-lang/rust#130540) and `UNNECESSARY_TRANSMUTES` (rust-lang/rust#136083) into "normal" HIR-based lints.
Funny enough this came up in the review of the latter (https://github.com/rust-lang/rust/pull/136083#issuecomment-2614301413), but I guess it just was overlooked.
But anywyas, there's no reason for these to be MIR lints; in fact, it makes the suggestions for them a bit more complicated than necessary.
Note that there's probably a few more simplifications and improvements to be done here. Follow-ups can be done in a separate PR, especially if they're about the messaging and suggestions themselves, which I didn't write.
|
|
Make check-cfg diagnostics work in `#[doc(cfg(..))]`
This PR makes it so that the check-cfg `unexpected_cfgs` lint, is correctly emitted in `rustdoc`'s `#[doc(cfg(..))]`.
This is achieved by adding a custom trait to `cfg_matches` (the method that emits the lint) which permits `rustc` and `rustdoc` to each have their way to emitting lints (via buffered lints/AST for `rustc` and via `TyCtxt`/HIR for `rustdoc`).
The reason this is required is because buffered lints operates on the AST but `rustdoc` uses the HIR and by the time `rustdoc` calls `cfg_matches` we are way passed the point where buffered lints have been drain and emitted.
Best reviewed commit by commit.
r? `@jieyouxu` (for the compiler part)
r? `@GuillaumeGomez` (for the rustdoc part)
|
|
|
|
Rename `{GenericArg,Term}::unpack()` to `kind()`
A well-deserved rename IMO.
r? `@oli-obk` or `@lcnr` (or anyone)
cc `@rust-lang/types,` but I'd be surprised if this is controversial.
|
|
- The lint is now reported in code that gets removed/modified/duplicated
by macro expansion.
- Spans are more accurate
- Fixes #140281
|
|
|
|
Improve `ambiguous_wide_pointer_comparisons` lint compare diagnostics
This PR improves the `ambiguous_wide_pointer_comparisons` lint compare diagnostics: `cmp`/`partial_cmp`, but also the operators `<`/`>`/`>=`/`<=`, by:
1. removing the reference to `std::ptr::addr_eq` which only works for equality
2. and adding an `#[expect]` suggestion for keeping the current behavior
Fixes rust-lang/rust#141510
|
|
|
|
Fix `unused_braces` lint suggestion when encountering attributes
This PR fixes the `unused_braces` lint suggestion when encountering attributes by not removing them in the suggestion.
Fixes rust-lang/rust#141549
|
|
further deduplicate ast visitor code
Previous PR: #141249
Tracking issue: #127615
r? `@oli-obk`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
make `rustc_attr_parsing` less dominant in the rustc crate graph
It has/had a glob re-export of `rustc_attr_data_structures`, which is a crate much lower in the graph, and a lot of crates were using it *just* (or *mostly*) for that re-export, while they can rely on `rustc_attr_data_structures` directly.
Previous graph:
Graph with this PR:
The first commit keeps the re-export, and just changes the dependency if possible. The second commit is the "breaking change" which removes the re-export, and "explicitly" adds the `rustc_attr_data_structures` dependency where needed. It also switches over some src/tools/*.
The second commit is actually a lot more involved than I expected. Please let me know if it's a better idea to back it out and just keep the first commit.
|
|
|
|
|
|
|
|
Stage0 bootstrap update
This PR [follows the release process](https://forge.rust-lang.org/release/process.html#master-bootstrap-update-tuesday) to update the stage0 compiler.
The only thing of note is https://github.com/rust-lang/rust/commit/58651d1b316e268fac2100c3ae37bb502a36b8ba, which was flagged by clippy as a correctness fix. I think allowing that lint in our case makes sense, but it's worth to have a second pair of eyes on it.
r? `@Mark-Simulacrum`
|
|
|
|
Warn when `#[export_name]` is used with generic functions
Fixes #140742
|
|
|
|
Use span before macro expansion in lint for-loops-over-falibles
Fixes #140747
I think there are going to be a lot of cases where macros are expanded in the compiler resulting in span offsets, and I'd like to know how that's typically handled. Does it have to be handled specially every time?
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
|
|
The documentation is talking about other way using only raw pointers, but the example was use `std::slice::from_raw_parts_mut` which also create a reference. `std::ptr::slice_from_raw_parts_mut` should be used instead, and it also highlights the benefit of raw pointer manipulation compared to dereference, as the function doesn't need to be unsafe anymore.
Moreover, [`unsafe_op_in_unsafe_fn`](https://doc.rust-lang.org/edition-guide/rust-2024/unsafe-op-in-unsafe-fn.html) warning has been enabled since Edition 2024, so I've updated the examples to use unsafe blocks.
|
|
|
|
perf: delay checking of `#[rustc_no_implicit_autorefs]` in autoref lint
Try to address the regression seen in https://github.com/rust-lang/rust/pull/123239#issuecomment-2835418470 by delaying the checking of `#[rustc_no_implicit_autorefs]` on method call.
|
|
handle paren in macro expand for let-init-else expr
Fixes #131655
This PR modifies the codegen logic of the macro expansion within `let-init-else` expression:
- Before: The expression `let xxx = (mac! {}) else {}` expands to `let xxx = (expanded_ast) else {}`.
- After: The same expression expands to `let xxx = expanded_ast else {}`.
An alternative solution to this issue could involve handling the source code directly when encountering unused parentheses in `let-init-else` expressions. However, this approach might be more cumbersome due to the absence of the necessary data structure.
r? `@petrochenkov`
|
|
Check bare function idents for non snake-case name
This PR adds the check required to lint on bare function idents for non snake-case name.
Reported at #140089.
cc `@theemathas`
|
|
uses_power_alignment: wording tweaks
Slightly improves the wording introduced with https://github.com/rust-lang/rust/pull/135552.
|
