Skip to content

Lints on AST, remove ExprParen #28349

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

Merged
merged 6 commits into from
Sep 17, 2015
Merged

Lints on AST, remove ExprParen #28349

merged 6 commits into from
Sep 17, 2015

Conversation

nrc
Copy link
Member

@nrc nrc commented Sep 11, 2015

@Manishearth
Copy link
Member

I'd personally prefer if there were different kinds of lints entirely (not one kind of lint with different available contexts -- this means the lint will be run multiple times). So, basically, the LintStore would contain both EarlyLintPasses and LateLintPasses. It also keeps the lint traits easier to understand. If we want to have "MIR lints" in the future, the design is easily extended.

But I'm not insistent on this, the current model is fine too.

Aside from that and the check_mac thing, LGTM

fn check_explicit_self(&mut self, _: &LateContext, _: &hir::ExplicitSelf) { }
// Note that you shouldn't implement both check_mac and check_ast_mac,
// because then your lint will be called twice. Prefer check_ast_mac.
fn check_mac(&mut self, _: &LateContext, _: &ast::Mac) { }
Copy link
Member

Choose a reason for hiding this comment

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

Why would we have a macro in the HIR tree? Isn't HIR post-expansion?

(Actually, so is the AST at the time of early lint checking, do we need a check_mac of any form here?)

Copy link
Contributor

Choose a reason for hiding this comment

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

@Manishearth

Why would we have a macro in the HIR tree? Isn't HIR post-expansion?

I believe these are exported macro definitions, not macro uses.

Copy link
Member

Choose a reason for hiding this comment

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

@nrc
Copy link
Member Author

nrc commented Sep 11, 2015

My first idea for this was having two kinds of lints (early and late), but I decided against basically for backwards compatibility and simplicity. With the changes as they stand, lint authors only need to import a trait. I thought having to use different pass names, etc. would be too much of a breaking change. However, I guess if we are going to break lints even a little, then breaking them a lot is not much worse. I also thought it was easier having one big lint, rather than lots of little ones, but I'm not really sure about that.

If the backcompat issue is not too big a deal, then I can redo this with different lint passes pretty easily.

@Manishearth
Copy link
Member

I don't think it would be a major backcompat issue; given that it's just one trait that can be sed'ed (most lints work at the HIR stage). Only AST lints will have some backcompat issues (which is a tiny bit more sed)

@petrochenkov
Copy link
Contributor

I'm waiting for this to land and then will try to finish #6993 by replacing Idents with Names in HIR and below.

@nikomatsakis
Copy link
Contributor

I defer to @Manishearth (aka Mr Lint) when it comes to the backwards compat pain. Basically seems like we ought to redo this PR as described?

@Manishearth
Copy link
Member

I'm okay with the status quo, but I'd prefer the multitrait approach, yeah. I don't think it would be a major backcompat issue. Most lints out there are conceptually HIR lints, and we'd just need to replace some trait imports.

The original HIR changes (which had a lot of fiddly, non-sed-able import changes) were larger backcompat issues than this could be.

@nrc
Copy link
Member Author

nrc commented Sep 15, 2015

Now with multiple traits

@bors
Copy link
Collaborator

bors commented Sep 15, 2015

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

@Manishearth
Copy link
Member

LGTM

@bors
Copy link
Collaborator

bors commented Sep 16, 2015

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

@nrc
Copy link
Member Author

nrc commented Sep 16, 2015

@bors: r=manishearth

@bors
Copy link
Collaborator

bors commented Sep 16, 2015

📌 Commit 664b874 has been approved by manishearth

@bors
Copy link
Collaborator

bors commented Sep 16, 2015

⌛ Testing commit 664b874 with merge 71bdae1...

@bors
Copy link
Collaborator

bors commented Sep 16, 2015

💔 Test failed - auto-mac-32-opt

@Manishearth
Copy link
Member

../src/librustc/middle/expr_use_visitor.rs:283:22: 287:10 error: cannot infer an appropriate lifetime for lifetime parameter `'tcx` due to conflicting requirements
../src/librustc/middle/expr_use_visitor.rs:283         let result = ExprUseVisitor {
../src/librustc/middle/expr_use_visitor.rs:284             typer: typer,
../src/librustc/middle/expr_use_visitor.rs:285             mc: mc::MemCategorizationContext::new(typer),
../src/librustc/middle/expr_use_visitor.rs:286             delegate: delegate,
../src/librustc/middle/expr_use_visitor.rs:287         };
../src/librustc/middle/expr_use_visitor.rs:279:5: 290:6 help: consider using an explicit lifetime parameter as shown: fn new(delegate: &'d mut Delegate<'tcx>, typer: &'t infer::InferCtxt<'a, 't>)
 -> ExprUseVisitor<'d, 't, 'a, 't>
../src/librustc/middle/expr_use_visitor.rs:279     pub fn new(delegate: &'d mut Delegate<'tcx>,
../src/librustc/middle/expr_use_visitor.rs:280                typer: &'t infer::InferCtxt<'a, 'tcx>)
../src/librustc/middle/expr_use_visitor.rs:281                -> ExprUseVisitor<'d,'t,'a,'tcx>
../src/librustc/middle/expr_use_visitor.rs:282     {
../src/librustc/middle/expr_use_visitor.rs:283         let result = ExprUseVisitor {
../src/librustc/middle/expr_use_visitor.rs:284             typer: typer,
                                               ...
error: aborting due to previous error

@bors
Copy link
Collaborator

bors commented Sep 16, 2015

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

nrc added 6 commits September 17, 2015 12:16
There is a minor [breaking-change] for lint authors - some functions which were previously defined on `lint::Context` have moved to a trait - `LintContext`, you may need to import that trait to avoid name resolution errors.
[breaking-change] for lint authors

You must now implement LateLintPass or EarlyLintPass as well as LintPass and use either register_late_lint_pass or register_early_lint_pass, rather than register_lint_pass.
@nrc
Copy link
Member Author

nrc commented Sep 17, 2015

@bors: r=manishearth

@bors
Copy link
Collaborator

bors commented Sep 17, 2015

📌 Commit ed61a64 has been approved by manishearth

@bors
Copy link
Collaborator

bors commented Sep 17, 2015

⌛ Testing commit ed61a64 with merge d16129b...

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 this pull request may close these issues.

5 participants