Uh oh!
There was an error while loading. Please reload this page.
Define _RUST_STAGEN when building rustrt. - #6714
Merged
Merged
Conversation
This lets us use #ifdefs to determine which stage of the build we happen to be in, which is useful in the event we need to make changes to rustrt that are incompatible with the code generated by stage0. This should help pave the way to completing rust-lang#6575, which will likely require changes to type signatures for spawn_fn & glue_fn in rustrt.
brson
commented
May 24, 2013
Contributor
Oh, wow. It didn't occur to me that we only build rt in one stage. This is a bigger task than I thought. |
brson
commented
May 24, 2013
Contributor
I think this is probably the cleanest way to do this, since it makes the rt build like the rest of the libraries, but it is going to increase build times. We used to have a flag in the makefiles called USE_SNAPSHOT_RT (removed in e343abd) that we removed because it was no longer being used. That flag was used to make this sort of change by reusing the snapshot rt, core and/or std libraries in stage0. |
brson
commented
May 24, 2013
Contributor
@catamorphism What do you think of this? |
catamorphism
commented
May 24, 2013
Contributor
@brson How much of an increase in build times do you think it will be? IME, the runtime doesn't take very long to build compared to the compiler and libraries. |
brson
commented
May 24, 2013
Contributor
@catamorphism Yeah, it shouldn't be that much, and it's parallelizable. |
bors added a commit
that referenced
this pull request
May 24, 2013
As discussed with @brson on IRC: This lets us use #ifdefs to determine which stage of the build we happen to be in, which is useful in the event we need to make changes to rustrt that are incompatible with the code generated by a stage0 rustc. Example of the _RUST_STAGEN flag in action here: https://gist.github.com/thomaslee/5641890 I'm not sure what tests for this change should look like, so please advise if I need to do some work around that.
flip1995 pushed a commit
to flip1995/rust
that referenced
this pull request
Feb 11, 2021
Fix typo changelog: none
U007D pushed a commit
to U007D/rust-mos
that referenced
this pull request
Aug 21, 2026
7891: Improve handling of rustc_private r=matklad a=DJMcNab This PR changes how `rust-analyzer` handles `rustc_private`. In particular, packages now must opt-in to using `rustc_private` in `Cargo.toml`, by adding: ```toml [package.metadata.rust-analyzer] rustc_private=true ``` This means that depending on crates which also use `rustc_private` will be significantly improved, since their dependencies on the `rustc_private` crates will be resolved properly. A similar approach could be used in rust-lang#6714 to allow annotating that your package uses the `test` crate, although I have not yet handled that in this PR. Additionally, we now only index the crates which are transitive dependencies of `rustc_driver` in the `rustcSource` directory. This should not cause any change in behaviour when using `rustcSource: "discover"`, as the source used then will only be a partial clone. However, if `rustcSource` pointing at a local checkout of rustc, this should significantly improve the memory usage and lower indexing time. This is because we avoids indexing all crates in `src/tools/`, which includes `rust-analyzer` itself. Furthermore, we also prefer named dependencies over dependencies from `rustcSource`. This ensures that feature resolution for crates which are depended on by both `rustc` and your crate uses the correct set for analysing your crate. See also [introductory zulip stream](https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Fwg-rls-2.2E0/topic/Fixed.20crate.20graphs.20and.20optional.20builtin.20crates/near/229086673) I have tested this in [priroda](https://github.com/oli-obk/priroda/), and it provides a significant improvement to the development experience (once I give `miri` the required data in `Cargo.toml`) Todo: - [ ] Documentation This is ready to review, and I will add documentation if this would be accepted (or if I get time to do so anyway) Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
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
4 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.
As discussed with @brson on IRC:
This lets us use #ifdefs to determine which stage of the build we happen
to be in, which is useful in the event we need to make changes to rustrt
that are incompatible with the code generated by a stage0 rustc.
Example of the _RUST_STAGEN flag in action here: https://gist.github.com/thomaslee/5641890
I'm not sure what tests for this change should look like, so please advise if I need to do some work around that.