Re-implement lint with less emphasis on item ids #6093
Conversation
| t | ||
| }); | ||
|
|
||
| if (n_uniq > 0 && lint != managed_heap_memory) { |
There was a problem hiding this comment.
nit: extraneous parentheses.
|
Updated with less parentheses and allocations |
|
Hmm... I also just found that some imports are getting warned about when they probably shouldn't be, so I'll update once I've investigated that. |
|
Should be good to go now, there was an import in |
|
@pcwalton r? |
|
I'm a little nervous about this. The existing system had to be revised several times before it was considered "correct". I .. actually don't remember what algorithm was settled on, and I feel like maybe we don't have enough testing in place to know if this perturbs the logic. |
|
Sorry, I guess that was a bit useless as feedback. Here are my concerns:
I'm of course glad to see attention on the lint system! Maybe I am just being my usual paranoid self and these concerns are not so serious? Happy to entertain some discussion on the matter. I just see this sitting here and I'm not r+'ing it due to a little hesitation. |
|
I agree lint is kind of not working out, but I'm not sure this is the solution. I had the thought of doing an inverse style:
|
|
Thanks for the comments! I wanted to do what @nikomatsakis was thinking, but I couldn't figure out a reliable way of always checking every Is there a way to iterate over every node id in the ast, or would I need to add something like |
|
|
|
Just updated to no longer use spans, but rather use |
|
I just updated with a fix to the tests, but I also realized that there's an unfortunate side effect of this in that linting runs 3x slower (at least on the core crate). There's a super-easy fix which is to not create a new visitor every time you run a new lint check, but when I implemented that it was complaining about leaked memory on exit... |
|
Hmm. That is too bad, I suspect that may be a side-effect of how visit_id is written, which I think is pretty inefficienct. How much time are we talking about? It might be worth landing and then trying to fixup visit_id to run more efficiently. |
|
libcore took ~0.16s in linting before this change, and it takes about 0.46s after the change. With my change that leaks memory (but only allocates all the visitors once), it takes ~0.06s |
|
I see. It seems to me that this timing regression is small in the |
|
That sounds ok to me. Getting the structure of lint right is pretty important. I'm curious about the change that leaks memory! Please do file a followup with as much detail as possible. Obviously that shouldn't be happening 😦 |
|
(also, seems this now needs a rebase) |
|
Just rebased, and the errors may have been fixed by the huge borrowck fix that just landed. Once this goes through I'll look into optimizing it and doing a more thorough inspection. |
|
Apparently my suspicions were correct, or I didn't know what I was doing before. Regardless I just added a commit with the optimizations I had in mind, and it does indeed run a large amount faster now (just the lint pass, obviously). |
|
r? @graydon |
|
This needs rebase again. :( |
This way it's much easier to add lints throughout compilation correctly, and functions on impls can alter the way lints are emitted.
Achieves ~3x speedup on lint passes for libcore
Closes #2647 This way it's much easier to add lints throughout compilation correctly, and functions on impls can alter the way lints are emitted. This involved pretty much rewriting how lints are emitted. Beforehand, only items could alter the lint settings, so whenever a lint was added it had to be associated with whatever item id it was coming from. I removed this (possibly questionably) in favor of just specifying a span and a message when adding a lint. When lint checking comes around, it looks at all the lints and sees which node with attributes best encloses it and uses that level of linting. This means that all consumer code doesn't have to deal with what item things came from (especially because functions on impls aren't items). More details of this can be found in the code (and comments). As a bonus, I managed to greatly simplify emission of lints in resolve.rs about unused imports. Now instead of it manually tracking what the lint level is, it's all moved over into the lint module (as is to be expected).
…hearth needless arbitrary self: handle macros This fixes two cases related to macros: * If the parameter comes from expansion, do not lint as the user has no possibility of changing it. This is not directly related to the fixed issue, but we should probably do that. * If *only* the lifetime name comes from expansion, lint, but allow the user decide the name of the lifetime. In the related issue, the lifetime was unnamed and then renamed by `async_trait`, so just removing the name in the suggestion would work, but in the general case a macro can rename a lifetime that was named differently, and we can't reliably know that name anymore. As a hint for the reviewer, the expanded code for the test can be checked with this command (from the root dir of the repo): ```sh rustc -L target/debug/test_build_base/needless_arbitrary_self_type_unfixable.stage-id.aux -Zunpretty=expanded tests/ui/needless_arbitrary_self_type_unfixable.rs ``` changelog: [`needless_arbitrary_self_type`]: handle macros Fixes rust-lang#6089
Closes #2647
This way it's much easier to add lints throughout compilation correctly, and
functions on impls can alter the way lints are emitted. This involved pretty much rewriting how lints are emitted. Beforehand, only items could alter the lint settings, so whenever a lint was added it had to be associated with whatever item id it was coming from. I removed this (possibly questionably) in favor of just specifying a span and a message when adding a lint. When lint checking comes around, it looks at all the lints and sees which node with attributes best encloses it and uses that level of linting. This means that all consumer code doesn't have to deal with what item things came from (especially because functions on impls aren't items). More details of this can be found in the code (and comments).
As a bonus, I managed to greatly simplify emission of lints in resolve.rs about unused imports. Now instead of it manually tracking what the lint level is, it's all moved over into the lint module (as is to be expected).