[beta] Revert "Build shared LLVM lib for windows-gnullvm"
This reverts commit 1d1280aae1.
Looks like this causes problems (rust-lang/rust#155268) with certain LLVM bin tools not finding `libLLVM` on `*-windows-gnullvm`. This PR is a _minimal_ revert to return us to known state to alleviate time pressure to investigate.
r? @mati865
This reverts commit 1d1280aae1.
Looks like this causes problems with certain LLVM bin tools not finding
`libLLVM` on `*-windows-gnullvm`. This commit is a _minimal_ revert to
return us to known state to alleviate time pressure to investigate.
[beta] branch 1.96 release
This follows https://forge.rust-lang.org/release/process.html#beta-pr to branch beta. It also includes a backport of:
* Patch musl's CVE-2026-6042 and CVE-2026-40200 rust-lang/rust#155171
since it landed after beta branched but per security discussion is getting backported direct to stable.
r? me
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#152901 (Introduce a `#[diagnostic::on_unknown]` attribute)
- rust-lang/rust#155078 (Reject dangling attributes in where clauses)
- rust-lang/rust#154449 (Invert dependency between `rustc_errors` and `rustc_abi`.)
- rust-lang/rust#154646 (Add suggestion to `.to_owned()` used on `Cow` when borrowing)
- rust-lang/rust#154993 (compiletest: pass -Zunstable-options for unpretty and no-codegen paths)
- rust-lang/rust#155097 (Make `rustc_attr_parsing::SharedContext::emit_lint` take a `MultiSpan` instead of a `Span`)
Make `rustc_attr_parsing::SharedContext::emit_lint` take a `MultiSpan` instead of a `Span`
I'll likely need it for https://github.com/rust-lang/rust/pull/153721 to allow emitting the lint on one attribute at a time instead of each of the wrong values.
r? @JonathanBrouwer
compiletest: pass -Zunstable-options for unpretty and no-codegen paths
When using custom targets via `RUST_TARGET_PATH`, compiletest does not
consistently pass `-Zunstable-options` in all code paths.
In particular, `unpretty` and `-Zno-codegen` (typecheck) paths invoke
rustc without `-Zunstable-options`, which causes failures when the
target is not built-in.
Pass `-Zunstable-options` in these code paths to ensure consistent
behavior when using custom targets.
This primarily affects setups using custom targets without `.json`
suffix (resolved via `RUST_TARGET_PATH`).
Add suggestion to `.to_owned()` used on `Cow` when borrowing
fixesrust-lang/rust#144792
supersedes rust-lang/rust#144925 with the review comments addressed
the tests suggested from @Kivooeo from https://github.com/rust-lang/rust/pull/144925#discussion_r2252703007 didn't work entirely, because these tests failed due to error `[E0308]` mismatched types, which actually already provides a suggestion, that actually makes the code compile:
```
$ cargo check
error[E0308]: mismatched types
--> src/main.rs:3:5
|
1 | fn test_cow_suggestion() -> String {
| ------ expected `std::string::String` because of return type
2 | let os_string = std::ffi::OsString::from("test");
3 | os_string.to_string_lossy().to_owned()
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `String`, found `Cow<'_, str>`
|
= note: expected struct `std::string::String`
found enum `std::borrow::Cow<'_, str>`
help: try using a conversion method
|
3 | os_string.to_string_lossy().to_owned().to_string()
| ++++++++++++
```
now this suggestion is of course not good or efficient code, but via clippy with `-Wclippy::nursery` lint group you can actually get to the correct code, so i don't think this is too much of an issue:
<details>
<summary>the clippy suggestions</summary>
```
$ cargo clippy -- -Wclippy::nursery
warning: this `to_owned` call clones the `Cow<'_, str>` itself and does not cause its contents to become owned
--> src/main.rs:3:5
|
3 | os_string.to_string_lossy().to_owned().to_string()
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/beta/index.html#suspicious_to_owned
= note: `#[warn(clippy::suspicious_to_owned)]` on by default
help: depending on intent, either make the `Cow` an `Owned` variant
|
3 | os_string.to_string_lossy().into_owned().to_string()
| ++
help: or clone the `Cow` itself
|
3 - os_string.to_string_lossy().to_owned().to_string()
3 + os_string.to_string_lossy().clone().to_string()
|
$ # apply first suggestion
$ cargo c -- -Wclippy::nursery
warning: redundant clone
--> src/main.rs:3:45
|
3 | os_string.to_string_lossy().into_owned().to_string()
| ^^^^^^^^^^^^ help: remove this
|
note: this value is dropped without further use
--> src/main.rs:3:5
|
3 | os_string.to_string_lossy().into_owned().to_string()
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
= help: for further information visit https://rust-lang.github.io/rust-clippy/beta/index.html#redundant_clone
= note: `-W clippy::redundant-clone` implied by `-W clippy::nursery`
= help: to override `-W clippy::nursery` add `#[allow(clippy::redundant_clone)]`
```
</details>
the actual error that we are looking for is error `[E0515]`, cannot return value referencing local variable, which was only present in the original issue due to automatic type inference assuming you want to return a cloned `Cow<'_, str>`, which is of course not possible. this is why i took the original test functions and turned them into closures, where it's less obvious that it's trying to return the wrong type.
r? davidtwco
(because you reviewed the last attempt)
(also, let me know if i should squash this down to one commit and add myself as the co-contributor)
Invert dependency between `rustc_errors` and `rustc_abi`.
Currently, `rustc_errors` depends on `rustc_abi`, which depends on `rustc_error_messages`. This is a bit odd.
`rustc_errors` depends on `rustc_abi` for a single reason: `rustc_abi` defines a type `TargetDataLayoutErrors` and `rustc_errors` impls `Diagnostic` for that type.
We can get a more natural relationship by inverting the dependency, moving the `Diagnostic` trait upstream. Then `rustc_abi` defines `TargetDataLayoutErrors` and also impls `Diagnostic` for it. `rustc_errors` is already pretty far upstream in the crate graph, it doesn't hurt to push it a little further because errors are a very low-level concept.
r? @davidtwco
Reject dangling attributes in where clauses
Report `attribute without where predicates` for trailing outer attributes in where clauses.
Closesrust-lang/rust#155073 .
Introduce a `#[diagnostic::on_unknown]` attribute
This PR introduces a `#[diagnostic::on_unknown]` attribute that allows crate authors to customize the error messages emitted by unresolved imports. The main usecase for this is using this attribute as part of a proc macro that expects a certain external module structure to exist or certain dependencies to be there.
For me personally the motivating use-case are several derives in diesel, that expect to refer to a `tabe` module. That is done either implicitly (via the name of the type with the derive) or explicitly by the user. This attribute would allow us to improve the error message in both cases:
* For the implicit case we could explicity call out our assumptions (turning the name into lower case, adding an `s` in the end)
+ point to the explicit variant as alternative
* For the explicit variant we would add additional notes to tell the user why this is happening and what they should look for to fix the problem (be more explicit about certain diesel specific assumptions of the module structure)
I assume that similar use-cases exist for other proc-macros as well, therefore I decided to put in the work implementing this new attribute. I would also assume that this is likely not useful for std-lib internal usage.
related rust-lang/rust#152900 and rust-lang/rust#128674
Fix code block whitespace handling in Markdown
### Fix Markdown code block closing whitespace handling
Previously, the parser incorrectly accepted closing backticks followed by extra text and rejected lines where only spaces appeared after closing backticks. This did not match expected Markdown behavior.
Now, the parser correctly ends a code block only when line after the code ends with spaces or nothing. Lines where extra text appears after the closing backticks are treated as part of the code block.
Includes tests for both correct and incorrect cases.
### Related issue
This PR addresses the Outreachy issue: [Markdown whitespace bug in Rust Compiler](https://github.com/rustfoundation/interop-initiative/issues/53)
delegation: fix unelided lifetime ICE, refactoring of GenericArgPosition
This PR does two things:
- First it restores `lower_generic_args_of_path` as it was before rust-lang/rust#151864, as it turns out we should use `GenericArgPosition::Type` for generic args lowering for signature inheritance, as it will not cause lifetime inference and then ICEs during child args lowering,
- Next it refactors `GenericArgPosition` enum replacing `Value` and `MethodCall` with `Call(IsMethodCall)`, as the only place where we created `Value` or `MethodCall` variants was in `check_generic_arg_count_for_call`, where it was a match over `is_method_call`. Not sure it is needed, but seems cleaner to me.
Fixesrust-lang/rust#154178, part of rust-lang/rust#118212.
r? @petrochenkov
Fix `pattern_from_macro_note` for bit-or expr
This is a continuation of issue https://github.com/rust-lang/rust/issues/99380 (and pr https://github.com/rust-lang/rust/pull/124488) but covers bit-or pattern.
Essentially a `pat1 | pat2`, or any bit-or pattern used in a `$e:expr` was not firing the `.pattern_from_macro_note` diagnostic bc `ast::Expr::is_approximately_pattern()` did not cover bit-or.
The cover for bit-or is only added in `lower_expr_within_pat()`, otherwise doing it in `is_approximately_pattern()` would result in the suggestion `if (i + 2) = 2 => if let (i + 2) = 2` from `suggest_pattern_match_with_let()` (which is the only other place `ast::Expr::is_approximately_pattern()` is used from what i see).
resolves https://github.com/rust-lang/rust/issues/99380
refs https://github.com/rust-lang/rust/pull/124488
Fix ICE when combining #[eii] with #[core::contracts::ensures]
Fixesrust-lang/rust#153745
Builtin attribute macros like #[eii] generate AST items programmatically without collected tokens. When another attribute macro was present on the same item, the compiler would panic in TokenStream::from_ast() trying to tokenize the generated items during subsequent attribute expansion.
Generate fake token streams (via pretty-print and re-parse) for Item and ForeignItem nodes that lack collected tokens, following the existing pattern used for Crate and out-of-line modules.
Restrict EII declarations to functions at lowering time
We tighten EII declaration resolution so that `lower_path_simple_eii` only accepts function‑like items (`Fn, AssocFn, Ctor(_, Fn)`) as valid EII targets. If name resolution points at something else (like a const with the same name), we now emit a direct error (“`externally implementable items must refer to a function`”) at the declaration site, which prevents bad `DefIds` from ever reaching `compare_eii_function_types` and turning into an ICE
this is more robust and root-cause oriented fix to rust-lang/rust#152337 issue and an alternate of my more simple PR rust-lang/rust#152365
test included
Simplify `try_load_from_disk_fn`.
`try_load_from_disk_fn` has a single call site. We can move some of the stuff within it to its single call site, which simplifies it, and also results in all of the query profiling code ending up in the same module. Details in individual commits.
r? @Zalathar
Always exhaustively match on typing mode
r? @lcnr
Unimplements Eq/PartialEq for TypingMode, adds TypingModeEqWrapper for the few cases where we need it (mainly in the query system), and adds a new rustc internal lint to detect cases where we non-exhaustively match on typing mode.
Moreover, dereference `ty_layout.align` for `#[rustc_dump_layout(align)]`
to render `align: Align($N bytes)` instead of `align: AbiAlign { abi: Align($N bytes) }`
which contains the same amount of information but it more concise and legible.
This PR introduces a `#[diagnostic::on_unknown_item]` attribute that
allows crate authors to customize the error messages emitted by
unresolved imports. The main usecase for this is using this attribute as
part of a proc macro that expects a certain external module structure to
exist or certain dependencies to be there.
For me personally the motivating use-case are several derives in diesel,
that expect to refer to a `tabe` module. That is done either
implicitly (via the name of the type with the derive) or explicitly by
the user. This attribute would allow us to improve the error message in
both cases:
* For the implicit case we could explicity call out our
assumptions (turning the name into lower case, adding an `s` in the end)
+ point to the explicit variant as alternative
* For the explicit variant we would add additional notes to tell the
user why this is happening and what they should look for to fix the
problem (be more explicit about certain diesel specific assumptions of
the module structure)
I assume that similar use-cases exist for other proc-macros as well,
therefore I decided to put in the work implementing this new attribute.
I would also assume that this is likely not useful for std-lib internal
usage.
Rollup of 10 pull requests
Successful merges:
- rust-lang/rust#154973 (Break a single query cycle in the deadlock handler)
- rust-lang/rust#155034 (Implement `GenericTypeVisitable` for some types)
- rust-lang/rust#151377 (Fix linker error by resolving regions for main return type obligations)
- rust-lang/rust#154677 (hwaddress: automatically add `-Ctarget-feature=+tagged-globals`)
- rust-lang/rust#154774 (Add myself as co-maintainer for hexagon-unknown-linux-musl)
- rust-lang/rust#155015 (Add tests for three fixed issues (an LLVM crash, an ICE and poor codegen))
- rust-lang/rust#155039 (minor follow up to removing soft mode `#[unstable]`)
- rust-lang/rust#155043 (Fix if branch in op.rs)
- rust-lang/rust#155071 (Deny `#[global_allocator]` + `#[thread_local]`)
- rust-lang/rust#155072 (Set the Fuchsia ABI to the documented minimum)
From `plumbing.rs` to `execution.rs`, which is where most of the other
query profiling occurs. It also avoids eliminates some fn parameters.
This means the `provided_to_erased` call in `try_from_load_disk_fn` is
now included in the profiling when previously it wasn't. This is
good because `provided_to_erased` is included in other profiling calls
(e.g. calls to `invoke_provider_fn`).
Deny `#[global_allocator]` + `#[thread_local]`
This forbids using `#[thread_local]` on `static` items that are also `#[global_allocator]`s.
Fixesrust-lang/rust#85517.
bors