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

lifetime constraints cross-interfere between method definitions #18163

Closed
dwrensha opened this issue Oct 19, 2014 · 1 comment
Closed

lifetime constraints cross-interfere between method definitions #18163

dwrensha opened this issue Oct 19, 2014 · 1 comment

Comments

@dwrensha
Copy link
Contributor

$ rustc --version
rustc 0.13.0-nightly (c46812f65 2014-10-19 00:47:18 +0000)

I expect this program to compile successfully:

// lifetimes.rs

pub struct ListBuilder<'a> {
    data : &'a [u8]
}

pub struct StructBuilder<'a> {
    data : &'a [u8]
}

impl <'a> ListBuilder <'a> {
    pub fn get_struct_element(&self, index : uint) -> StructBuilder<'a> {
        StructBuilder { data: self.data.slice(index, index + 4) }
    }
}

pub trait FromStructBuilder<'a> {
    fn new(structBuilder : StructBuilder<'a>) -> Self;
}

pub struct ConcreteListBuilder<'a, T> {
    pub builder : ListBuilder<'a>
}

impl <'a, T : FromStructBuilder<'a>> ConcreteListBuilder<'a, T> {
    pub fn get(&self, index : uint) -> T {
        FromStructBuilder::new(self.builder.get_struct_element(index))
    }
}

// Compilation succeeds if I comment out this impl.
impl <'a, T : FromStructBuilder<'a>> ConcreteListBuilder<'a, T> {
    pub fn get2(&self, index : uint) -> T {
        FromStructBuilder::new(self.builder.get_struct_element(index))
    }
}

pub fn main () {}

Instead, it gives me this error:

$ rustc lifetimes.rs 
lifetimes.rs:34:32: 34:44 error: cannot infer an appropriate lifetime for lifetime parameter `'a` due to conflicting requirements
lifetimes.rs:34         FromStructBuilder::new(self.builder.get_struct_element(index))
                                               ^~~~~~~~~~~~
lifetimes.rs:33:43: 35:6 note: first, the lifetime cannot outlive the lifetime 'a as defined on the block at 33:42...
lifetimes.rs:33     pub fn get2(&self, index : uint) -> T {
lifetimes.rs:34         FromStructBuilder::new(self.builder.get_struct_element(index))
lifetimes.rs:35     }
lifetimes.rs:34:32: 34:44 note: ...so that types are compatible (expected `&ListBuilder<'_>`, found `&ListBuilder<'a>`)
lifetimes.rs:34         FromStructBuilder::new(self.builder.get_struct_element(index))
                                               ^~~~~~~~~~~~
lifetimes.rs:26:42: 28:6 note: but, the lifetime must be valid for the lifetime 'a as defined on the block at 26:41...
lifetimes.rs:26     pub fn get(&self, index : uint) -> T {
lifetimes.rs:27         FromStructBuilder::new(self.builder.get_struct_element(index))
lifetimes.rs:28     }
lifetimes.rs:34:9: 34:31 note: ...so that trait type parameters matches those specified on the impl (expected `FromStructBuilder<'_>`, found `FromStructBuilder<'a>`)
lifetimes.rs:34         FromStructBuilder::new(self.builder.get_struct_element(index))
                        ^~~~~~~~~~~~~~~~~~~~~~
error: aborting due to previous error

The program successfully compiles if I comment out the definition of the get2() method.

This kind of thing used to work; e.g. the program compiles successfully at the commit 9b80efd.

cc @nikomatsakis

@dwrensha
Copy link
Contributor Author

Fixed via #18235.

lnicola pushed a commit to lnicola/rust that referenced this issue Sep 25, 2024
…Veykril

fix: Fix a bug in span map merge, and add explanations of how span maps are stored

Because it took me hours to figure out that contrary to common sense, the offset stored is the *end* of the node, and we search by the *start*. Which is why we need a convoluted `partition_point()` instead of a simple `binary_search()`. And this was not documented at all. Which made me make mistakes with my implementation of `SpanMap::merge()`.

The other bug fixed about span map merging is correctly keeping track of the current offset in presence of multiple sibling macro invocations. Unrelated, but because of the previous issue it took me hours to debug, so I figured out I'll put them together for posterity.

Fixes rust-lang#18163.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant