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

Squash all lints tied to foreign macros by default #52467

Merged
merged 2 commits into from
Jul 20, 2018

Conversation

alexcrichton
Copy link
Member

@alexcrichton alexcrichton commented Jul 17, 2018

This PR is a continuation of #49755 (thanks for the initial jump-start @Dylan-DPC!) and is targeted at solving #48855. This change updates the lint infrastructure to, by default, ignore all lints emitted for code that originates in a foreign macro. For example if println!("...") injects some idiomatic warnings these are all ignored by default. The rationale here is that for almost all lints there's no action that can be taken if the code originates from a foreign lint.

Closes #48855
Closes #52483
Closes #52479

@rust-highfive
Copy link
Collaborator

r? @estebank

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 17, 2018
@alexcrichton
Copy link
Member Author

r? @Manishearth

Copy link
Member

@Manishearth Manishearth left a comment

Choose a reason for hiding this comment

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

Looks good so far, but it should always output warnings for future incompatibility lints. Folks should know if their code will break, even if it's not something they can fix in their own crate.

@alexcrichton
Copy link
Member Author

@Manishearth indeed! That's why this is in the else clause where the previous has to do with future incompatibility (this is also mentioned in the comment added)

@oli-obk
Copy link
Contributor

oli-obk commented Jul 17, 2018

Ideally we'd still emit lints if the macro originates from a crate within the workspace. But that probably requires significant changes to tell us which crates belong to the same workspace

/// Returns whether `span` originates in a foreign crate's external macro.
///
/// This is used to test whether a lint should be entirely aborted above.
fn in_external_macro(sess: &Session, span: Span) -> bool {
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you make this public so we can reuse it from clippy?

Copy link
Member Author

Choose a reason for hiding this comment

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

Certainly!

Copy link
Member

@Manishearth Manishearth left a comment

Choose a reason for hiding this comment

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

lol missed that (was reviewing from phone)

r=me, with the function public

This commit polishes off this new function to compile on newer rustc as well as
update and add a suite of test cases to work with this new check for lints.
@alexcrichton
Copy link
Member Author

@oli-obk I agree! I also agree though that unfortunately there's no great way to know that in the compiler right now :(

@bors: r=Manishearth

@bors
Copy link
Contributor

bors commented Jul 17, 2018

📌 Commit 8adf08c has been approved by Manishearth

@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 17, 2018
@alexcrichton alexcrichton added this to the Rust 2018 Preview 2 milestone Jul 17, 2018
@alexcrichton alexcrichton added the A-edition-2018-lints Area: Lints supporting the 2018 edition label Jul 17, 2018
@bors
Copy link
Contributor

bors commented Jul 20, 2018

⌛ Testing commit 8adf08c with merge 4260c8b...

bors added a commit that referenced this pull request Jul 20, 2018
Squash all lints tied to foreign macros by default

This PR is a continuation of #49755 (thanks for the initial jump-start @Dylan-DPC!) and is targeted at solving #48855. This change updates the lint infrastructure to, by default, ignore all lints emitted for code that originates in a foreign macro. For example if `println!("...")` injects some idiomatic warnings these are all ignored by default. The rationale here is that for almost all lints there's no action that can be taken if the code originates from a foreign lint.

Closes #48855
Closes #52483
Closes #52479
@bors
Copy link
Contributor

bors commented Jul 20, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: Manishearth
Pushing 4260c8b to master...

@bors bors merged commit 8adf08c into rust-lang:master Jul 20, 2018
@Manishearth
Copy link
Member

This ends up breaking a bunch of clippy lints:

  • Sometimes we lint on an expression when not caring about the contents, it should be okay for that to be a macro -- e.g. if the expression is println!("foo"), the lint gets hidden, even though the lint is about the expression as a whole and not the macro origins
  • There should be an opt out, we have some lints that lint #[derive()]s
  • There's some funkyness around compiler desugarings, we're having for i in 1..3 where the lint is on the range getting squashed

overall ISTM it might be better to make this a per-lint thing like how clippy does. Either way, clippy is going to opt out I think.

@alexcrichton alexcrichton deleted the lints-and-macros branch July 20, 2018 20:53
@alexcrichton
Copy link
Member Author

@Manishearth should this check perhaps become a runtime check against a set stored in the session or lint context? That way Clippy would be able to register lints as "please issue a warning despite the foreign-macro-ness"

@oli-obk
Copy link
Contributor

oli-obk commented Jul 20, 2018

I have made it a runtime check and added the two rustc exceptions as a proof of concept: https://github.com/rust-lang/rust/pull/52562/files#diff-837439bcaa26732bb48bcbb0c60716ccL586

japaric added a commit to rust-embedded/cortex-m-rt that referenced this pull request Sep 5, 2018
they are no longer required due to rust-lang/rust#52467
adamgreig pushed a commit to rust-embedded/cortex-m that referenced this pull request Jan 12, 2022
they are no longer required due to rust-lang/rust#52467
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-edition-2018-lints Area: Lints supporting the 2018 edition 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.

7 participants