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

Struct and variant constructors are not generic over lifetimes like regular functions. #30904

Open
eddyb opened this issue Jan 14, 2016 · 5 comments · Fixed by #66331
Open

Struct and variant constructors are not generic over lifetimes like regular functions. #30904

eddyb opened this issue Jan 14, 2016 · 5 comments · Fixed by #66331
Labels
A-lifetimes Area: lifetime related C-enhancement Category: An issue proposing an enhancement or a PR with one. F-unboxed_closures `#![feature(unboxed_closures)]` T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@eddyb
Copy link
Member

eddyb commented Jan 14, 2016

The following testcase produces the errors noted in comments and the last one is an ICE (run on playpen):

#![feature(fn_traits, unboxed_closures)]

fn test<F: for<'x> FnOnce<(&'x str,)>>(_: F) {}

struct Compose<F,G>(F,G);
impl<T,F,G> FnOnce<(T,)> for Compose<F,G>
where F: FnOnce<(T,)>, G: FnOnce<(F::Output,)> {
    type Output = G::Output;
    extern "rust-call" fn call_once(self, (x,): (T,)) -> G::Output {
        (self.1)((self.0)(x))
    }
}

struct Str<'a>(&'a str);
fn mk_str<'a>(s: &'a str) -> Str<'a> { Str(s) }

fn main() {
    let _: for<'a> fn(&'a str) -> Str<'a> = mk_str;
    // expected concrete lifetime, found bound lifetime parameter 'a
    let _: for<'a> fn(&'a str) -> Str<'a> = Str;

    test(|_: &str| {});
    test(mk_str);
    // expected concrete lifetime, found bound lifetime parameter 'x
    test(Str);

    test(Compose(|_: &str| {}, |_| {}));
    test(Compose(mk_str, |_| {}));
    // internal compiler error: cannot relate bound region:
    //   ReLateBound(DebruijnIndex { depth: 2 },
    //     BrNamed(DefId { krate: 0, node: DefIndex(6) => test::'x }, 'x(65)))
    //<= ReSkolemized(0,
    //     BrNamed(DefId { krate: 0, node: DefIndex(6) => test::'x }, 'x(65)))
    test(Compose(Str, |_| {}));
}

The same errors occur if an enum Foo<'a> { Str(&'a str) } is used.

Usage of FnOnce<(T,)> is to avoid proving an explicit type parameter for the Output associated type, as an workaround for #30867.

Originally found in @asajeffrey's wasm repo (see my comment on asajeffrey/wasm#1).
cc @nikomatsakis @arielb1

@eddyb eddyb added A-lifetimes Area: lifetime related I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ and removed I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ labels Jan 14, 2016
@nikomatsakis
Copy link
Contributor

It's not as simple as making all regions late-bound; we'd have to use similar logic to what we use for fns I guess, where we distinguish the early-vs-late based on whether they are in use by where clauses. I imagine we don't do so because, when the struct or enum is used as a type, all the regions are always early bound.

@eddyb
Copy link
Member Author

eddyb commented Jan 14, 2016

@nikomatsakis I wouldn't expect anything less (than having the same logic for both constructors and free functions).

@eddyb
Copy link
Member Author

eddyb commented Jan 14, 2016

Submitted ICE separately as #30906.

@Mark-Simulacrum Mark-Simulacrum added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Jul 24, 2017
@steveklabnik
Copy link
Member

Triage: The ICE has been fixed, and the error message is now:

error[E0308]: mismatched types
  --> src/main.rs:20:45
   |
20 |     let _: for<'a> fn(&'a str) -> Str<'a> = Str;
   |                                             ^^^ expected concrete lifetime, found bound lifetime parameter 'a
   |
   = note: expected type `for<'a> fn(&'a str) -> Str<'a>`
              found type `fn(&str) -> Str<'_> {Str::<'_>}`

error[E0631]: type mismatch in function arguments
  --> src/main.rs:25:10
   |
3  | fn test<F: for<'x> FnOnce<(&'x str,)>>(_: F) {}
   | -------------------------------------------- required by `test`
...
14 | struct Str<'a>(&'a str);
   | ------------------------ found signature of `fn(&str) -> _`
...
25 |     test(Str);
   |          ^^^ expected signature of `for<'x> fn(&'x str) -> _`

error: aborting due to 2 previous errors

@Centril Centril added F-unboxed_closures `#![feature(unboxed_closures)]` E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. E-help-wanted Call for participation: Help is requested to fix this issue. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ labels Nov 5, 2019
JohnTitor added a commit to JohnTitor/rust that referenced this issue Nov 13, 2019
Add some tests for fixed ICEs

Closes rust-lang#30904 (fixed between nightly-2019-07-14 and nightly-2019-07-31)
Closes rust-lang#40231 (example 1 is fixed in 1.32.0, example 2 is fixed in 1.38.0)
Closes rust-lang#52432 (fixed in rustc 1.40.0-beta.1 (76b4053 2019-11-05))
Closes rust-lang#63279 (fixed in rustc 1.40.0-nightly (246be7e 2019-10-25))

r? @Centril
JohnTitor added a commit to JohnTitor/rust that referenced this issue Nov 13, 2019
Add some tests for fixed ICEs

Closes rust-lang#30904 (fixed between nightly-2019-07-14 and nightly-2019-07-31)
Closes rust-lang#40231 (example 1 is fixed in 1.32.0, example 2 is fixed in 1.38.0)
Closes rust-lang#52432 (fixed in rustc 1.40.0-beta.1 (76b4053 2019-11-05))
Closes rust-lang#63279 (fixed in rustc 1.40.0-nightly (246be7e 2019-10-25))

r? @Centril
@bors bors closed this as completed in 5683fe5 Nov 13, 2019
@eddyb
Copy link
Member Author

eddyb commented Nov 13, 2019

@steveklabnik Oops, I missed your comment - the ICE is #30906, not this issue.
This issue is about the example erroring (which is IMO a bug).

@eddyb eddyb reopened this Nov 13, 2019
@eddyb eddyb removed E-help-wanted Call for participation: Help is requested to fix this issue. E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ labels Nov 13, 2019
JohnTitor added a commit to JohnTitor/rust that referenced this issue Nov 15, 2019
Add more tests for fixed ICEs

Closes rust-lang#36122 (fixed in 1.20.0)
Closes rust-lang#58094 (fixed in rust-lang#66054)
Also, fix mistaken test case, from rust-lang#30904 to rust-lang#30906 (cc @eddyb)

r? @Centril
Centril added a commit to Centril/rust that referenced this issue Nov 15, 2019
Add more tests for fixed ICEs

Closes rust-lang#36122 (fixed in 1.20.0)
Closes rust-lang#58094 (fixed in rust-lang#66054)
Also, fix mistaken test case, from rust-lang#30904 to rust-lang#30906 (cc @eddyb)

r? @Centril
Centril added a commit to Centril/rust that referenced this issue Nov 15, 2019
Add more tests for fixed ICEs

Closes rust-lang#36122 (fixed in 1.20.0)
Closes rust-lang#58094 (fixed in rust-lang#66054)
Also, fix mistaken test case, from rust-lang#30904 to rust-lang#30906 (cc @eddyb)

r? @Centril
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lifetimes Area: lifetime related C-enhancement Category: An issue proposing an enhancement or a PR with one. F-unboxed_closures `#![feature(unboxed_closures)]` 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.

5 participants