non_lifetime_binders: fix ICE in lint opaque-hidden-inferred-bound
Opaque types like `impl for<T> Trait<T>` would previously lead to an ICE.
r? `@compiler-errors`
a small wf and clause cleanup
- remove `Clause::from_projection_clause`, instead use `ToPredicate`
- change `predicate_obligations` to directly take a `Clause`
- remove some unnecessary `&`
- use clause in `min_specialization` checks where easily applicable
Suggest `pin!()` instead of `Pin::new()` when appropriate
When encountering a type that needs to be pinned but that is `!Unpin`, suggest using the `pin!()` macro.
Fix#57994.
Rollup of 5 pull requests
Successful merges:
- #115863 (Add check_unused_messages in tidy)
- #116210 (Ensure that `~const` trait bounds on associated functions are in const traits or impls)
- #116358 (Rename both of the `Match` relations)
- #116371 (Remove unused features from `rustc_llvm`.)
- #116374 (Print normalized ty)
r? `@ghost`
`@rustbot` modify labels: rollup
Print normalized ty
Inside `mir_assign_valid_types` we are comparing normalized type of `mir_place` but in debug message we are not printing the normalized value, this changes that.
Don't suggest nonsense suggestions for unconstrained type vars in `note_source_of_type_mismatch_constraint`
The way we do type inference for suggestions in `note_source_of_type_mismatch_constraint` is a bit strange. We compute the "ideal" method signature, which takes the receiver that we *want* and uses it to compute the types of the arguments that would have given us that receiver via type inference, and use *that* to suggest how to change an argument to make sure our receiver type is inferred correctly.
The problem is that sometimes we have totally unconstrained arguments (well, they're constrained by things outside of the type checker per se, like associated types), and therefore type suggestions are happy to coerce anything to that unconstrained argument. This leads to bogus suggestions, like #116155. This is partly due to above, and partly due to the fact that `emit_type_mismatch_suggestions` doesn't double check that its suggestions are actually compatible with the program other than trying to satisfy the type mismatch.
This adds a hack to make sure that at least the types are fully constrained, but I guess I could also rip out this logic altogether. There would be some sad diagnostics regressions though, such as `tests/ui/type/type-check/point-at-inference-4.rs`.
Fixes#116155
For a single impl candidate, try to unify it with error trait ref
This allows us to point out an exact type mismatch when there's only one applicable impl.
cc `@asquared31415`
r? `@estebank`
bootstrap major change detection implementation
The use of `changelog-seen` and `bootstrap/CHANGELOG.md` has not been functional in any way for many years. We often do major/breaking changes but never update the changelog file or the `changelog-seen`. This is an alternative method for tracking major or breaking changes and informing developers when such changes occur.
Example output when bootstrap detects a major change:
![image](https://github.com/rust-lang/rust/assets/39852038/ee802dfa-a02b-488b-a433-f853ce079b8a)
Cleanup number handling in match exhaustiveness
Doing a little bit of cleanup; handling number constants was somewhat messy. In particular, this:
- evals float consts once instead of repetitively
- reduces `Constructor` from 88 bytes to 56 (`mir::Const` is big!)
The `fast_try_eval_bits` function was mostly constructed from inlining existing code but I don't fully understand it; I don't follow how consts work and are evaluated very well.
resolve: skip underscore character during candidate lookup
Fixes#116164
In use statement, an underscore is merely a placeholder symbol and does not bind to any name. Therefore, it can be safely ignored.
Partially outline code inside the panic! macro
This outlines code inside the panic! macro in some cases. This is split out from https://github.com/rust-lang/rust/pull/115562 to exclude changes to rustc.
Previously, any associated function could have `~const` trait bounds on
generic parameters, which could lead to ICEs when these bounds were used
on associated functions of non-`#[const_trait] trait` or
non-`impl const` blocks.
Includes changes as per @fee1-dead's comments in #116210.