-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Move lint_store
#117649
Move lint_store
#117649
Conversation
This comment has been minimized.
This comment has been minimized.
Two weird clippy failures.
I bisected locally and found it's third commit that's causing these changes, but I don't know why. |
It's likely because spans are changing, clippy loads
Blessing them would be fine, we can fix the other one on the clippy side |
Thanks for the info, that's a huge help! I had suspected the The If I remove But I don't understand how my change affected clippy's use of |
Haven't finished it yet but a local clippy change I have to read the config file in Because |
This was made possible by the removal of plugin support, which simplified lint store creation. This simplifies the places in rustc and rustdoc that call `describe_lints`, which are early on. The lint store is now built before those places, so they don't have to create their own lint store for temporary use, they can just use the main one. Note: there are two clippy test changes. clippy loads the `clippy.toml` file into the source map during lint registration, and this now happens earlier than it used to, before the Rust source code is loaded. This exposes some latent bugs in clippy where it assumes invalid things about spans and source map offsets. These are in the process of being fixed elsewhere, as described in rust-lang#117649.
bfc1d3d
to
0034727
Compare
Some changes occurred in src/tools/clippy cc @rust-lang/clippy |
Thanks, @Alexendoo. I have updated the expected test outputs. This should now be ready to review. |
This PR would totally block and mean a total re-write of the current efforts for not processing allowed lints (both in Clippy and Rustc) as it removed practically everything that the current version of that patch uses. I advise against this cleanup, at least until that patch is open and merged. |
Do you have a link to that patch? |
@flip1995 pointed me at #106983, which has an attempted fix in #116271. I looked through the code for #116271 and I don't see any real overlap with the changes in this PR. So I think "totally block and mean a total re-write" is untrue. |
I wasn't talking about #116271, I was talking about a more modern form of this patch (which I lost and will have to rewrite from memory). And blocking that patch would block the Clippy efforts to ignore allowed lints (apart from Alexendoo's patch, which I don't know the progress of, or usage of this objects) Some things can indeed be cleaned up, but others like |
Your original comment said this:
Strong words! But there was no link to the patch and you didn't respond to my request for a link to it. So I contacted @flip1995 on Zulip and they pointed me at #116271.
Ok, that's helpful. I just looked at that patch and... again, it doesn't seem to conflict with this PR at all?
This PR removes I don't want to get in people's way and I'm happy to make adjustments if there are specific changes here that cause problems. But I don't see any such problems so far. I can't read minds so I don't know what was in past patches that have been lost, nor what will be in future patches yet to be written. I feel like we can all work together to get most or all of this PR merged. |
On an even closer inspection, the current patch indeed isn't blocked by this PR, let's hope that the next iteration isn't as well. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just one question. r=me if no issue.
0034727
to
31ce67e
Compare
I've addressed @cjgillot's comment. I will wait until the next clippy sync (Thursday) before merging this, to avoid the problem with |
This comment has been minimized.
This comment has been minimized.
☔ The latest upstream changes (presumably #117773) made this pull request unmergeable. Please resolve the merge conflicts. |
31ce67e
to
1be32dd
Compare
This comment has been minimized.
This comment has been minimized.
This was made possible by the removal of plugin support, which simplified lint store creation. This simplifies the places in rustc and rustdoc that call `describe_lints`, which are early on. The lint store is now built before those places, so they don't have to create their own lint store for temporary use, they can just use the main one.
Lint registration now happens early enough that we can run it from `Config`, before `Compiler` is created.
1be32dd
to
dededd2
Compare
The clippy sync has occurred, and I have updated. @bors r=cjgillot |
Rollup of 5 pull requests Successful merges: - rust-lang#117649 (Move `lint_store`) - rust-lang#117850 (bootstrap: simplify setting unstable-options for tools) - rust-lang#117889 (docs(release): Clarify cargo entries) - rust-lang#117946 (avoid exhaustive i16 test in Miri) - rust-lang#117963 (`rustc_query_system` cleanups) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#117649 - nnethercote:mv-lint_store, r=cjgillot Move `lint_store` Some nice cleanups enabled by the removal of compiler plugins. r? `@cjgillot`
Currently we have an inconsistency between the "input" and "no input" cases: - no input: `rustc --print=sysroot -Whelp` prints the lint help. - input: `rustc --print=sysroot -Whelp a.rs` prints the sysroot. It makes sense to print the lint help in both cases, because that's what happens with `--help`/`-Zhelp`/`-Chelp`. In fact, the `describe_lints` in the "input" case happens amazingly late, after *parsing*. This is because, with plugins, lints used to be registered much later, when the global context was created. But rust-lang#117649 moved lint registration much earlier, during session construction. So this commit moves the `describe_lints` call to a single spot for both for both the "input" and "no input" cases, as early as possible. This is still not as early as `--help`/`-Zhelp`/`-Chelp`, because `-Whelp` must wait until the session is constructed.
Currently we have an inconsistency between the "input" and "no input" cases: - no input: `rustc --print=sysroot -Whelp` prints the lint help. - input: `rustc --print=sysroot -Whelp a.rs` prints the sysroot. It makes sense to print the lint help in both cases, because that's what happens with `--help`/`-Zhelp`/`-Chelp`. In fact, the `describe_lints` in the "input" case happens amazingly late, after *parsing*. This is because, with plugins, lints used to be registered much later, when the global context was created. But rust-lang#117649 moved lint registration much earlier, during session construction. So this commit moves the `describe_lints` call to a single spot for both for both the "input" and "no input" cases, as early as possible. This is still not as early as `--help`/`-Zhelp`/`-Chelp`, because `-Whelp` must wait until the session is constructed.
…bjorn3 Unify "input" and "no input" paths in `run_compiler` A follow-up to rust-lang#117649. r? `@bjorn3`
Make `macro_use_imports` lint ordering more stable changelog: none Fixes [the `macro_use_imports` ordering dependence](rust-lang/rust#117649 (comment)) on the hash of `Span`s
Some nice cleanups enabled by the removal of compiler plugins.
r? @cjgillot