[`missing_fields_in_debug`]: don't ICE when self type is a generic param
Fixes#10887
This PR fixes an ICE that happens when the implementor (self type) of a `Debug` impl is a generic parameter.
The lint calls `TyCtxt::type_of` with that self type, which ICEs when called with generic parameters, so this just adds a quick check before getting there to ignore them.
That can only happen inside of core itself (afaik) because the orphan rules forbid defining an impl such as `impl<T> Debug for T` outside of core, so I'm not sure how to add a test for this.
It seems like this impl in particular caused this: https://doc.rust-lang.org/stable/std/fmt/trait.Debug.html#impl-Debug-for-F
changelog: [`missing_fields_in_debug`]: don't ICE on blanket `Debug` impl in core
Force all native libraries to be statically linked when linking a static binary
Previously, `#[link]` without an explicit `kind = "static"` would confuse the linker and end up producing a dynamically linked library because of the `-Bdynamic` flag. However this binary would not work correctly anyways since it was linked with startup code for a static binary.
This PR solves this by forcing all native libraries to be statically linked when the output is a static binary that cannot link to dynamic libraries anyways.
Fixes#108878Fixes#102993
Remember names of `cfg`-ed out items to mention them in diagnostics
# Examples
## `serde::Deserialize` without the `derive` feature (a classic beginner mistake)
I had to slightly modify serde so that it uses explicit re-exports instead of a glob re-export. (Update: a serde PR was merged that adds the manual re-exports)
```
error[E0433]: failed to resolve: could not find `Serialize` in `serde`
--> src/main.rs:1:17
|
1 | #[derive(serde::Serialize)]
| ^^^^^^^^^ could not find `Serialize` in `serde`
|
note: crate `serde` has an item named `Serialize` but it is inactive because its cfg predicate evaluated to false
--> /home/gh-Nilstrieb/.cargo/registry/src/index.crates.io-6f17d22bba15001f/serde-1.0.160/src/lib.rs:343:1
|
343 | #[cfg(feature = "serde_derive")]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
344 | pub use serde_derive::{Deserialize, Serialize};
| ^^^^^^^^^
= note: the item is gated behind the `serde_derive` feature
= note: see https://doc.rust-lang.org/cargo/reference/features.html for how to activate a crate's feature
```
(the suggestion is not ideal but that's serde's fault)
I already tested the metadata size impact locally by compiling the `windows` crate without any features. `800k` -> `809k`
r? `@ghost`
This patch just removes the `#[rustc_coinductive]` annotation from `BikeshedIntrinsicFrom` and flips the related tests to `check-fail`. Once an FCP for setting the annotation on the trait is approved, it could be enabled again.
Rollup of 6 pull requests
Successful merges:
- #112076 (Fall back to bidirectional normalizes-to if no subst-relate candidate in alias-relate goal)
- #112122 (Add `-Ztrait-solver=next-coherence`)
- #112251 (rustdoc: convert `if let Some()` that always matches to variable)
- #112345 (fix(expand): prevent infinity loop in macro containing only "///")
- #112359 (Respect `RUST_BACKTRACE` for delayed bugs)
- #112382 (download-rustc: Fix `x test core` on MacOS)
r? `@ghost`
`@rustbot` modify labels: rollup
fix: only generate trait bound for associated types in field types
Given the following definitions:
```rust
trait Trait {
type A;
type B;
type C;
}
#[derive(Clone)]
struct S<T: Trait>
where
T::A: Send,
{
qualified: <T as Trait>::B,
shorthand: T::C,
}
```
we currently expand the derive macro to:
```rust
impl<T> Clone for S<T>
where
T: Trait + Clone,
T::A: Clone,
T::B: Clone,
T::C: Clone,
{ /* ... */ }
```
This does not match how rustc expands it. Specifically, `Clone` bounds for `T::A` and `T::B` should not be generated.
The criteria for associated types to get bound seem to be 1) the associated type appears as part of field types AND 2) it's written in the shorthand form. I have no idea why rustc doesn't consider qualified associated types (there's even a comment that suggests they should be considered; see rust-lang/rust#50730), but it's important to follow rustc.
download-rustc: Fix `x test core` on MacOS
before, this hardcoded `.so` as the extension for dynamically linked objects, which is incorrect everywhere except linux.
Respect `RUST_BACKTRACE` for delayed bugs
Sometimes, especially with MIR validation, the backtraces from delayed bugs are noise and make it harder to look at them. Respect the environment variable and don't print it when the user doesn't want it.
fix(expand): prevent infinity loop in macro containing only "///"
Fixes https://github.com/rust-lang/rust/issues/112342
Issue #112342 was caused by an infinity loop in `parse_tt_inner`, and the state of it is as follows:
- `matcher`: `[Sequence, Token(Doc), SequenceKleeneOpNoSep(op: ZeroOrMore), Eof]`
- loop:
| Iteration | Action |
| - | - |
| 0 | enter `Sequence`|
| 1 | enter `Token(Doc)` and `mp.idx += 1` had been executed |
| 2 | enter `SequenceKleeneOpNoSep` and reset `mp.idx` to `1` |
| 3 | enter `Token(Doc)` again|
To prevent the infinite loop, a check for whether it only contains `DocComment` in `check_lhs_no_empty_seq` had been added.
Add `-Ztrait-solver=next-coherence`
Flag that conditionally uses the trait solver *only* during coherence, for more testing and/or eventual partial-migration onto the trait solver (in the medium- to long-term).
* This still uses the selection context in some of the coherence methods I think, so it's not "complete". Putting this up for review and/or for further work in-tree.
* I probably need to spend a bit more time making sure that we don't sneakily create any other infcx's during coherence that also need the new solver enabled.
r? `@lcnr`
Fall back to bidirectional normalizes-to if no subst-relate candidate in alias-relate goal
Sometimes we get into the case where the choice of normalizes-to branch in alias-relate are both valid, but we cannot make a choice of which one to take because they are different -- either returning equivalent but permuted region constraints, or equivalent opaque type definitions but differing modulo normalization.
In this case, we can make progress by considering a fourth candidate where we compute both normalizes-to branches together and canonicalize that as a response. This is essentially the AND intersection of both normalizes-to branches. In an ideal world, we'd be returning something more like the OR intersection of both branches, but we have no way of representing that either for regions (maybe eventually) or opaques (don't see that happening ever).
This is incomplete, so like the subst-relate fallback it's only considered outside of coherence. But it doesn't seem like a dramatic strengthening of inference or anything, and is useful for helping opaque type inference succeed when the hidden type is a projection.
## Example
Consider the goal - `AliasRelate(Tait, <[i32; 32] as IntoIterator>::IntoIter)`.
We have three ways of currently solving this goal:
1. SubstRelate - fails because we can't directly equate the substs of different alias kinds.
2. NormalizesToRhs - `Tait normalizes-to <[i32; 32] as IntoIterator>::IntoIter`
* Ends up infering opaque definition - `Tait := <[i32; 32] as IntoIterator>::IntoIter`
3. NormalizesToLhs - `<[i32; 32] as IntoIterator>::IntoIter normalizes-to Tait`
* Find impl candidate, substitute the associated type - `std::array::IntoIter<i32, 32>`
* Equate `std::array::IntoIter<i32, 32>` and `Tait`
* Ends up infering opaque definition - `Tait := std::array::IntoIter<i32, 32>`
The problem here is that 2 and 3 are essentially both valid, since we have aliases that normalize on both sides, but due to lazy norm, they end up inferring different opaque type definitions that are only equal *after* normalizing them further.
---
r? `@lcnr`
