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

Confusing elided-lifetimes-in-paths lint in bridge #907

Closed
sbrocket opened this issue Aug 2, 2021 · 4 comments · Fixed by #981
Closed

Confusing elided-lifetimes-in-paths lint in bridge #907

sbrocket opened this issue Aug 2, 2021 · 4 comments · Fixed by #981

Comments

@sbrocket
Copy link
Contributor

sbrocket commented Aug 2, 2021

Building the demo with -W elided-lifetimes-in-paths results in the following:

warning: hidden lifetime parameters in types are deprecated
  --> demo/src/main.rs:22:63
   |
22 |         fn new_blobstore_client() -> UniquePtr<BlobstoreClient>;
   |                                                               ^- help: indicate the anonymous lifetime: `<'_>`
   |
   = note: requested on the command line with `-W elided-lifetimes-in-paths`

warning: 1 warning emitted

However, neither cxx::UniquePtr nor BlobstoreClient have a lifetime parameter, so of course trying to add one is an error (and of course the lint still triggers too):

warning: hidden lifetime parameters in types are deprecated
  --> demo/src/main.rs:22:66
   |
22 |         fn new_blobstore_client() -> UniquePtr<BlobstoreClient<'_>>;
   |                                                                  ^^- help: indicate the anonymous lifetime: `<'_>`
   |
   = note: requested on the command line with `-W elided-lifetimes-in-paths`

error[E0106]: missing lifetime specifier
  --> demo/src/main.rs:22:64
   |
22 |         fn new_blobstore_client() -> UniquePtr<BlobstoreClient<'_>>;
   |                                                                ^^ expected named lifetime parameter
   |
   = help: this function's return type contains a borrowed value, but there is no value for it to be borrowed from
help: consider using the `'static` lifetime
   |
22 |         fn new_blobstore_client() -> UniquePtr<BlobstoreClient<'static>>;
   |                                                                ^^^^^^^

error[E0107]: this struct takes 0 lifetime arguments but 1 lifetime argument was supplied
  --> demo/src/main.rs:22:48
   |
22 |         fn new_blobstore_client() -> UniquePtr<BlobstoreClient<'_>>;
   |                                                ^^^^^^^^^^^^^^^---- help: remove these generics
   |                                                |
   |                                                expected 0 lifetime arguments
   |
note: struct defined here, with 0 lifetime parameters
  --> demo/src/main.rs:20:14
   |
20 |         type BlobstoreClient;
   |              ^^^^^^^^^^^^^^^

error: aborting due to 2 previous errors; 1 warning emitted

Looking at the expanded output with cargo expand, I don't see any clues as to what missing anonymous lifetime the compiler might be intending to flag here. It's unclear to me if this is a lint bug, if the compiler diagnostic is just confusing due to the cxx::bridge proc macro, or something else.

This is an issue for us because our codebase uses both -W rust_2018_idioms and -D warnings by default. Worse, elided-lifetimes-in-paths can only be allowed at the crate level (rust-lang/rust#71957) so we can't just allow it for the cxx::bridge module.

@sbrocket
Copy link
Contributor Author

sbrocket commented Aug 2, 2021

Ahhhh, I see what it's trying to indicate now. It's complaining about the generated UniquePtrTarget for BlobstoreClient impl, which includes a std::fmt::Formatter type that is missing the anonymous lifetime. Ok, that should be easily fixable.

@saitoy1
Copy link

saitoy1 commented Dec 10, 2021

I'm running into the same issue and wondering if there is any workaround for this?

@sbrocket
How did you go about fixing it?

@dtolnay
Copy link
Owner

dtolnay commented Dec 10, 2021

I am not a fan of this lint and I don't think codebases should use it, but I've published support for it in 1.0.60.

@sbrocket
Copy link
Contributor Author

sbrocket commented Dec 10, 2021 via email

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

Successfully merging a pull request may close this issue.

3 participants