add structured suggestions and fix false-positive for elided-lifetimes-in-paths lint #52069

zackmdavis · 2018-07-05T04:34:41Z

This adds structured suggestions to the elided-lifetimes-in-paths lint (introduced in Nov. 2017's #46254), prevents it from emitting a false-positive on anonymous (underscore) lifetimes (!), and adds it to the idioms-2018 group (#52041).

As an aside, "elided-lifetimes-in-paths" seems like an unfortunate name, because it's not clear exactly what "elided" means. The motivation for this lint (see original issue #45992, and RFC 2115) seems to be specifically about not supplying angle-bracketed lifetime arguments to non-& types, but (1) the phrase "lifetime elision" has historically also referred to the ability to not supply a lifetime name to & references, and (2) an is_elided method in the HIR returns true for anoymous/underscore lifetimes, which is not what we're trying to lint here. (That naming confusion is almost certainly what led to the false positive addressed here.) Given that the lint is relatively new and is allow-by-default, is it too late to rename it ... um, again (#50879)?

~~This does not address a couple of other false positives discovered in #52041 (comment).~~

r? @nikomatsakis
cc @nrc @petrochenkov

zackmdavis · 2018-07-05T17:25:35Z

(Some would argue that we shouldn't give the lint the increased prominence of the idioms-2018 group (in contrast to allow-by-default, which I fear almost no one turns up) until we fix the false-positive exemplified by Ref::map (again, in #52041 (comment) ), but the counterargument would be that anyone who enables the idioms-2018 lints before October should know that they're opting into alpha/beta software and might help us discover more edge cases?)

nikomatsakis · 2018-07-06T10:11:20Z

@zackmdavis

I'm good with another name, do you have a suggestion? When it comes to the term "elided", there are two schools of thought in any case:

"Elided" carries the plain English meaning, and hence refers to any lifetime is not written (my personal opinion)
"Elided" refers speciically to a lifetime in a return type that is not written and is resolved to a lifetime from one of the parameters ("lifetime elision RFC")

Perhaps best to find another term altogether that is not as contentious. =)

It's sort of unclear what to call a '_ lifetime, which is not explicitly written but also not invisible... ah, perhaps that is a good name?

invisible_lifetimes_in_paths?
hidden_lifetime_in_paths?

nikomatsakis · 2018-07-06T10:13:02Z

This does not address a couple of other false positives

Which ones are not addressed? It'd be nice to update the issue to have a current list of known false positives.

nikomatsakis · 2018-07-06T10:15:16Z

src/librustc/lint/builtin.rs

@@ -252,7 +252,7 @@ declare_lint! {
 declare_lint! {
    pub ELIDED_LIFETIMES_IN_PATHS,
    Allow,
-    "hidden lifetime parameters are deprecated, try `Foo<'_>`"
+    "implicit lifetime parameters are deprecated"


As far as names go, my take:

implicit is ok, but it tends to mean anything that the reader wants it to mean

hidden and invisible I think are both ok

I don't think any name will necessarily convey perfectly what we are going for -- but all 3 names are roughly in the right direction. I would summarize as "a lifetime that you can't tell is there from looking at the type". For this, I like "hidden" or "invisible" better than "implicit".

nikomatsakis

Thank you very much for taking this up! Looks awesome. 💯 I have a few suggestions.

nikomatsakis · 2018-07-06T10:17:38Z

src/librustc/middle/resolve_lifetime.rs

+            &format!("implicit lifetime parameters in types are deprecated"),
+        );
+
+        if num_implicit_lifetimes == 1 {


Why only the case of 1 implicit lifetime?

It seems like the logic below would apply to any number of lifetimes, if we just generalized the string.

nikomatsakis · 2018-07-06T10:19:00Z

src/librustc/middle/resolve_lifetime.rs

+                    (segment_ident.span.shrink_to_hi(), "<'_>")
+                } else {
+                    // Otherwise—sorry, this is kind of gross—we need to infer the
+                    // replacement point span from the generics that do exist


I don't see a better way, but I get nervous around macros and things -- e.g., what will happen if somebody does:

Ref<$x>

in a macro? (I'm imagining that the span of $x might then come from some other place than the type itself...?) Maybe we want a test around that case? I think it'd be fine to disable suggestions there, but it'd be nice to ICE or suggest something mangled?

nikomatsakis · 2018-07-06T10:21:00Z

src/librustc/middle/resolve_lifetime.rs

+                    let mut first_generic_span = None;
+                    for ref arg in &generic_args.args {
+                        match arg {
+                            hir::GenericArg::Lifetime(lt) => {


I think there cannot be a lifetime name here... you can totally elide lifetimes (e.g., Foo<T>) but you cannot write only some of the needed lifetimes (e.g., Foo<'_, T> when Foo<'_, '_, T> is needed) -- you'll get an error in the latter case and (probably?) not go down this path. Should test though.

nikomatsakis · 2018-07-06T10:22:13Z

src/test/ui/in-band-lifetimes/elided-lifetimes.rs

+#![deny(elided_lifetimes_in_paths)]
+//~^ NOTE lint level defined here
+
+use std::cell::{RefCell, Ref};


Can we test:

some case with more than one parameter (just for fun, though I don't see why it wouldn't work)

a case where there is more than one lifetime and you only supply some?

the macro case where the type is constructed in a macro from bits and pieces?

bors · 2018-07-13T05:58:03Z

☔ The latest upstream changes (presumably #52275) made this pull request unmergeable. Please resolve the merge conflicts.

It's only with reluctance and sadness that we rename a lint that has already been renamed once (rust-lang#50879), but it seems worth it to pick the best name now because since the lint is relatively new and has heretofore been allow-by-default, the ecosystem breakage should be minimal. (And—also sadly—the fact that the original implementation was so buggy for so long testifies that not very many people are tuning up the allow-by-default lints. Also, as always, lint capping prevents lint changes from spreading contagiously to dependencies.) The rationales here are that— • "hidden" is less potentially ambiguous than "elided", because this lint is specifically about angle-bracketed lifetime parameters, whereas the term "elided" has a strong precedent for also encompassing omitted lifetime names in reference ('&') types, which is not the concern of this lint, and • "types" is a more specific description of where the lint fires than "paths" (indeed, previous implementations of the lint used to fire on non-type paths in ways that proved to be erroneous false-positives, as evidenced by applications of the suggestion to use an anonymous lifetime (`'_`) resulting in code that didn't even parse) This comes from discussion on rust-lang#52069.

zackmdavis · 2018-07-15T04:53:16Z

@nikomatsakis

(When you're back from vacation.)

Why only the case of 1 implicit lifetime? It seems like the logic below would apply to any number of lifetimes, if we just generalized the string.

I couldn't find a situation where inserting <'_, '_> would result in successfully fixing broken code. As an illustrative negative example, consider this program—

#![allow(unused)]
#![warn(elided_lifetimes_in_paths)]

struct DoubleLifetime<'a, 'b> {
    one: &'a str,
    another: &'b str,
}

fn returns_double_lifetime(one: &'a str, another: &'b str) -> DoubleLifetime {
    DoubleLifetime { one, another }
}

fn main() {}

The lint does fire on the return type of returns_double_lifetime, but we also hit E0106 ("missing lifetime specifiers")—

warning: implicit lifetime parameters in types are deprecated
  --> elide.rs:17:63
   |
17 | fn returns_double_lifetime(one: &'a str, another: &'b str) -> DoubleLifetime {
   |                                                               ^^^^^^^^^^^^^^
   |

[...]

error[E0106]: missing lifetime specifiers
  --> elide.rs:17:63
   |
17 | fn returns_double_lifetime(one: &'a str, another: &'b str) -> DoubleLifetime {
   |                                                               ^^^^^^^^^^^^^^ expected 2 lifetime parameters

Adding <'_, '_> doesn't solve the E0106—

error[E0106]: missing lifetime specifiers
  --> elide.rs:17:78
   |
17 | fn returns_double_lifetime(one: &'a str, another: &'b str) -> DoubleLifetime<'_, '_> {
   |                                                                              ^^ expected 2 lifetime parameters

I think this makes sense—if there are two distinct "output" lifetimes (in the terminology of RFC 141), they can't both be anonymous, because they need names to disambiguate which is which, right? And this is a different scenario from when we can legitimately use multiple anonymous input lifetimes <'_, '_> in an impl header as illustrated in the Edition Guide?

Which ones are not addressed? It'd be nice to update the issue to have a current list of known false positives.

I think I've fixed them now. What was happening is that the lint would fire on the type path in struct construction expressions—

error: implicit lifetime parameters in types are deprecated
  --> src/test/ui/in-band-lifetimes/elided-lifetimes.rs:44:5
   |
44 |     WrappedWithBow { gift }
   |     ^^^^^^^^^^^^^^- help: indicate the anonymous lifetime: `<'_>`

—and in associated-functions/static-methods (the motivating examples being Ref::clone and Ref::map)—

warning: implicit lifetime parameters in types are deprecated
  --> elide.rs:20:15
   |
20 |     let b2a = Ref::clone(b1);
   |               ^^^-^^^^^^
   |                  |
   |                  help: indicate the anonymous lifetime: `<'_>`

In both these cases, applying the suggestion results in code that fails to even parse ("expected :, found >").

To avoid this, I first moved the lint check from (a callee of) the visit_path method in the LifetimeContext visitor, to the hir::TyPath arm of visit_ty. That in itself fixes the struct-constructor case, but we were still emitting a false-positive in Ref::clone-like cases. (As far as the HIR is concerned, it seems that Ref::clone is the same as the UFCS expression <Ref>::clone, where the Ref counts as a type to be visited by visit_ty.) To fix that, I'm afraid I couldn't think of anything better than just not letting the visitor recurse into the callee of call expressions. I think that's legitimate, because I'm pretty sure you can't have a named lifetime in need of resolution there?—but this is in particular need of your expert reviewer scrutiny before we merge it. ( @oli-obk might also have insight, as the author of the other work we're doing in the TyPath arm.)

I think there cannot be a lifetime name here... you can totally elide lifetimes (e.g., Foo) but you cannot write only some of the needed lifetimes (e.g., Foo<', T> when Foo<', '_, T> is needed) -- you'll get an error in the latter case and (probably?) not go down this path. Should test though.

Thanks for clarifying this. However, unless I can convince myself that we error out before we get here, I think I'm inclined to naïvely obey the type system rather than asserting that the Lifetime arm never happens, on separation-of-concerns grounds: this method is just about linting for invisible lifetimes in otherwise (currently!) legal code; erroring out is someone else's responsibility (I added a comment.)

It's sort of unclear what to call a '_ lifetime, which is not explicitly written but also not invisible...

The edition guide calls it an "anonymous" lifetime, which seems appropriate (it's not omitted from the source, it just doesn't have a name). I've followed this terminology in the span label here ("indicate the anonymous lifetime").

I'm good with another name [...] invisible_lifetimes_in_paths? hidden_lifetime_in_paths?

After re-consulting RFC 141, I'm not enthusiastic about renaming the lint anymore.

(The reason I thought we wanted to rename is because I had mentally associated the word "elision" with & references specifically, which this lint isn't concerned with, but the RFC makes it clear that unwritten angle-bracked lifetimes are also "elided", and on reflection, I think "in paths" does a good enough job of being more specific.)

rust-highfive · 2018-07-15T05:21:23Z

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

[00:22:21]    Compiling proc_macro v0.0.0 (file:///checkout/src/libproc_macro)
[00:22:38]    Compiling syntax_ext v0.0.0 (file:///checkout/src/libsyntax_ext)
[00:28:39]    Compiling rustc_typeck v0.0.0 (file:///checkout/src/librustc_typeck)
[00:28:39]    Compiling rustc_mir v0.0.0 (file:///checkout/src/librustc_mir)
[00:28:43] error[E0597]: `my_registrar` does not live long enough
[00:28:43]    --> librustc_metadata/creader.rs:582:24
[00:28:43]     |
[00:28:43] 582 |         registrar(&mut my_registrar);
[00:28:43]     |                        ^^^^^^^^^^^^ borrowed value does not live long enough
[00:28:43] 588 |     }
[00:28:43] 588 |     }
[00:28:43]     |     - `my_registrar` dropped here while still borrowed
[00:28:43]     |
[00:28:43]     = note: values in a scope are dropped in the opposite order they are created
[00:28:43] error: variable does not need to be mutable
[00:28:43]    --> librustc_metadata/creader.rs:581:13
[00:28:43]     |
[00:28:43]     |
[00:28:43] 581 |         let mut my_registrar = MyRegistrar { extensions: Vec::new(), edition: root.edition };
[00:28:43]     |             ----^^^^^^^^^^^^
[00:28:43]     |             |
[00:28:43]     |             help: remove this `mut`
[00:28:43]     = note: `-D unused-mut` implied by `-D warnings`
[00:28:43] 
[00:28:43] error: aborting due to 2 previous errors
[00:28:43] 
[00:28:43] 
[00:28:43] For more information about this error, try `rustc --explain E0597`.
[00:28:43] error: Could not compile `rustc_metadata`.
[00:28:43] 
[00:28:43] Caused by:
[00:28:43]   process didn't exit successfully: `/checkout/obj/build/bootstrap/debug/rustc --crate-name rustc_metadata librustc_metadata/lib.rs --color always --error-format json --crate-type dylib --emit=dep-info,link -C prefer-dynamic -C opt-level=2 -C metadata=f2e516612ec0eb19 -C extra-filename=-f2e516612ec0eb19 --out-dir /checkout/obj/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnu/release/deps --target x86_64-unknown-linux-gnu -L dependency=/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnu/release/deps -L dependency=/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-rustc/release/deps --extern flate2=/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnu/release/deps/libflate2-1a6e055719da9e2b.rlib --extern log=/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnu/release/deps/liblog-3aae1b07eee5f41a.rlib --extern proc_macro=/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnu/release/deps/libproc_macro-02138f2ab64d4539.so --extern rustc=/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnu/release/deps/librustc-da4d2a69d03b2f0d.so --extern rustc_data_structures=/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnu/release/deps/librustc_data_structures-e5f576c4a2daecee.so --extern rustc_errors=/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnu/release/deps/librustc_errors-3575a7cf8f4898f3.so --extern rustc_target=/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnu/release/deps/librustc_target-2d5d56ac8c265ecc.so --extern serialize=/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnu/release/deps/libserialize-4ea3497d1552c967.so --extern serialize=/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnu/release/deps/libserialize-4ea3497d1552c967.rlib --extern syntax=/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnu/release/deps/libsyntax-fb9576173c28daa7.so --extern syntax_ext=/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnu/release/deps/libsyntax_ext-2d7bddb0d9db098b.so --extern syntax_pos=/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnu/release/deps/libsyntax_pos-9caed024aacf789e.so -L native=/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnu/release/build/miniz-sys-00f2106305a03b52/out -L native=/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnu/release/build/backtrace-sys-11ea4ad08c115426/out` (exit code: 101)
travis_time:end:19e9f270:start=1531630179288618005,finish=1531632080027436552,duration=1900738818547

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:0f8c0ac0

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

zackmdavis · 2018-07-15T05:23:25Z

(CI error is mysterious; this PR does not touch librustc_metadata)

(or, less mysteriously, perhaps some of the changes that I thought were only lint-related have actually broken borrowck 😰 )

oli-obk · 2018-07-15T09:57:54Z

You definitely broke something, the question is whether this code wasn't broken to begin with:

        let registrar = unsafe {
            let sym = match lib.symbol(&sym) {
                Ok(f) => f,
                Err(err) => self.sess.span_fatal(span, &err),
            };
            mem::transmute::<*mut u8, fn(&mut dyn Registry)>(sym)
        };

zackmdavis · 2018-07-15T15:57:46Z

Thanks, my code is almost certainly doing the wrong thing on mem::transmute::<*mut u8, fn(&mut dyn Registry)>(sym).

I'll need to rethink this (maybe we can store some extra state on the LifetimeContext visitor, rather than mucking with its traversal, which I really should have known better than to think I could get away with), but don't have time today.

nikomatsakis · 2018-07-16T12:33:05Z

@zackmdavis

I couldn't find a situation where inserting <', '> would result in successfully fixing broken code.

Perhaps this?

#![allow(unused)]
#![warn(elided_lifetimes_in_paths)]

struct DoubleLifetime<'a, 'b> {
    one: &'a str,
    another: &'b str,
}

fn accepts_double_lifetime(dl: DoubleLifetime) -> String {
    format!("{} {}", dl.one, dl.another)
}

fn main() {}

As far as the HIR is concerned, it seems that Ref::clone is the same as the UFCS expression <Ref>::clone, where the Ref counts as a type to be visited by visit_ty.

Hmm, yes, I can imagine that. I wonder if we are doing this lint in the wrong place. Maybe we should do it during HIR lowering...? After all, that is where we actually insert the various markers in HIR in the first place. I forget why I didn't suggest that route.

nikomatsakis · 2018-07-16T12:35:06Z

I think that's legitimate, because I'm pretty sure you can't have a named lifetime in need of resolution there?—but this is in particular need of your expert reviewer scrutiny before we merge it.

I would say it's not the worst thing ever, but it seems suboptimal. My goal is roughly to make lifetime parameters work the same as types -- that is, whenever you would have to write the type parameters for Foo, you also write the lifetime ones. So if you would do Vec<_> (and not just Vec) then you should do Foo<'_> (and not just Foo).

bors · 2018-07-16T16:25:35Z

☔ The latest upstream changes (presumably #52264) made this pull request unmergeable. Please resolve the merge conflicts.

zackmdavis · 2018-07-17T07:33:56Z

Maybe we should do it during HIR lowering...?

(This is looking like it's going to be much better, but for now my build is mysteriously ICEing and I need to sleep.)

zackmdavis · 2018-07-19T14:31:17Z

@nikomatsakis ready 🏁

nikomatsakis · 2018-07-19T18:51:43Z

@bors r+ -- looks nice

bors · 2018-07-19T18:51:44Z

📌 Commit 6fdcc60d6314d111acf4ea8e4e82cfd20f55f998 has been approved by nikomatsakis

zackmdavis · 2018-07-22T15:33:30Z

@kennytm @nikomatsakis I forgot that integer overflow panics (in non-release builds). Should be fixed now.

nikomatsakis · 2018-07-22T17:28:15Z

@bors r+

bors · 2018-07-22T17:28:16Z

📌 Commit 41d5c0c has been approved by nikomatsakis

bors · 2018-07-22T20:54:12Z

⌛ Testing commit 41d5c0c with merge ffaf3d2...

@nikomatsakis

…_re-pub-lic, r=nikomatsakis add structured suggestions and fix false-positive for elided-lifetimes-in-paths lint This adds structured suggestions to the elided-lifetimes-in-paths lint (introduced in Nov. 2017's #46254), prevents it from emitting a false-positive on anonymous (underscore) lifetimes (!), and adds it to the idioms-2018 group (#52041). ~~As an aside, "elided-lifetimes-in-paths" seems like an unfortunate name, because it's not clear exactly what "elided" means. The motivation for this lint (see original issue #45992, and [RFC 2115](https://github.com/rust-lang/rfcs/blob/e978a8d3017a01d632f916140c98802505cd1324/text/2115-argument-lifetimes.md#motivation)) seems to be specifically about not supplying angle-bracketed lifetime arguments to non-`&` types, but (1) the phrase "lifetime elision" has historically also referred to the ability to not supply a lifetime name to `&` references, and (2) an `is_elided` method in the HIR returns true for anoymous/underscore lifetimes, which is _not_ what we're trying to lint here. (That naming confusion is almost certainly what led to the false positive addressed here.) Given that the lint is relatively new and is allow-by-default, is it too late to rename it ... um, _again_ (#50879)?~~ ~~This does _not_ address a couple of other false positives discovered in #52041 (comment) ![elided_states](https://user-images.githubusercontent.com/1076988/42302137-2bf9479c-7fce-11e8-8bd0-f29aefc802b6.png) r? @nikomatsakis cc @nrc @petrochenkov

bors · 2018-07-22T23:05:06Z

☀️ Test successful - status-appveyor, status-travis
Approved by: nikomatsakis
Pushing ffaf3d2 to master...

rust-highfive · 2018-07-22T23:08:33Z

📣 Toolstate changed by #52069!

Tested on commit ffaf3d2.
Direct link to PR: #52069

💔 clippy-driver on windows: test-fail → build-fail (cc @Manishearth @llogiq @mcarton @oli-obk, @rust-lang/infra).
💔 clippy-driver on linux: test-fail → build-fail (cc @Manishearth @llogiq @mcarton @oli-obk, @rust-lang/infra).
💔 rls on windows: test-pass → build-fail (cc @nrc, @rust-lang/infra).
💔 rls on linux: test-pass → build-fail (cc @nrc, @rust-lang/infra).

@Manishearth

Tested on commit rust-lang/rust@ffaf3d2. Direct link to PR: <rust-lang/rust#52069> 💔 clippy-driver on windows: test-fail → build-fail (cc @Manishearth @llogiq @mcarton @oli-obk, @rust-lang/infra). 💔 clippy-driver on linux: test-fail → build-fail (cc @Manishearth @llogiq @mcarton @oli-obk, @rust-lang/infra). 💔 rls on windows: test-pass → build-fail (cc @nrc, @rust-lang/infra). 💔 rls on linux: test-pass → build-fail (cc @nrc, @rust-lang/infra).

zackmdavis · 2018-07-23T01:39:24Z

↑ I'm confused why this would break Clippy given that Clippy is not -Denying the rust_2018_idioms group?

oli-obk · 2018-07-23T06:17:48Z

I think we have #[deny(warnings)]

This seemed like a good way to kick the tires on the elided-lifetimes-in-paths lint (rust-lang#52069)—seems to work! This was also pretty tedious—it sure would be nice if `cargo fix` worked on this codebase (rust-lang#53896)!

rust-highfive assigned nikomatsakis Jul 5, 2018

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 5, 2018

zackmdavis changed the title ~~structured suggestions and fewer false-positives for elided-lifetimes-in-path lint~~ add structured suggestions and fix false-positive for elided-lifetimes-in-paths lint Jul 5, 2018

nikomatsakis reviewed Jul 6, 2018

View reviewed changes

nikomatsakis approved these changes Jul 6, 2018

View reviewed changes

nikomatsakis added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 6, 2018

zackmdavis force-pushed the elided_states_of_america—and_to_the_re-pub-lic branch from 6cc4481 to 681b321 Compare July 15, 2018 04:48

zackmdavis force-pushed the elided_states_of_america—and_to_the_re-pub-lic branch from 681b321 to 6fdcc60 Compare July 19, 2018 06:27

nikomatsakis added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 19, 2018

nikomatsakis approved these changes Jul 19, 2018

View reviewed changes

bors removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 19, 2018

kennytm added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 22, 2018

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 22, 2018

bors merged commit 41d5c0c into rust-lang:master Jul 22, 2018

zackmdavis deleted the elided_states_of_america—and_to_the_re-pub-lic branch July 23, 2018 01:35

zackmdavis mentioned this pull request Aug 11, 2018

elided_lifetimes_in_paths lint is broken #51902

Closed

alexcrichton mentioned this pull request Oct 8, 2018

cargo fix doesn't work with projects using rocket (it wants to fix plugin-generated code) rust-lang/cargo#6124

Closed

pnkfelix mentioned this pull request Oct 9, 2018

error: internal compiler error: Accessing (*_310) with the kind Write(Move) shouldn't be possible #54597

Closed

zackmdavis mentioned this pull request Oct 20, 2018

elided_lifetime_in_path triggers for the format! macro #48385

Closed

zackmdavis mentioned this pull request Oct 31, 2018

println!(), derive(Debug), derive(Clone), and probably many other macros break when using the elided_lifetimes_in_paths lint #51903

Closed

zackmdavis mentioned this pull request Oct 26, 2020

Can't allow elided_lifetimes_in_paths inside a module that denies rust_2018_idioms, other lints work #71957

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

add structured suggestions and fix false-positive for elided-lifetimes-in-paths lint #52069

add structured suggestions and fix false-positive for elided-lifetimes-in-paths lint #52069

zackmdavis commented Jul 5, 2018 •

edited

Loading

zackmdavis commented Jul 5, 2018

nikomatsakis commented Jul 6, 2018 •

edited

Loading

nikomatsakis commented Jul 6, 2018

nikomatsakis Jul 6, 2018

nikomatsakis left a comment

nikomatsakis Jul 6, 2018

nikomatsakis Jul 6, 2018

nikomatsakis Jul 6, 2018

nikomatsakis Jul 6, 2018

nikomatsakis Jul 6, 2018

bors commented Jul 13, 2018

zackmdavis commented Jul 15, 2018

rust-highfive commented Jul 15, 2018

zackmdavis commented Jul 15, 2018 •

edited

Loading

oli-obk commented Jul 15, 2018

zackmdavis commented Jul 15, 2018

nikomatsakis commented Jul 16, 2018

nikomatsakis commented Jul 16, 2018

bors commented Jul 16, 2018

zackmdavis commented Jul 17, 2018

zackmdavis commented Jul 19, 2018

nikomatsakis commented Jul 19, 2018

bors commented Jul 19, 2018

zackmdavis commented Jul 22, 2018

nikomatsakis commented Jul 22, 2018

bors commented Jul 22, 2018

bors commented Jul 22, 2018

bors commented Jul 22, 2018

rust-highfive commented Jul 22, 2018

zackmdavis commented Jul 23, 2018

oli-obk commented Jul 23, 2018

add structured suggestions and fix false-positive for elided-lifetimes-in-paths lint #52069

add structured suggestions and fix false-positive for elided-lifetimes-in-paths lint #52069

Conversation

zackmdavis commented Jul 5, 2018 • edited Loading

zackmdavis commented Jul 5, 2018

nikomatsakis commented Jul 6, 2018 • edited Loading

nikomatsakis commented Jul 6, 2018

nikomatsakis Jul 6, 2018

Choose a reason for hiding this comment

nikomatsakis left a comment

Choose a reason for hiding this comment

nikomatsakis Jul 6, 2018

Choose a reason for hiding this comment

nikomatsakis Jul 6, 2018

Choose a reason for hiding this comment

nikomatsakis Jul 6, 2018

Choose a reason for hiding this comment

nikomatsakis Jul 6, 2018

Choose a reason for hiding this comment

nikomatsakis Jul 6, 2018

Choose a reason for hiding this comment

bors commented Jul 13, 2018

zackmdavis commented Jul 15, 2018

rust-highfive commented Jul 15, 2018

zackmdavis commented Jul 15, 2018 • edited Loading

oli-obk commented Jul 15, 2018

zackmdavis commented Jul 15, 2018

nikomatsakis commented Jul 16, 2018

nikomatsakis commented Jul 16, 2018

bors commented Jul 16, 2018

zackmdavis commented Jul 17, 2018

zackmdavis commented Jul 19, 2018

nikomatsakis commented Jul 19, 2018

bors commented Jul 19, 2018

zackmdavis commented Jul 22, 2018

nikomatsakis commented Jul 22, 2018

bors commented Jul 22, 2018

bors commented Jul 22, 2018

bors commented Jul 22, 2018

rust-highfive commented Jul 22, 2018

zackmdavis commented Jul 23, 2018

oli-obk commented Jul 23, 2018

zackmdavis commented Jul 5, 2018 •

edited

Loading

nikomatsakis commented Jul 6, 2018 •

edited

Loading

zackmdavis commented Jul 15, 2018 •

edited

Loading