Rust: compiler error: lifetimes in associated types leading to a compiler error.

Created on 24 Feb 2019  路  15Comments  路  Source: rust-lang/rust

Hello!

I am getting a compiler error when trying to define the following trait:

trait Foo {
  type PublicKey<'a> : From<&'a [u8]>;

}

fn main() {
  println!("hello, world!")
}
````

I would have expected my code to compile successfully, or to exit with some error explaining why static compilation failed.

Instead, I am getting a: 

error: internal compiler error: src/librustc/ty/subst.rs:426: Region parameter out of range when substituting in region 'a (root type=Some(&'a [u8])) (index=1)




More specifically, I'm having troubles trying to define some type `PublicKey` that must implement `AsRef<[u8]>` and `From<&[u8]>`. If I try with lifetimes I get this compiler error; if I replace the from trait with `From<[u8; N]>` for some const N: usize (enabling `generic_associated_types` and `const_generics`) I get: 

error: const generics in any position are currently unsupported
--> foo.rs:4:24
|
4 | type PublicKey : From<[u8; N]>;
| ^

Am I doing something terribly stupid here or const generics for associated types are not yet ready _and_ lifetimes on associated types lead to a compiler error?

Here's the full traceback
```error[E0658]: generic associated types are unstable (see issue #44265)
 --> foo.rs:3:3
  |
3 |   type PublicKey<'a> : From<&'a[u8]>;
  |   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = help: add #![feature(generic_associated_types)] to the crate attributes to enable

error: internal compiler error: src/librustc/ty/subst.rs:426: Region parameter out of range when substituting in region 'a (root type=Some(&'a [u8])) (index=1)

thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:558:9
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
error: aborting due to 2 previous errors

For more information about this error, try `rustc --explain E0658`.

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.34.0-nightly (aadbc459b 2019-02-23) running on x86_64-unknown-linux-gnu
A-associated-items C-bug F-generic_associated_types I-ICE P-medium T-compiler

Most helpful comment

cc @rust-lang/compiler @rust-lang/release

It's technically a stable-to-beta regression, but it goes from hard error to ICE so I don't think it's worth blocking the release on this.

(Also woops, mistakenly closed the issue)

All 15 comments

type PublicKey<'a> defines a generic associated type, which aren't yet fully implemented.

type PublicKey<'a> defines a generic associated type, which aren't yet fully implemented.

That's correct, but even without enabled feature it crashes, which should not happen, or am I wrong? :/

cc @rust-lang/compiler @rust-lang/release

It's technically a stable-to-beta regression, but it goes from hard error to ICE so I don't think it's worth blocking the release on this.

(Also woops, mistakenly closed the issue)

As long as we're not breaking working code it's not really a breakage and so I agree we should not block a release on it.

Also +1 for not blocking the release on this.

This error does not only occur in code that is illegal, it (apparently) only occurs in code that has already triggered a visible, clear, feature-gate error. Therefore, it's not even a particularly-high risk for confusing users (unlike e.g. an ICE that occurs instead of a valid error message, or an ICE that occurs after an obscure error message).

triage: P-medium. Assigning to self for initial investigation.

(P-medium based on the reasons given by @arielb1 : the risks for end users here do seem quite low.)

triage: confirmed this was promoted into stable, as one would expect based on the conversation above. Marking as regression-from-stable-to-stable.

This seems like it was fixed. Going to bisect and see if a corresponding test was already added at time it was fixed.

Fixed between nightly-2019-05-25 (dec4c5201 2019-05-24) and nightly-2019-05-26 (f49269398 2019-05-25)

Here's what landed in that time frame:

% git log --format=oneline --author=bors dec4c5201..f49269398
f492693982d1e252f5411ae3e4d560ab0dfea48a Auto merge of #59276 - oli-obk:cleanups, r=eddyb
02f5786a324c40b2d8b2d0df98456e48fb45d30c Auto merge of #61151 - Centril:rollup-5rpyhfo, r=Centril

    #61092 (Make sanitize_place iterate instead of recurse)
    #61093 (Make borrow_of_local_data iterate instead of recurse)
    #61094 (Make find_local iterate instead of recurse)
    #61099 (Make ignore_borrow iterate instead of recurse)
    #61103 (Make find iterate instead of recurse)
    #61104 (Make eval_place_to_op iterate instead of recurse)


315ab95a9c13cbb69ae8538fcd69b9f7b0c30f89 Auto merge of #61150 - Centril:rollup-wmm7qga, r=Centril


    #61026 (Tweak macro parse errors when reaching EOF during macro call parse)
    #61095 (Update cargo)
    #61096 (tidy: don't short-circuit on license error)
    #61107 (Fix a couple docs typos)
    #61110 (Revert edition-guide toolstate override)
    #61111 (Fixed type-alias-bounds lint doc)
    #61113 (Deprecate FnBox. Box<dyn FnOnce()> can be called directly, since 1.35)
    #61116 (Remove the incorrect warning from README.md)
    #61118 (Dont ICE on an attempt to use GAT without feature gate)
    #61121 (improve debug-printing of scalars)
    #61125 (Updated my mailmap entry)
    #61134 (Annotate each reverse_bits with #[must_use])
    #61138 (Move async/await tests to their own folder)

524580312039e4fa5ccf91e8f7093cd755bc1aad Auto merge of #60441 - vext01:try-to-kill-projection-params, r=oli-obk

Oh, I fixed this back in PR #61118 (to fix #60654), which was part of rollup #61150, but I didn't notice that #60654 was a duplicate of #58694.

@pnkfelix it is not really fixed. It doesn't crash anymore with the above code, but it still ICEs with the feature gate: playground

well, if the ICE is not occurring any more when the feature attribute is omitted and we're back to a hard error, then its not a regression-from-stable-to-stable.

I'm going to open a fresh issue to track the problem with the feature gate enabled, because the comments in #58694 and #60654 make it hard to tell which bug (the ICE without feature-gate vs the ICE with feature-gate) is being discussed.

(the remaining bug, when the feature gate is enabled, is tracked in issue #62521)

closing as fixed as remaining bug is in #62521

Was this page helpful?
0 / 5 - 0 ratings

Related issues

modsec picture modsec  路  3Comments

behnam picture behnam  路  3Comments

nikomatsakis picture nikomatsakis  路  3Comments

SharplEr picture SharplEr  路  3Comments

drewcrawford picture drewcrawford  路  3Comments