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

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

Conversation

zackmdavis
Copy link
Member

@zackmdavis zackmdavis commented Jul 5, 2018

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).

elided_states

r? @nikomatsakis
cc @nrc @petrochenkov

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 5, 2018
@zackmdavis 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
@zackmdavis
Copy link
Member Author

(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
Copy link
Contributor

nikomatsakis commented Jul 6, 2018

@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
Copy link
Contributor

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.

@@ -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"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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".

Copy link
Contributor

@nikomatsakis nikomatsakis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

&format!("implicit lifetime parameters in types are deprecated"),
);

if num_implicit_lifetimes == 1 {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why only the case of 1 implicit lifetime?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

(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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

#![deny(elided_lifetimes_in_paths)]
//~^ NOTE lint level defined here

use std::cell::{RefCell, Ref};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

@nikomatsakis 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
@bors
Copy link
Contributor

bors commented Jul 13, 2018

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

zackmdavis added a commit to zackmdavis/rust that referenced this pull request Jul 15, 2018
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 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
Copy link
Member Author

@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
Copy link
Collaborator

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
Copy link
Member Author

zackmdavis commented Jul 15, 2018

(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
Copy link
Contributor

oli-obk commented Jul 15, 2018

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
Copy link
Member Author

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
Copy link
Contributor

@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
Copy link
Contributor

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
Copy link
Contributor

bors commented Jul 16, 2018

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

@zackmdavis
Copy link
Member Author

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 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
@zackmdavis
Copy link
Member Author

@nikomatsakis ready 🏁

@nikomatsakis 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
Copy link
Contributor

@bors r+ -- looks nice

@bors
Copy link
Contributor

bors commented Jul 19, 2018

📌 Commit 6fdcc60d6314d111acf4ea8e4e82cfd20f55f998 has been approved by nikomatsakis

@bors bors removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 19, 2018
@zackmdavis
Copy link
Member Author

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

@kennytm 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
@nikomatsakis
Copy link
Contributor

@bors r+

@bors
Copy link
Contributor

bors commented Jul 22, 2018

📌 Commit 41d5c0c has been approved by nikomatsakis

@bors 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
Copy link
Contributor

bors commented Jul 22, 2018

⌛ Testing commit 41d5c0c with merge ffaf3d2...

bors added a commit that referenced this pull request Jul 22, 2018
…_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
Copy link
Contributor

bors commented Jul 22, 2018

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

@bors bors merged commit 41d5c0c into rust-lang:master Jul 22, 2018
@rust-highfive
Copy link
Collaborator

📣 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).

rust-highfive added a commit to rust-lang-nursery/rust-toolstate that referenced this pull request Jul 22, 2018
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 zackmdavis deleted the elided_states_of_america—and_to_the_re-pub-lic branch July 23, 2018 01:35
@zackmdavis
Copy link
Member Author

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

@oli-obk
Copy link
Contributor

oli-obk commented Jul 23, 2018

I think we have #[deny(warnings)]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants