Uh oh!
There was an error while loading. Please reload this page.
Separate most of rustc::lint::builtin into a separate crate. - #22801
Merged
Conversation
rust-highfive
commented
Feb 25, 2015
Contributor
r? @eddyb (rust_highfive has picked a reviewer for you, use r? to override) |
huonw
commented
Feb 25, 2015
ContributorAuthor
r? @kmcallister |
nagisa
commented
Feb 25, 2015
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. |
huonw
commented
Feb 25, 2015
ContributorAuthor
@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. |
bors
commented
Feb 25, 2015
Collaborator
☔ The latest upstream changes (presumably #22796) made this pull request unmergeable. Please resolve the merge conflicts. |
huonw
commented
Feb 26, 2015
ContributorAuthor
Rebased & fixed the missing word. |
kmcallister
commented
Feb 27, 2015
Contributor
bors
commented
Feb 27, 2015
Collaborator
⌛ Testing commit 26ea732 with merge 35923cb... |
bors
commented
Feb 27, 2015
Collaborator
💔 Test failed - auto-win-32-nopt-t |
alexcrichton
commented
Feb 27, 2015
Member
@bors: retry clean |
bors
commented
Feb 28, 2015
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.
huonw
commented
Feb 28, 2015
ContributorAuthor
@bors r=kmcallister 3909 |
bors
commented
Feb 28, 2015
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.
bors
commented
Feb 28, 2015
Collaborator
This was referenced Feb 28, 2015
Closed
Manishearth
commented
Feb 28, 2015
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 freeto 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.