Rollup of 7 pull requests
Successful merges:
- #122382 (Detect unused structs which implement private traits)
- #124389 (Add a warning to proc_macro::Delimiter::None that rustc currently does not respect it.)
- #125224 (Migrate `run-make/issue-53964` to `rmake`)
- #125227 (Migrate `run-make/issue-30063` to `rmake`)
- #125336 (Add dedicated definition for intrinsics)
- #125401 (Migrate `run-make/rustdoc-scrape-examples-macros` to `rmake.rs`)
- #125454 (Improve the doc of query associated_item)
r? `@ghost`
`@rustbot` modify labels: rollup
Improve the doc of query associated_item
<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.
This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using
r? <reviewer name>
-->
This query also maps from a impl item to the impl item "descriptor". So it's a bit confused, I skipped it cause it doesn't say it contains impl items.
```rust
fn associated_item(tcx: TyCtxt<'_>, def_id: LocalDefId) -> ty::AssocItem {
let id = tcx.local_def_id_to_hir_id(def_id);
let parent_def_id = tcx.hir().get_parent_item(id);
let parent_item = tcx.hir().expect_item(parent_def_id.def_id);
match parent_item.kind {
hir::ItemKind::Impl(impl_) => {
if let Some(impl_item_ref) = impl_.items.iter().find(|i| i.id.owner_id.def_id == def_id)
{
let assoc_item = associated_item_from_impl_item_ref(impl_item_ref);
debug_assert_eq!(assoc_item.def_id.expect_local(), def_id);
return assoc_item;
}
}
hir::ItemKind::Trait(.., trait_item_refs) => {
if let Some(trait_item_ref) =
trait_item_refs.iter().find(|i| i.id.owner_id.def_id == def_id)
{
let assoc_item = associated_item_from_trait_item_ref(trait_item_ref);
debug_assert_eq!(assoc_item.def_id.expect_local(), def_id);
return assoc_item;
}
}
_ => {}
}
span_bug!(
parent_item.span,
"unexpected parent of trait or impl item or item not found: {:?}",
parent_item.kind
)
}
```
Migrate `run-make/issue-53964` to `rmake`
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
This is extremely similar to #125146. Could it be interesting to merge the two in some way? This one seems to do the same thing as the #125146, but with an added check that a useless lint is not shown.
Add a warning to proc_macro::Delimiter::None that rustc currently does not respect it.
It does not provide the behaviour it is indicated to provide when used in a proc_macro context.
This seems to be a bug, (https://github.com/rust-lang/rust/issues/67062), but it is a long standing one, and hard to discover.
This pull request adds a warning to inform users of this issue, with a link to the relevant issue, and a version number of the last known affected rustc version.
Rewrite native thread-local storage
(part of #110897)
The current native thread-local storage implementation has become quite messy, uses indescriptive names and unnecessarily adds code to the macro expansion. This PR tries to fix that by using a new implementation that also allows more layout optimizations and potentially increases performance by eliminating unnecessary TLS accesses.
This does not change the recursive initialization behaviour I described in [this comment](https://github.com/rust-lang/rust/issues/110897#issuecomment-1525705682), so it should be a library-only change. Changing that behaviour should be quite easy now, however.
r? `@m-ou-se`
`@rustbot` label +T-libs
Rollup of 8 pull requests
Successful merges:
- #124297 (Allow coercing functions whose signature differs in opaque types in their defining scope into a shared function pointer type)
- #124516 (Allow monomorphization time const eval failures if the cause is a type layout issue)
- #124976 (rustc: Use `tcx.used_crates(())` more)
- #125210 (Cleanup: Fix up some diagnostics)
- #125409 (Rename `FrameworkOnlyWindows` to `RawDylibOnlyWindows`)
- #125416 (Use correct param-env in `MissingCopyImplementations`)
- #125421 (Rewrite `core-no-oom-handling`, `issue-24445` and `issue-38237` `run-make` tests to new `rmake.rs` format)
- #125438 (Remove unneeded string conversion)
r? `@ghost`
`@rustbot` modify labels: rollup
Rewrite `core-no-oom-handling`, `issue-24445` and `issue-38237` `run-make` tests to new `rmake.rs` format
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
The test which is now called `non-pie-thread-local` has an unexplained "only-linux" flag. Could it be worth trying to remove it and changing the CI to test non-Linux platforms on it?
Use correct param-env in `MissingCopyImplementations`
We shouldn't assume the param-env is empty for this lint, since although we check the struct has no parameters, there still may be trivial where-clauses.
fixes#125394
Cleanup: Fix up some diagnostics
Several diagnostics contained their error code inside their primary message which is no bueno.
This PR moves them out of the message and turns them into structured error codes.
Also fixes another occurrence of `->` after a selector in a Fluent message which is not correct. I've fixed two other instances of this issue in #104345 (2022) but didn't update all instances as I've noted here: https://github.com/rust-lang/rust/pull/104345#issuecomment-1312705977 (“the future is now!”).
Allow coercing functions whose signature differs in opaque types in their defining scope into a shared function pointer type
r? `@compiler-errors`
This accepts more code on stable. It is now possible to have match arms return a function item `foo` and a different function item `bar` in another, and that will constrain OpaqueTypeInDefiningScope to have the hidden type ConcreteType and make the type of the match arms a function pointer that matches the signature. So the following function will now compile, but on master it errors with a type mismatch on the second match arm
```rust
fn foo<T>(t: T) -> T {
t
}
fn bar<T>(t: T) -> T {
t
}
fn k() -> impl Sized {
fn bind<T, F: FnOnce(T) -> T>(_: T, f: F) -> F {
f
}
let x = match true {
true => {
let f = foo;
bind(k(), f)
}
false => bar::<()>,
};
todo!()
}
```
cc https://github.com/rust-lang/rust/issues/116652
This is very similar to https://github.com/rust-lang/rust/pull/123794, and with the same rationale:
> this is for consistency with `-Znext-solver`. the new solver does not have the concept of "non-defining use of opaque" right now and we would like to ideally keep it that way. Moving to `DefineOpaqueTypes::Yes` in more cases removes subtlety from the type system. Right now we have to be careful when relating `Opaque` with another type as the behavior changes depending on whether we later use the `Opaque` or its hidden type directly (even though they are equal), if that later use is with `DefineOpaqueTypes::No`*
self-contained linker: retry linking without `-fuse-ld=lld` on CCs that don't support it
For the self-contained linker, this PR applies [the strategy](https://github.com/rust-lang/rust/issues/125330#issuecomment-2125119838) of retrying the linking step when the driver doesn't support `-fuse-ld=lld`, but with the option removed. This is the same strategy we already use of retrying when e.g. `-no-pie` is not supported.
Fixes#125330
r? `@petrochenkov`
I have no idea how we could add a test here, much like we don't have one for `-no-pie` or `-static-pie` -- let me know if you have ideas -- but I tested on a CentOS7 image:
```console
[root@d25b38376ede tmp]# ../build/host/stage1/bin/rustc helloworld.rs
WARN rustc_codegen_ssa:🔙:link The linker driver does not support `-fuse-ld=lld`. Retrying without it.
[root@d25b38376ede tmp]# readelf -p .comment helloworld
String dump of section '.comment':
[ 0] GCC: (GNU) 4.8.5 20150623 (Red Hat 4.8.5-44)
[ 2d] rustc version 1.80.0-dev
```
I wasn't able to test with `cross` as the issue describes: I wasn't able to reproduce that behavior locally.
Expand `for_loops_over_fallibles` lint to lint on fallibles behind references.
Extends the scope of the (warn-by-default) lint `for_loops_over_fallibles` from just `for _ in x` where `x: Option<_>/Result<_, _>` to also cover `x: &(mut) Option<_>/Result<_>`
```rs
fn main() {
// Current lints
for _ in Some(42) {}
for _ in Ok::<_, i32>(42) {}
// New lints
for _ in &Some(42) {}
for _ in &mut Some(42) {}
for _ in &Ok::<_, i32>(42) {}
for _ in &mut Ok::<_, i32>(42) {}
// Should not lint
for _ in Some(42).into_iter() {}
for _ in Some(42).iter() {}
for _ in Some(42).iter_mut() {}
for _ in Ok::<_, i32>(42).into_iter() {}
for _ in Ok::<_, i32>(42).iter() {}
for _ in Ok::<_, i32>(42).iter_mut() {}
}
```
<details><summary><code>cargo build</code> diff</summary>
```diff
diff --git a/old.out b/new.out
index 84215aa..ca195a7 100644
--- a/old.out
+++ b/new.out
`@@` -1,33 +1,93 `@@`
warning: for loop over an `Option`. This is more readably written as an `if let` statement
--> src/main.rs:3:14
|
3 | for _ in Some(42) {}
| ^^^^^^^^
|
= note: `#[warn(for_loops_over_fallibles)]` on by default
help: to check pattern in a loop use `while let`
|
3 | while let Some(_) = Some(42) {}
| ~~~~~~~~~~~~~~~ ~~~
help: consider using `if let` to clear intent
|
3 | if let Some(_) = Some(42) {}
| ~~~~~~~~~~~~ ~~~
warning: for loop over a `Result`. This is more readably written as an `if let` statement
--> src/main.rs:4:14
|
4 | for _ in Ok::<_, i32>(42) {}
| ^^^^^^^^^^^^^^^^
|
help: to check pattern in a loop use `while let`
|
4 | while let Ok(_) = Ok::<_, i32>(42) {}
| ~~~~~~~~~~~~~ ~~~
help: consider using `if let` to clear intent
|
4 | if let Ok(_) = Ok::<_, i32>(42) {}
| ~~~~~~~~~~ ~~~
-warning: `for-loops-over-fallibles` (bin "for-loops-over-fallibles") generated 2 warnings
- Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.04s
+warning: for loop over a `&Option`. This is more readably written as an `if let` statement
+ --> src/main.rs:7:14
+ |
+7 | for _ in &Some(42) {}
+ | ^^^^^^^^^
+ |
+help: to check pattern in a loop use `while let`
+ |
+7 | while let Some(_) = &Some(42) {}
+ | ~~~~~~~~~~~~~~~ ~~~
+help: consider using `if let` to clear intent
+ |
+7 | if let Some(_) = &Some(42) {}
+ | ~~~~~~~~~~~~ ~~~
+
+warning: for loop over a `&mut Option`. This is more readably written as an `if let` statement
+ --> src/main.rs:8:14
+ |
+8 | for _ in &mut Some(42) {}
+ | ^^^^^^^^^^^^^
+ |
+help: to check pattern in a loop use `while let`
+ |
+8 | while let Some(_) = &mut Some(42) {}
+ | ~~~~~~~~~~~~~~~ ~~~
+help: consider using `if let` to clear intent
+ |
+8 | if let Some(_) = &mut Some(42) {}
+ | ~~~~~~~~~~~~ ~~~
+
+warning: for loop over a `&Result`. This is more readably written as an `if let` statement
+ --> src/main.rs:9:14
+ |
+9 | for _ in &Ok::<_, i32>(42) {}
+ | ^^^^^^^^^^^^^^^^^
+ |
+help: to check pattern in a loop use `while let`
+ |
+9 | while let Ok(_) = &Ok::<_, i32>(42) {}
+ | ~~~~~~~~~~~~~ ~~~
+help: consider using `if let` to clear intent
+ |
+9 | if let Ok(_) = &Ok::<_, i32>(42) {}
+ | ~~~~~~~~~~ ~~~
+
+warning: for loop over a `&mut Result`. This is more readably written as an `if let` statement
+ --> src/main.rs:10:14
+ |
+10 | for _ in &mut Ok::<_, i32>(42) {}
+ | ^^^^^^^^^^^^^^^^^^^^^
+ |
+help: to check pattern in a loop use `while let`
+ |
+10 | while let Ok(_) = &mut Ok::<_, i32>(42) {}
+ | ~~~~~~~~~~~~~ ~~~
+help: consider using `if let` to clear intent
+ |
+10 | if let Ok(_) = &mut Ok::<_, i32>(42) {}
+ | ~~~~~~~~~~ ~~~
+
+warning: `for-loops-over-fallibles` (bin "for-loops-over-fallibles") generated 6 warnings
+ Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.02s
```
</details>
-----
Question:
* ~~Currently, the article `an` is used for `&Option`, and `&mut Option` in the lint diagnostic, since that's what `Option` uses. Is this okay or should it be changed? (likewise, `a` is used for `&Result` and `&mut Result`)~~ The article `a` is used for `&Option`, `&mut Option`, `&Result`, `&mut Result` and (as before) `Result`. Only `Option` uses `an` (as before).
`@rustbot` label +A-lint
Fix OutsideLoop's error suggestion: adding label `'block` for `if` block.
For OutsideLoop we should not suggest add `'block` label in `if` block, or we wiil get another err: block label not supported here.
fixes#123261
Add some tests for public-private dependencies.
This adds some tests to show more scenarios for the `exported_private_dependencies` lint. Several of these illustrate that the lint is not working as expected, and I have annotated those places with `FIXME`.
Note also that this includes some diamond dependency structures which compiletest doesn't exactly support. However, I don't think it should be a problem, it just results in the common dependency being built twice.
Rollup of 7 pull requests
Successful merges:
- #125043 (reference type safety invariant docs: clarification)
- #125306 (Force the inner coroutine of an async closure to `move` if the outer closure is `move` and `FnOnce`)
- #125355 (Use Backtrace::force_capture instead of Backtrace::capture in rustc_log)
- #125382 (rustdoc: rename `issue-\d+.rs` tests to have meaningful names (part 7))
- #125391 (Minor serialize/span tweaks)
- #125395 (Remove unnecessary `.md` from the documentation sidebar)
- #125399 (Stop using `to_hir_binop` in codegen)
r? `@ghost`
`@rustbot` modify labels: rollup
Stop using `to_hir_binop` in codegen
This came up in https://github.com/rust-lang/rust/pull/125359#discussion_r1609401311 , and looking into it we can just use the `mir::BinOp`s directly instead of `hir::BinOpKind`s.
(AKA rather than going `mir::BinOp` → `hir::BinOpKind` → `IntPredicate`, just go `mir::BinOp` → `IntPredicate`.)
Use Backtrace::force_capture instead of Backtrace::capture in rustc_log
After https://github.com/rust-lang/rust/pull/125063, the compiler and custom drivers won't automatically set the RUST_BACKTRACE environment variable anymore, so we have to call `Backtrace::force_capture` instead of `Backtrace::capture` to unconditionally capture a backtrace.
rustc_log handles enabling backtraces via env vars itself, so we don't want RUST_BACKTRACE to make a difference.
Force the inner coroutine of an async closure to `move` if the outer closure is `move` and `FnOnce`
See the detailed comment in `upvar.rs`.
Fixes#124867.
Fixes#124487.
r? oli-obk
reference type safety invariant docs: clarification
The old text could have been read as saying that you can call a function if these requirements are upheld, which is definitely not true as they are an underapproximation of the actual safety invariant.
I removed the part about functions relaxing the requirements via their documentation... this seems incoherent with saying that it may actually be unsound to ever temporarily violate the requirement. Furthermore, a function *cannot* just relax this for its return value, that would in general be unsound. And the part about "unsafe code in a safe function may assume these invariants are ensured of arguments passed by the caller" also interacts with relaxing things: clearly, if the invariant has been relaxed, unsafe code cannot rely on it any more. There may be a place to give general guidance on what kinds of function contracts can exist, but the reference type is definitely not the right place to write that down.
I also took a clarification from https://github.com/rust-lang/rust/pull/121965 that is orthogonal to the rest of that PR.
Cc ```@joshlf``` ```@scottmcm```
