-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
lifetime variables in type bounds not properly enforced #12857
Comments
cc @pnkfelix |
I can't see how you're enforcing the lifetime of anything there. You just have things generic over a lifetime without a mention of the lifetime in the return type (in the trait definition, that is). You should also check IMO that trait should be HKT over a lifetime for this to work at all. |
@eddyb I see the same problem if I use a slice instead of a marker type:
|
I don't think this example should require higher kinded types. The trait in question is:
Here, |
Maybe @nikomatsakis can say if I'm mistaken on this point? |
This does look like a bug. |
Sorry it took me 5 days to read into it. What I expect to happen is that the region rules require that the lifetime of |
I'm looking at this problem now. In particular the second version that avoids using any native pointers. |
A new datapoint: the use of a trait method seems to be necessary to expose the problem here: pub trait FromSlice<'a> { fn new(s : &'a [u8]) -> Self; }
struct Hide<'a> { slice : &'a [u8] }
impl<'a> Hide<'a> { fn new(s: &'a [u8]) -> Hide<'a> { Hide { slice: s } } }
impl<'a> FromSlice<'a> for Hide<'a> {
fn new(s: &'a [u8]) -> Hide<'a> { Hide::new(s) }
}
#[cfg(hide_works)]
pub fn main () {
let bar : Hide = {
let foo = ~[1, 2, 3, 4, 5];
FromSlice::new(foo.as_slice())
}; // somehow sidesteps typecheck
let _x : ~[u8] = ~[9,9,9,9,9,9,9,9,9,9,9,9];
println!("bar.slice = {}, should reject (was [1, 2, 3, 4, 5])", bar.slice);
}
#[cfg(hide_fails)]
pub fn main () {
let bar : Hide = {
let foo = ~[1, 2, 3, 4, 5];
Hide::new(foo.as_slice())
}; // does not typecheck: `foo` does not live long enough
let _x : ~[u8] = ~[9,9,9,9,9,9,9,9,9,9,9,9];
println!("bar.slice = {}, should reject (was [1, 2, 3, 4, 5])", bar.slice);
}
|
Here is an updated test case.
|
In HEAD I get |
…, r=DorianListens fix: Autocomplete for struct fields includes receiver fixes rust-lang#12857
fix: let non_canonical_impls skip proc marco Fixed rust-lang#12788 Although the issue only mentions `NON_CANONICAL_CLONE_IMPL`, this fix will also affect `NON_CANONICAL_PARTIAL_ORD_IMPL` because I saw > Because of these unforeseeable or unstable behaviors, macro expansion should often not be regarded as a part of the stable API. on Clippy Documentation and these two lints are similar, so I think it might be good, not sure if it's right or not. --- changelog: `NON_CANONICAL_CLONE_IMPL`, `NON_CANONICAL_PARTIAL_ORD_IMPL` will skip proc marco now
Please see the
MessageReader::get_root
function below and the call to it inmain()
. It seems that'a
is not properly constrained.This is related to #5121 and #12807.
I expect this program not to typecheck, because it allows a
FooReader
to live longer than theStructReader
it was constructed from.However, we get:
The text was updated successfully, but these errors were encountered: