| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Rollup of 9 pull requests
Successful merges:
- #135296 (interpret: adjust vtable validity check for higher-ranked types)
- #137106 (Add customized compare for Link in rustdoc)
- #137253 (Restrict `bevy_ecs` `ParamSet` hack)
- #137262 (Make fewer crates depend on `rustc_ast_ir`)
- #137263 (Register `USAGE_OF_TYPE_IR_INHERENT`, remove inherent usages)
- #137266 (MIR visitor tweaks)
- #137269 (Pattern Migration 2024: properly label `&` patterns whose subpatterns are from macro expansions)
- #137277 (stabilize `inherent_str_constructors`)
- #137281 (Tweak "expected ident" parse error to avoid talking about doc comments)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
interpret: adjust vtable validity check for higher-ranked types
## What
Transmuting between trait objects where a generic argument or associated type only differs in bound regions (not bound at or above the trait object's binder) is now UB. For example
* transmuting between `&dyn Trait<for<'a> fn(&'a u8)>` and `&dyn Trait<fn(&'static u8)>` is UB.
* transmuting between `&dyn Trait<Assoc = for<'a> fn(&'a u8)>` and `&dyn Trait<Assoc = fn(&'static u8)>` is UB.
* transmuting between `&dyn Trait<for<'a> fn(&'a u8) -> (&'a u8, &'static u8)>` and `&dyn Trait<for<'a> fn(&'a u8) -> (&'static u8, &'a u8)>` is UB.
Transmuting between subtypes (in either direction) is still allowed, which means that bound regions that are bound at or above the trait object's binder can still be changed:
* transmuting between `&dyn for<'a> Trait<fn(&'a u8)>` and `&dyn for Trait<fn(&'static u8)>` is fine.
* transmuting between `&dyn for<'a> Trait<dyn Trait<fn(&'a u8)>>` and `&dyn for Trait<dyn Trait<fn(&'static u8)>>` is fine.
## Why
Very similar to https://github.com/rust-lang/rust/issues/120217 and https://github.com/rust-lang/rust/issues/120222, changing a trait object's generic argument to a type that only differs in bound regions can still affect the vtable layout and lead to segfaults at runtime (for an example see `src/tools/miri/tests/fail/validity/dyn-transmute-inner-binder.rs`).
Since we already already require that the trait object predicates must be equal modulo bound regions, it is only natural to extend this check to also require type equality considering bound regions.
However, it also makes sense to allow transmutes between a type and a subtype thereof. For example `&dyn for<'a> Trait<&'a u8>` is a subtype of `&dyn Trait<&'static ()>` and they are guaranteed to have the same vtable, so it makes sense to allow this transmute. So that's why bound lifetimes that are bound to the trait object itself are treated as free lifetime for the purpose of this check.
Note that codegen already relies on the property that subtyping cannot change the the vtable and this is asserted here (note the leak check): https://github.com/rust-lang/rust/blob/251206c27b619ccf3a08e2ac4c525dc343f08492/compiler/rustc_codegen_ssa/src/base.rs#L106-L153
Furthermore, we allow some pointer-to-pointer casts like `*const dyn for<'a> Trait<&'a u8>` to `*const Wrapper<dyn Trait<&'static u8>>` that instantiate the trait object binder and are currently lowered to a single pointer-to-pointer cast in MIR (`CastKind::PtrToPtr`) and *not* an unsizing coercion (`CastKind::PointerCoercion(Unsize)`), so the current MIR lowering of these would be UB if we didn't allow subtyping transmutes.
---
fixes https://github.com/rust-lang/rust/issues/135230
cc `@rust-lang/opsem`
r? `@compiler-errors` for the implementation
|
|
Lint `#[must_use]` attributes applied to methods in trait impls
The `#[must_use]` attribute has no effect when applied to methods in trait implementations. This PR adds it to the unused `#[must_use]` lint, and cleans the extra attributes in portable-simd and Clippy.
|
|
Suggest replacing `.` with `::` in more error diagnostics.
First commit makes the existing "help: use the path separator to refer to an item" also work when the base is a type alias, not just a trait/module/struct.
The existing unconditional `DefKind::Mod | DefKind::Trait` match arm is changed to a conditional `DefKind::Mod | DefKind::Trait | DefKind::TyAlias` arm that only matches if the `path_sep` suggestion-adding closure succeeds, so as not to stop the later `DefKind::TyAlias`-specific suggestions if the path-sep suggestion does not apply. This shouldn't change behavior for `Mod` or `Trait` (due to the default arm's `return false` etc).
This commit also updates `tests/ui/resolve/issue-22692.rs` to reflect this, and also renames it to something more meaningful.
This commit also makes the `bad_struct_syntax_suggestion` closure take `err` as a parameter instead of capturing it, since otherwise caused borrowing errors due to the change to using `path_sep` in a pattern guard.
<details> <summary> Type alias diagnostic example </summary>
```rust
type S = String;
fn main() {
let _ = S.new;
}
```
```diff
error[E0423]: expected value, found type alias `S`
--> diag7.rs:4:13
|
4 | let _ = S.new;
| ^
|
- = note: can't use a type alias as a constructor
+ help: use the path separator to refer to an item
+ |
+4 | let _ = S::new;
+ | ~~
```
</details>
Second commit adds some cases for `enum`s, where if there is a field/method expression where the field/method has the name of a unit/tuple variant, we assume the user intended to create that variant[^1] and suggest replacing the `.` from the field/method suggestion with a `::` path separator. If no such variant is found (or if the error is not a field/method expression), we give the existing suggestion that suggests adding `::TupleVariant(/* fields */)` after the enum.
<details> <summary> Enum diagnostic example </summary>
```rust
enum Foo {
A(u32),
B,
C { x: u32 },
}
fn main() {
let _ = Foo.A(42); // changed
let _ = Foo.B; // changed
let _ = Foo.D(42); // no change
let _ = Foo.D; // no change
let _ = Foo(42); // no change
}
```
```diff
error[E0423]: expected value, found enum `Foo`
--> diag8.rs:8:13
|
8 | let _ = Foo.A(42); // changed
| ^^^
|
note: the enum is defined here
--> diag8.rs:1:1
|
1 | / enum Foo {
2 | | A(u32),
3 | | B,
4 | | C { x: u32 },
5 | | }
| |_^
-help: you might have meant to use the following enum variant
- |
-8 | let _ = Foo::B.A(42); // changed
- | ~~~~~~
-help: alternatively, the following enum variant is available
+help: use the path separator to refer to a variant
|
-8 | let _ = (Foo::A(/* fields */)).A(42); // changed
- | ~~~~~~~~~~~~~~~~~~~~~~
+8 | let _ = Foo::A(42); // changed
+ | ~~
error[E0423]: expected value, found enum `Foo`
--> diag8.rs:9:13
|
9 | let _ = Foo.B; // changed
| ^^^
|
note: the enum is defined here
--> diag8.rs:1:1
|
1 | / enum Foo {
2 | | A(u32),
3 | | B,
4 | | C { x: u32 },
5 | | }
| |_^
-help: you might have meant to use the following enum variant
- |
-9 | let _ = Foo::B.B; // changed
- | ~~~~~~
-help: alternatively, the following enum variant is available
+help: use the path separator to refer to a variant
|
-9 | let _ = (Foo::A(/* fields */)).B; // changed
- | ~~~~~~~~~~~~~~~~~~~~~~
+9 | let _ = Foo::B; // changed
+ | ~~
error[E0423]: expected value, found enum `Foo`
--> diag8.rs:10:13
|
10 | let _ = Foo.D(42); // no change
| ^^^
|
note: the enum is defined here
--> diag8.rs:1:1
|
1 | / enum Foo {
2 | | A(u32),
3 | | B,
4 | | C { x: u32 },
5 | | }
| |_^
help: you might have meant to use the following enum variant
|
10 | let _ = Foo::B.D(42); // no change
| ~~~~~~
help: alternatively, the following enum variant is available
|
10 | let _ = (Foo::A(/* fields */)).D(42); // no change
| ~~~~~~~~~~~~~~~~~~~~~~
error[E0423]: expected value, found enum `Foo`
--> diag8.rs:11:13
|
11 | let _ = Foo.D; // no change
| ^^^
|
note: the enum is defined here
--> diag8.rs:1:1
|
1 | / enum Foo {
2 | | A(u32),
3 | | B,
4 | | C { x: u32 },
5 | | }
| |_^
help: you might have meant to use the following enum variant
|
11 | let _ = Foo::B.D; // no change
| ~~~~~~
help: alternatively, the following enum variant is available
|
11 | let _ = (Foo::A(/* fields */)).D; // no change
| ~~~~~~~~~~~~~~~~~~~~~~
error[E0423]: expected function, tuple struct or tuple variant, found enum `Foo`
--> diag8.rs:12:13
|
12 | let _ = Foo(42); // no change
| ^^^ help: try to construct one of the enum's variants: `Foo::A`
|
= help: you might have meant to construct the enum's non-tuple variant
note: the enum is defined here
--> diag8.rs:1:1
|
1 | / enum Foo {
2 | | A(u32),
3 | | B,
4 | | C { x: u32 },
5 | | }
| |_^
error: aborting due to 5 previous errors
```
</details>
[^1]: or if it's a field expression and a tuple variant, that they meant to refer the variant constructor.
|
|
Rollup of 10 pull requests
Successful merges:
- #135711 (Do not ICE on default_field_value const with lifetimes)
- #136599 (librustdoc: more usages of `Joined::joined`)
- #136876 (Locking documentation updates)
- #137000 (Deeply normalize item bounds in new solver)
- #137126 (fix docs for inherent str constructors)
- #137161 (Pattern Migration 2024: fix incorrect messages/suggestions when errors arise in macro expansions)
- #137191 (Update mdbook and move error_index_generator)
- #137203 (Improve MIR modification)
- #137206 (Make E0599 a structured error)
- #137218 (misc `layout_of` cleanup)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
When `Foo.field` or `Foo.method()` exprs are encountered, suggest `Foo::field` or `Foo::method()` when Foo is a type alias, not just
a struct, trait, or module.
Also rename test for this suggestion from issue-22692.rs to something more meaningful.
|
|
Update mdbook and move error_index_generator
This moves error_index_generator to the rustbook workspace so that it can share the dependency with mdbook. I had forgotten that error_index_generator is using mdbook.
This includes a corresponding update to mdbook which avoids a regression in error_index_generator.
Closes https://github.com/rust-lang/rust/issues/137052
|
|
Make ub_check message clear that it's not an assert
I've seen a user assume that their unsound code was *safe*, because ub_check prevented the program from performing the unsafe operation.
This PR makes the panic message clearer that ub_check is a bug detector, not run-time safety protection.
|
|
Move methods from `Map` to `TyCtxt`, part 2.
Continuing the work started in #136466.
Every method gains a `hir_` prefix, though for the ones that already have a `par_` or `try_par_` prefix I added the `hir_` after that.
r? Zalathar
|
|
Continuing the work started in #136466.
Every method gains a `hir_` prefix, though for the ones that already
have a `par_` or `try_par_` prefix I added the `hir_` after that.
|
|
I believe this is trying to say there is something that is in the file,
but shouldn't be.
|
|
I had forgotten that error_index_generator is using mdbook. This moves
it to be part of the rustbook workspace so that it can share the
dependency with rustbook.
|
|
Changelog: https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md#mdbook-0445
|
|
Subtree update of `rust-analyzer`
r? `@ghost`
|
|
Pass vendored sources from bootstrap to generate-copyright
In addition to doing the vendoring in bootstrap, this PR also loads the list of manifests to parse from bootstrap (instead of hardcoding a smaller list in generate-copyright). This is best reviewed commit-by-commit.
Fixes https://github.com/rust-lang/rust/issues/136955
|
|
|
|
minor: Sync from downstream
|
|
|
|
fix: Fix detection of ref patterns for path patterns
|
|
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #137095 (Replace some u64 hashes with Hash64)
- #137100 (HIR analysis: Remove unnecessary abstraction over list of clauses)
- #137105 (Restrict DerefPure for Cow<T> impl to T = impl Clone, [impl Clone], str.)
- #137120 (Enable `relative-path-include-bytes-132203` rustdoc-ui test on Windows)
- #137125 (Re-add missing empty lines in the releases notes)
- #137145 (use add-core-stubs / minicore for a few more tests)
- #137149 (Remove SSE ABI from i586-pc-windows-msvc)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
I was wrong on #19127, I thought hir-def resolver is enough for them, but it turns out not because of paths like `<Enum>::Variant` and `Type::AssocThatIsEnum::Variant`.
|
|
Implement expand_glob_reexport assist
|
|
pass struct fields to chalk
|
|
feat: Refactor path lowering and serve a new path diagnostic
|
|
Replace some u64 hashes with Hash64
I introduced the Hash64 and Hash128 types in https://github.com/rust-lang/rust/pull/110083, essentially as a mechanism to prevent hashes from landing in our leb128 encoding paths. If you just have a u64 or u128 field in a struct then derive Encodable/Decodable, that number gets leb128 encoding. So if you need to store a hash or some other value which behaves very close to a hash, don't store it as a u64.
This reverts part of https://github.com/rust-lang/rust/pull/117603, which turned an encoded Hash64 into a u64.
Based on https://github.com/rust-lang/rust/pull/110083, I don't expect this to be perf-sensitive on its own, though I expect that it may help stabilize some of the small rmeta size fluctuations we currently see in perf reports.
|
|
`invalid_from_utf8[_unchecked]`: also lint inherent methods
Addressing https://github.com/rust-lang/rust/issues/131114#issuecomment-2646663535
Also corrected a typo: "_an_ invalid literal", not "_a_ invalid literal".
|
|
Overhaul `rustc_middle::limits`
In particular, to make `pattern_complexity` work more like other limits, which then enables some other simplifications.
r? ``@Nadrieril``
|
|
Start removing `rustc_middle::hir::map::Map`
`rustc_middle::hir::map::Map` is now just a low-value wrapper around `TyCtxt`. This PR starts removing it.
r? `@cjgillot`
|
|
First of all, note that `Map` has three different relevant meanings.
- The `intravisit::Map` trait.
- The `map::Map` struct.
- The `NestedFilter::Map` associated type.
The `intravisit::Map` trait is impl'd twice.
- For `!`, where the methods are all unreachable.
- For `map::Map`, which gets HIR stuff from the `TyCtxt`.
As part of getting rid of `map::Map`, this commit changes `impl
intravisit::Map for map::Map` to `impl intravisit::Map for TyCtxt`. It's
fairly straightforward except various things are renamed, because the
existing names would no longer have made sense.
- `trait intravisit::Map` becomes `trait intravisit::HirTyCtxt`, so named
because it gets some HIR stuff from a `TyCtxt`.
- `NestedFilter::Map` assoc type becomes `NestedFilter::MaybeTyCtxt`,
because it's always `!` or `TyCtxt`.
- `Visitor::nested_visit_map` becomes `Visitor::maybe_tcx`.
I deliberately made the new trait and associated type names different to
avoid the old `type Map: Map` situation, which I found confusing. We now
have `type MaybeTyCtxt: HirTyCtxt`.
|
|
The end goal is to eliminate `Map` altogether.
I added a `hir_` prefix to all of them, that seemed simplest. The
exceptions are `module_items` which became `hir_module_free_items` because
there was already a `hir_module_items`, and `items` which became
`hir_free_items` for consistency with `hir_module_free_items`.
|
|
There were two mistakes: first, tests were sorted before test modules, and second, we re-sorted based on the name only, which cancelled the sort based on the kind.
|
|
For consistency with `recursion_limit`, `move_size_limit`, and
`type_length_limit`.
|
|
It's similar to the other limits, e.g. obtained via `get_limit`. So it
makes sense to handle it consistently with the other limits. We now use
`Limit`/`usize` in most places instead of `Option<usize>`, so we use
`Limit::new(usize::MAX)`/`usize::MAX` to emulate how `None` used to work.
The commit also adds `Limit::unlimited`.
|
|
with rust-analyzer
|
|
And add a new diagnostic for non-`Fn` parenthesized generic args.
Path lowering started to look like a mess, with each function carrying additional parameters for the diagnostic callback (since paths can occur both in type and in expression/pattern position, and their diagnostic handling is different) and the segment index, for the diagnostics report. So I refactored it from stateless functions on `TyLoweringContext` into stateful struct, `PathLoweringContext`, that tracks the process of lowering a path from resolution til assoc types selection.
|
|
Apply unsafe_op_in_unsafe_fn to the standard library
This applies unsafe_op_in_unsafe_fn to the standard library in preparation for updating to Rust 2024.
Closes https://github.com/rust-lang/rust/issues/127747 (I think?) cc ``@workingjubilee``
I have been testing a variety of targets, and I feel like they are all pretty much covered. I'll continue doing some testing async, but I don't expect to catch any more.
|
|
fix: highlight `extern crate` in doc comments
|
|
internal: Remove mutable syntax tree usages from `add_missing_match_arms` assist
|
|
|
|
|
|
fix: Improve sort order of runnables
|
|
|
|
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #127581 (Fix crate name validation)
- #136490 (Do not allow attributes on struct field rest patterns)
- #136808 (Try to recover from path sep error in type parsing)
- #137055 (rustdoc: Properly restore search input placeholder)
- #137068 (fix(rustdoc): Fixed `Copy Item Path` in rust doc)
- #137070 (Do not generate invalid links in job summaries)
- #137074 (compiletest: add `{ignore,only}-rustc_abi-x86-sse2` directives)
- #137076 (triagebot.toml: ping me on changes to `tests/rustdoc-json`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Update cargo
13 commits in 2928e32734b04925ee51e1ae88bea9a83d2fd451..ce948f4616e3d4277e30c75c8bb01e094910df39
2025-02-07 16:50:22 +0000 to 2025-02-14 20:32:07 +0000
- util: provide a better error message for invalid SSH URLs (rust-lang/cargo#15185)
- Fix the description of the `"root"` field of the `cargo metadata`'s output (rust-lang/cargo#15182)
- refactor: Consolidate creation of SourceId from manifest path (rust-lang/cargo#15172)
- docs(embedded): Note the shebang deviation (rust-lang/cargo#15173)
- refactor(embedded): Integrate cargo-script logic into main parser (rust-lang/cargo#15168)
- feat: implement workspace feature unification (rust-lang/cargo#15157)
- Fix race condition in panic_abort_tests (rust-lang/cargo#15169)
- Update all dependencies (rust-lang/cargo#15166)
- Update curl from 8.9.0 to 8.12.0 (rust-lang/cargo#15162)
- Update annotate-snippets from 0.11.4 to 0.11.5 (rust-lang/cargo#15165)
- Update deny.toml (rust-lang/cargo#15164)
- Update rusqlite from 0.32.1 to 0.33.0 (rust-lang/cargo#15163)
- fix: align first line of unordered list with following (rust-lang/cargo#15161)
|
