Resolve lifetimes independently for each item-like.
Now that the heavy-lifting is done on the AST and during lowering, we do not need to perform HIR lifetime resolution on a full item at once. Instead, we can treat each item-like independently, and look at `generics_of` the parent exceptionally for associated items.
Use `const_error_with_guaranteed` more
Better to pass down an ErrorGuaranteed rather than making a new one out of thin air, for some usages. Also for the ones where we *do* need to delay a bug, that delayed bug will have a more descriptive message.
Add support for custom mir
This implements rust-lang/compiler-team#564 . Details about the design, motivation, etc. can be found in there.
r? ```@oli-obk```
Rollup of 7 pull requests
Successful merges:
- #100508 (avoid making substs of type aliases late bound when used as fn args)
- #101381 (Test that target feature mix up with homogeneous floats is sound)
- #103353 (Fix Access Violation when using lld & ThinLTO on windows-msvc)
- #103521 (Avoid possible infinite loop when next_point reaching the end of file)
- #103559 (first move on a nested span_label)
- #103778 (Update several crates for improved support of the new targets)
- #103827 (Properly remap and check for substs compatibility in `confirm_impl_trait_in_trait_candidate`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Better error for HRTB error from generator interior
cc #100013
This is just a first pass at an error. It could be better, and shouldn't really be emitted in the first place. But this is better than what was being emitted before.
selection failure: recompute applicable impls
The way we currently skip errors for ambiguous trait obligations seems pretty fragile so we get some duplicate errors because of this.
Removing this info from selection errors changes this system to be closer to my image of our new trait solver and is also making it far easier to change overflow errors to be non-fatal ✨
r? types cc `@estebank`
resolve: More detailed effective visibility tracking for imports
Per-`DefId` tracking is not enough, due to glob imports in particular, which have a single `DefId` for the whole glob import item.
We need to track this stuff per every introduced name (`NameBinding`).
Also drop `extern` blocks from the effective visibility table, they are nominally private and it doesn't make sense to keep them there.
Later commits add some debug-only invariant checking and optimiaztions to mitigate regressions in https://github.com/rust-lang/rust/pull/103965#issuecomment-1304256445.
This is a bugfix and continuation of https://github.com/rust-lang/rust/pull/102026.
fix: lint against the functions `LintContext::{lookup_with_diagnostics,lookup,struct_span_lint,lint}`, `TyCtxt::struct_lint_node`, `LintLevelsBuilder::struct_lint`.
Implement `std::marker::Tuple`, use it in `extern "rust-call"` and `Fn`-family traits
Implements rust-lang/compiler-team#537
I made a few opinionated decisions in this implementation, specifically:
1. Enforcing `extern "rust-call"` on fn items during wfcheck,
2. Enforcing this for all functions (not just ones that have bodies),
3. Gating this `Tuple` marker trait behind its own feature, instead of grouping it into (e.g.) `unboxed_closures`.
Still needing to be done:
1. Enforce that `extern "rust-call"` `fn`-ptrs are well-formed only if they have 1/2 args and the second one implements `Tuple`. (Doing this would fix ICE in #66696.)
2. Deny all explicit/user `impl`s of the `Tuple` trait, kinda like `Sized`.
3. Fixing `Tuple` trait built-in impl for chalk, so that chalkification tests are un-broken.
Open questions:
1. Does this need t-lang or t-libs signoff?
Fixes#99820
minor changes to make method lookup diagnostic code easier to read
The end result of around 4 days of trying to understand this 1000+ line long function- a bunch of tiny nitpicks
r? `@compiler-errors`
