avoid making substs of type aliases late bound when used as fn args
fixes#47511fixes#85533
(although I did not know theses issues existed when i was working on this 🙃)
currently `Alias<...>` is treated the same as `Struct<...>` when deciding if generics should be late bound or early bound but this is not correct as `Alias` might normalize to a projection which does not constrain the generics.
I think this needs more tests before merging
more explanation of PR [here](https://hackmd.io/v44a-QVjTIqqhK9uretyQg?view)
Hackmd inline for future readers:
---
This assumes reader is familiar with the concept of early/late bound lifetimes. There's a section on rustc-dev-guide if not (although i think some details are a bit out of date)
## problem & background
Not all lifetimes on a fn can be late bound:
```rust
fn foo<'a>() -> &'a ();
impl<'a> Fn<()> for FooFnDef {
type Output = &'a (); // uh oh unconstrained lifetime
}
```
so we make make them early bound
```rust
fn foo<'a>() -> &'a ();
impl<'a> Fn<()> for FooFnDef<'a> {// wow look at all that lifetimey
type Output = &'a ();
}
```
(Closures have the same constraint however it is not enforced leading to soundness bugs, [#84385](https://github.com/rust-lang/rust/pull/84385) implements this "downgrading late bound to early bound" for closures)
lifetimes on fn items are only late bound when they are "constrained" by the fn args:
```rust
fn foo<'a>(_: &'a ()) -> &'a ();
// late bound, not present on `FooFnItem`
// vv
impl<'a> Trait<(&'a (),)> for FooFnItem {
type Output = &'a ();
}
// projections do not constrain inputs
fn bar<'a, T: Trait>(_: <T as Trait<'a>>::Assoc) -> &'a (); // early bound
// vv
impl<'a, T: Trait> Fn<(<T as Trait<'a>>::Assoc,)> for BarFnItem<'a, T> {
type Output = &'a ();
}
```
current logic for determining if inputs "constrain" a lifetime works off of HIR so does not normalize aliases. It also assumes that any path with no self type constrains all its substs (i.e. `Foo<'a, u32>` has no self type but `T::Assoc` does). This falls apart for top level type aliases (see linked issues):
```rust
type Alias<'a, T> = <T as Trait<'a>>::Assoc;
// wow look its a path with no self type uwu
// i bet that constrains `'a` so it should be latebound
// vvvvvvvvvvv
fn foo<'a, T: Trait>(_: Alias<'a, T>) -> &'a ();
// `Alias` normalized to make things clearer
// vvvvvvvvvvvvvvvvvvvvvvv
impl<'a, T: Trait> Fn<(<T as Trait<'a>>::Assoc,)> for FooFnDef<T> {
type Output = &'a ();
// oh no `'a` isnt constrained wah wah waaaah *trumbone noises*
// i think, idk what musical instrument that is
}
```
## solution
The PR solves this by having the hir visitor that checks for lifetimes in constraining uses check if the path is a `DefKind::Alias`. If it is we ""normalize"" it by calling `type_of` and walking the returned type. This is a bit hacky as it requires a mapping between the substs on the path in hir, and the generics of the `type Alias<...>` which is on the ty layer.
Alternative solutions may involve calculating the "late boundness" of lifetimes after/during astconv rather than relying on hir at all. We already have code to determine whether a lifetime SHOULD be late bound or not as this is currently how the error for `fn foo<'a, T: Trait>(_: Alias<'a, T>) -> &'a ();` gets emitted.
It is probably not possible to do this right now, late boundness is used by `generics_of` and `gather_explicit_predicates_of` as we currently do not put late bound lifetimes in `Generics`. Although this seems sus to me as the long term goal is to make all generics late bound which would result in `generics_of(function)` being empty? [#103448](https://github.com/rust-lang/rust/pull/103448) places all lifetimes in `Generics` regardless of late boundness so that may be a good step towards making this possible.
Add split-debuginfo print option
This option prints all supported values for `-Csplit-debuginfo=..`, i.e. only stable ones on stable/beta and all of them on nightly/dev.
Motivated by 1.65.0 regression causing builds with the following entry in `Cargo.toml` to fail on Windows:
```toml
[profile.dev]
split-debuginfo = "unpacked"
```
See https://github.com/rust-lang/cargo/pull/11347 for details.
This will lead to closing https://github.com/rust-lang/rust/issues/103976.
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 debuginfo for windows_gnullvm_base.rs
These lines (including the FIXME comment) were added to windows_gnu_base.rs in cf2c492ef8 but windows_gnullvm_base.rs was not updated. This resulted in an error `LLVM ERROR: dwo only supported with ELF and Wasm` attempting to build on aarch64-pc-windows-gnullvm.
See also https://github.com/msys2/MINGW-packages/pull/13921#issuecomment-1304391707
/cc ```@mati865``` ```@davidtwco```
r? ```@davidtwco```
Remove `in_tail_expr` from FnCtxt
Cleans up yet another unneeded member from `FnCtxt`. The `in_tail_expr` condition wasn't even correct -- it was set for true while typechecking the whole fn body.
fix: lint against the functions `LintContext::{lookup_with_diagnostics,lookup,struct_span_lint,lint}`, `TyCtxt::struct_lint_node`, `LintLevelsBuilder::struct_lint`.
Normalize types when deducing closure signature from supertraits
Elaborated supertraits should be normalized, since there's no guarantee they don't contain projections 😅Fixes#104025
r? types
Mention const and lifetime parameters in error E0207
Error Index for E0207 must mention const and lifetime parameters. In addition, add code examples for these situations.
Fixes#80862
Remove #![allow(rustc::potential_query_instability)] from rustc_infer
Related to #84447
This PR probably needs to be benchmarked to check for regressions.
These lines (including the FIXME comment) were added to windows_gnu_base.rs in cf2c492ef8 but windows_gnullvm_base.rs was not updated. This resulted in an error `LLVM ERROR: dwo only supported with ELF and Wasm` attempting to build on aarch64-pc-windows-gnullvm.
Signed-off-by: Jeremy Drake <github@jdrake.com>
LLVM 16: Update RISCV data layout
The RISCV data layout was changed in 974e2e690b.
This updates all `riscv64*` targets, though I don't really know what the difference between the `gc` and `imac` ones is.
Passes `x test codegen` at LLVM head and with the currently bundled LLVM version. Without this patch, some tests fail with:
> error: internal compiler error: compiler/rustc_codegen_llvm/src/context.rs:192:13: data-layout for target `riscv64gc-unknown-none-elf`, `e-m:e-p:64:64-i64:64-i128:128-n64-S128`, differs from LLVM target's `riscv64` default layout, `e-m:e-p:64:64-i64:64-i128:128-n32:64-S128
Add type_array to BaseTypeMethods
Moved `type_array` function to `rustc_codegen_ssa::BaseTypeMethods` trait. This allows using normal `alloca` function to create arrays as suggested in https://github.com/rust-lang/rust/pull/104022.
Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
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
