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 misformatted (leading &) in rustc note output #10291

Closed
pnkfelix opened this issue Nov 5, 2013 · 7 comments · Fixed by #14317
Closed

lifetime misformatted (leading &) in rustc note output #10291

pnkfelix opened this issue Nov 5, 2013 · 7 comments · Fixed by #14317
Labels
A-lifetimes Area: lifetime related E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.

Comments

@pnkfelix
Copy link
Member

pnkfelix commented Nov 5, 2013

Consider compile_fail/regions-nested-fns.rs:

fn ignore<T>(t: T) {}

fn nested<'x>(x: &'x int) {
    let y = 3;
    let mut ay = &y; //~ ERROR cannot infer an appropriate lifetime

    ignore::< <'z>|&'z int|>(|z| {
        ay = x;
        ay = &y;
        ay = z;
    });

    ignore::< <'z>|&'z int| -> &'z int>(|z| {
        if false { return x; }  //~ ERROR mismatched types
        //~^ ERROR cannot infer an appropriate lifetime
        if false { return ay; }
        return z;
    });
}

fn main() {}

When you run this, in addition to various error output, you will also see messages prefixed by note:. In those messages, when a lifetime is printed, it is printed with a leading & in addition to the ' that is part of its name. For example:

[...] the lifetime cannot outlive the lifetime &'z1 as defined [...].

In my opinion, this is confusing. 'z is a lifetime, while &'z are the first three characters of some (incomplete) type expression that is missing the pointed-to type (along with a potential mut qualifier).

I suspect the leading & is arising probably some artifact of how the code is implementing the fmt::Default trait; it might also involve the use of bound_region_ptr_to_str as the implementation of how lifetimes are printed (even though the former says it is for printing ptrs, not lifetimes).


Also, there is an extra space between &'z and as defined above.

@nikomatsakis
Copy link
Contributor

that's a holdover from the days before 'z existed as a notation for
lifetimes, definitely should be fixed

@jeffcutsinger
Copy link

If no one else is working on this, I'll take it.

@jeffcutsinger
Copy link

Apologies for how long this is taking, I'm still kind of learning the internals. I have a question, though.

I have fixed this issue, but I'm now getting output like:

note: first, the lifetime cannot outlive an anonymous lifetime defined on the block at 23:46...
...so that types are compatible (expected `int` but found `int`)

The second int is an int scoped to an anonymous lifetime, but the way I've implemented it there's no indication of this in the output. Is there a decided-upon notation for this case? Perhaps 'anonymous int?

@nikomatsakis
Copy link
Contributor

I think those types should be written &int.

@nikomatsakis
Copy link
Contributor

Or perhaps, better yet, &'0 int or something like that. It'd be nice to indicate to the user that there are in fact two distinct lifetimes there, otherwise the message looks silly ("expected &int but found &int" -- wat??)

@ftxqxd
Copy link
Contributor

ftxqxd commented May 20, 2014

Given that work on this issue seems to have stagnated somewhat, would it be OK if I could take this issue?

I was thinking that perhaps &'<anon> int would be better than &'0 int as it’s more descriptive, and matches with &'<empty>.

Also, should all references be annotated thus? It seems slightly unnecessary to state the lifetime in an error like expected &' intbut founduint or even `type `&'<anon> int` has no method `foobar. This would probably complicate the implementation rather a lot, however.

@jeffcutsinger
Copy link

On 5/19/2014 10:56 PM, P1start wrote:

Given that work on this issue seems to have stagnated somewhat, would
it be OK if I could take this issue?


Reply to this email directly or view it on GitHub
#10291 (comment).

Yes, I am not working on this (or rust at all) any more. My apologies
for not updating the issue.

ftxqxd added a commit to ftxqxd/rust that referenced this issue May 23, 2014
This changes certain error messages about lifetimes so that they display
lifetimes without an `&`.

Fixes rust-lang#10291.
bors added a commit that referenced this issue May 23, 2014
This changes certain error messages about lifetimes so that they display lifetimes without an `&`.

Fixes #10291.
flip1995 pushed a commit to flip1995/rust that referenced this issue Feb 10, 2023
…tion, r=dswij

Negate suggestions when needed in `bool_assert_comparison`

changelog: none assuming this gets into the same release as rust-lang#10218

Fixes rust-lang#10291

r? `@dswij`

Thanks to `@black-puppydog` for spotting it early
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lifetimes Area: lifetime related E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants