Separate most of rustc::lint::builtin into a separate crate.#22801
Merged
Conversation
Contributor
|
r? @eddyb (rust_highfive has picked a reviewer for you, use r? to override) |
Contributor
Author
|
r? @kmcallister |
Member
|
Nice improvement! Since we have a separate crate for lints now, would be nice to split librustc_lint/builtin.rs into several files, e.g. each for a lint. |
Contributor
Author
|
@nagisa yeah definitely, that's #22206. I don't have time to do it all immediately, but this patch makes it much easier to do incrementally since the compile times are much shorter. I thought it better to land this (to let everyone get the benefits now) than have it blocked on me doing the reorganisation first. |
Collaborator
|
☔ The latest upstream changes (presumably #22796) made this pull request unmergeable. Please resolve the merge conflicts. |
Contributor
Author
|
Rebased & fixed the missing word. |
Contributor
Collaborator
|
⌛ Testing commit 26ea732 with merge 35923cb... |
Collaborator
|
💔 Test failed - auto-win-32-nopt-t |
Member
|
@bors: retry clean |
Collaborator
|
☔ The latest upstream changes (presumably #22860) made this pull request unmergeable. Please resolve the merge conflicts. |
This pulls out the implementations of most built-in lints into a
separate crate, to reduce edit-compile-test iteration times with
librustc_lint and increase parallelism. This should enable lints to be
refactored, added and deleted much more easily as it slashes the
edit-compile cycle to get a minimal working compiler to test with (`make
rustc-stage1`) from
librustc -> librustc_typeck -> ... -> librustc_driver ->
libcore -> ... -> libstd
to
librustc_lint -> librustc_driver -> libcore -> ... libstd
which is significantly faster, mainly due to avoiding the librustc build
itself.
The intention would be to move as much as possible of the infrastructure
into the crate too, but the plumbing is deeply intertwined with librustc
itself at the moment. Also, there are lints for which diagnostics are
registered directly in the compiler code, not in their own crate
traversal, and their definitions have to remain in librustc.
This is a [breaking-change] for direct users of the compiler APIs:
callers of `rustc::session::build_session` or
`rustc::session::build_session_` need to manually call
`rustc_lint::register_builtins` on their return value.
This should make rust-lang#22206 easier.
Contributor
Author
|
@bors r=kmcallister 3909 |
Collaborator
bors
added a commit
that referenced
this pull request
Feb 28, 2015
This pulls out the implementations of most built-in lints into a
separate crate, to reduce edit-compile-test iteration times with
librustc_lint and increase parallelism. This should enable lints to be
refactored, added and deleted much more easily as it slashes the
edit-compile cycle to get a minimal working compiler to test with (`make
rustc-stage1`) from
librustc -> librustc_typeck -> ... -> librustc_driver ->
libcore -> ... -> libstd
to
librustc_lint -> librustc_driver -> libcore -> ... libstd
which is significantly faster, mainly due to avoiding the librustc build
itself.
The intention would be to move as much as possible of the infrastructure
into the crate too, but the plumbing is deeply intertwined with librustc
itself at the moment. Also, there are lints for which diagnostics are
registered directly in the compiler code, not in their own crate
traversal, and their definitions have to remain in librustc.
This is a [breaking-change] for direct users of the compiler APIs:
callers of `rustc::session::build_session` or
`rustc::session::build_session_` need to manually call
`rustc_lint::register_builtins` on their return value.
This should make #22206 easier.
Collaborator
This was referenced Feb 28, 2015
Closed
Member
|
\o/ |
This was referenced Feb 28, 2015
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This pulls out the implementations of most built-in lints into a
separate crate, to reduce edit-compile-test iteration times with
librustc_lint and increase parallelism. This should enable lints to be
refactored, added and deleted much more easily as it slashes the
edit-compile cycle to get a minimal working compiler to test with (
make rustc-stage1) fromto
which is significantly faster, mainly due to avoiding the librustc build
itself.
The intention would be to move as much as possible of the infrastructure
into the crate too, but the plumbing is deeply intertwined with librustc
itself at the moment. Also, there are lints for which diagnostics are
registered directly in the compiler code, not in their own crate
traversal, and their definitions have to remain in librustc.
This is a [breaking-change] for direct users of the compiler APIs:
callers of
rustc::session::build_sessionorrustc::session::build_session_need to manually callrustc_lint::register_builtinson their return value.This should make #22206 easier.