UX bug report: Expected foo but found foo.

[pnathan]

Hi,

The following compiler error is not particularly clear or helpful (formatted to show the non-clarity).

error: mismatched types: expected 
`core::option::Option<&'r Job>` but found
`core::option::Option<&'r Job>` (lifetime mismatch)

While I understand there's a mismatch here, it's not really helpful in grasping what has to happen in my code to correct the error. In particular, if I passed type "X" but got "X", I'm not led towards a clear solution.

I've included below a fuller scroll, which is an error I have gotten a lot but don't really grok how to avoid yet.

Basically, I'm confused by the errors here and don't find them clarifying, only that I'm doing something vaguely wrong with lifetimes.

newton.rs:211:5: 213:6 note: consider using an explicit lifetime parameter as shown: fn take_job<'r>(&'r mut self, job: &'r Job)
newton.rs:211     fn take_job<'r>(&'r mut self, job: &'r Job) -> () {
newton.rs:212         self.job = Some(job);
newton.rs:213     }
newton.rs:212:20: 212:29 error: cannot infer an appropriate lifetime due to conflicting requirements
newton.rs:212         self.job = Some(job);
                                 ^~~~~~~~~
newton.rs:212:20: 212:29 error: mismatched types: expected `core::option::Option<&'r Job>` but found `core::option::Option<&Job>` (lifetime mismatch)
newton.rs:212         self.job = Some(job);
                                 ^~~~~~~~~

[soltanmm]

I recently encountered this problem while trying to work around the lack of object safety for the Iterator trait (and obviously making several mistakes in the process :-/ ). Here's a concrete toy example:

Code:

pub trait IntIterator {
    fn next<'a>(&'a mut self) -> Option<&'a int>;
}
impl<'a, T> IntIterator for T where T: Iterator<&'a int> {
    fn next<'a>(&'a mut self) -> Option<&'a int> {
        Iterator::next(self)
    }
}
fn main() {}

Error:

a.rs:5:5: 7:6 help: consider using an explicit lifetime parameter as shown: fn next<'a>(&'a mut self) -> Option<&'a int>
a.rs:5     fn next<'a>(&'a mut self) -> Option<&'a int> {
a.rs:6         Iterator::next(self)
a.rs:7     }
a.rs:6:9: 6:29 error: mismatched types: expected `core::option::Option<&'a int>`, found `core::option::Option<&'a int>` (lifetime mismatch)
a.rs:6         Iterator::next(self)
               ^~~~~~~~~~~~~~~~~~~~
a.rs:6:9: 6:29 error: mismatched types: expected `core::option::Option<&'a int>`, found `core::option::Option<&'a int>` (lifetime mismatch)
a.rs:6         Iterator::next(self)
               ^~~~~~~~~~~~~~~~~~~~
error: aborting due to 2 previous errors

Basically, afaict, 'a is used a few times and there's no diagnostic saying, "lol, dude, ya totally duped yo' names."

[huonw]

@soltanmm's example is definitely the duplication of 'a. I guess @pnathan's is too, but I cannot be 100% sure without seeing the full function/impl signature.

[chc4]

I've been bitten by this bug a couple of times lately, and had to flounder around trying things until it went away since it gives no hints.
I'm not sure if this is the correct issue to report this, since my case is unrelated to shadowing lifetimes, however.

src/xserver.rs:193:27: 193:64 error: mismatched types:
 expected `libc::types::common::c95::c_void`,
    found `libc::types::common::c95::c_void`
(expected enum `libc::types::common::c95::c_void`,
    found a different enum `libc::types::common::c95::c_void`) [E0308]
src/xserver.rs:193                     data: transmute::<[c_long; 5],c_void>(data),

In my code, I was setting XClientMessageEvent.data from rust-xlib with a transmute to c_void since that is what the unnamed_union2 type is defined as, along with what the compiler said it wanted the type as. The proper error would be if the compiler told me "expected unnamed_union2" opposed to c_void.

I also got the same error for function arguments:

src/xserver.rs:196:74: 196:100 error: mismatched types:
 expected `*mut libc::types::common::c95::c_void`,
    found `*mut libc::types::common::c95::c_void`
(expected enum `libc::types::common::c95::c_void`,
    found a different enum `libc::types::common::c95::c_void`) [E0308]
src/xserver.rs:196                 XSendEvent(self.display, wind, 0 /*false*/, NoEventMask, (mess_ptr as *mut c_void));

In this case, I'm calling XSendEvent and it's saying the *mut c_void I'm passing it for arg4 isn't the correct type. The XEvent struct is another C union defined as c_void. In this case, it was difficult to fix the error since calling the function with *mut XClientWindowEvent would tell me I need a *mut c_void, while in reality it needs a *mut XEvent.

I assume this is some kind of problem with Rust telling me the backed type for the exported type, instead of the proper name, and possibly because of how Rust doesn't support C-style unions and so have to be implemented as improper-sized c_void types...

[mcast]

@soltanmm wrote:

Basically, afaict, 'a is used a few times and there's no diagnostic saying, "lol, dude, ya totally duped yo' names."

@huonw wrote:

@soltanmm's example is definitely the duplication of 'a.

I see two issues here (and know that they would bite me if I got near them),

• Should there be a warning for shadowed lifetime symbols?
• Should there be a warning for lifetime symbols used in trait impls, which are different to the symbol used in the trait declaration?

[mitaa]

Should there be a warning for shadowed lifetime symbols?

@soltanmm's example currently errors with:

<anon>:13:13: 13:15 error: lifetime name `'a` shadows a lifetime name that is already in scope
<anon>:13     fn next<'a>(&'a mut self) -> Option<&'a isize> {
                      ^~
<anon>:12:6: 12:8 note: shadowed lifetime `'a` declared here
<anon>:12 impl<'a, T> IntIterator for T where T: Iterator<&'a isize> {
               ^~
error: aborting due to previous error
playpen: application terminated with error code 101

AFAICT this has been introduced in #24162

[mcast]

Ah yes, OP was a year ago! Sorry I didn't re-test before bumping.

Looks resolved to me, but I don't understand the implications for rust-lang/cargo#1636

[birkenfeld]

The better errors for same type names from different crate versions are tracked elsewhere; this issue should be closed as fixed.

[arielb1]

shadowing lifetimes is now illegal.