Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GAT's and broken LLVM #68642

Closed
Tracked by #44265
DutchGhost opened this issue Jan 29, 2020 · 0 comments · Fixed by #72788
Closed
Tracked by #44265

GAT's and broken LLVM #68642

DutchGhost opened this issue Jan 29, 2020 · 0 comments · Fixed by #72788
Labels
A-codegen Area: Code generation C-bug Category: This is a bug. F-generic_associated_types `#![feature(generic_associated_types)]` a.k.a. GATs T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@DutchGhost
Copy link
Contributor

I know GAT's are far from complete, but I've played around with them for a bit, and found some fun ICE's and LLVM errors.

The following code produces wrong LLVM output:

#![feature(generic_associated_types)]

trait Fun {
    type F<'a>: Fn() -> u32;
    
    fn callme<'a>(f: Self::F<'a>) -> u32 {
        f()
    }
}

impl <T> Fun for T {
    type F<'a> = Self;
}

fn main() {
    <fn() -> usize>::callme(|| {1});
}

It produces

Function return type does not match operand type of return inst!
  ret i64 %4, !dbg !155
 i32in function _ZN10playground3Fun6callme17h68e94299655f2c3eE
LLVM ERROR: Broken function found, compilation aborted!
error: could not compile `playground`.

To learn more, run the command again with --verbose.
@jonas-schievink jonas-schievink added A-codegen Area: Code generation C-bug Category: This is a bug. F-generic_associated_types `#![feature(generic_associated_types)]` a.k.a. GATs T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jan 29, 2020
Manishearth added a commit to Manishearth/rust that referenced this issue Jun 16, 2020
…dation, r=nikomatsakis

Projection bound validation

During selection we use bounds declared on associated types (e.g. `type X: Copy`) to satisfy trait/projection bounds. This would be fine so long as those bounds are checked on any impls/trait objects. For simple cases they are because the bound `Self::X: Copy` gets normalized when we check the impl.

However, for default values with specialization and higher-ranked bounds from GATs or otherwise, we can't normalize when checking the impl, and so we use the bound from the trait to prove that the bound applies to the impl, which is clearly unsound.

This PR makes 2 fixes for this:

1. Requiring that the bounds on the trait apply to a projection type with the corresponding substs, so a bound `for<'a> <Self as X<'a>>::U: Copy` on the trait cannot be used to prove `<T as X<'_>>::U: Copy`.
2. Actually checking that the bounds that we still allow apply to generic/default associated types.

Opening for a crater run.

Closes rust-lang#68641
Closes rust-lang#68642
Closes rust-lang#68643
Closes rust-lang#68644
Closes rust-lang#68645
Closes rust-lang#68656

r? @ghost
Manishearth added a commit to Manishearth/rust that referenced this issue Jun 20, 2020
…dation, r=nikomatsakis

Projection bound validation

During selection we use bounds declared on associated types (e.g. `type X: Copy`) to satisfy trait/projection bounds. This would be fine so long as those bounds are checked on any impls/trait objects. For simple cases they are because the bound `Self::X: Copy` gets normalized when we check the impl.

However, for default values with specialization and higher-ranked bounds from GATs or otherwise, we can't normalize when checking the impl, and so we use the bound from the trait to prove that the bound applies to the impl, which is clearly unsound.

This PR makes 2 fixes for this:

1. Requiring that the bounds on the trait apply to a projection type with the corresponding substs, so a bound `for<'a> <Self as X<'a>>::U: Copy` on the trait cannot be used to prove `<T as X<'_>>::U: Copy`.
2. Actually checking that the bounds that we still allow apply to generic/default associated types.

Opening for a crater run.

Closes rust-lang#68641
Closes rust-lang#68642
Closes rust-lang#68643
Closes rust-lang#68644
Closes rust-lang#68645
Closes rust-lang#68656

r? @ghost
@bors bors closed this as completed in 1a171d0 Jun 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-codegen Area: Code generation C-bug Category: This is a bug. F-generic_associated_types `#![feature(generic_associated_types)]` a.k.a. GATs T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants