Uh oh!
There was an error while loading. Please reload this page.
Build stage0/lib/libstd.so using the stage0 compiler. - #720
Conversation
This essentially starts the bootstrapping one step earlier by building the stdlib from source using the stage0 compiler and then using that stdlib to build the stage1 compiler. (Instead of starting by building the stage1 compiler and then building a stdlib with it). This means we should now be able to add features to the stdlib and use them in the compiler without having to do a snapshot. (On the flip side, this means that we now need to do a snapshot if we want to use a new language feature in the stdlib, but that doesn't really seem too burdensome (we already need to snapshot if we want to use a new language feature in the compiler)).
espindola
commented
Jul 21, 2011
I like the idea. Not sure about doing part of the work in stage0.mk and part in stageN.mk, but we can fix that afterwards. |
msullivan
commented
Jul 21, 2011
Putting it in stage0.mk doesn't work because the macro you need to invoke hasn't been defined yet. I guess if we included stageN.mk before stage0.mk... |
brson
commented
Jul 21, 2011
I kind of dislike building into stage0, but don't necessarily see a better solution. If we did this we would probably want to snapshot stage3/libstd.so and not stage3/lib/libstd.so, right? And if we're going down this path, does it also make sense to do the same thing with rustrt? Snapshot the stage3/ version and build the stage0/lib version. |
msullivan
commented
Jul 21, 2011
I think we want to snapshot the stage3/lib/libstd.so version, and not the stage3/libstd.so version. It doesn't matter for stage3, since they should be the same. But if we were taking a stage1 or stage2 snapshot, we definitely want the version built with the stage1 or stage2 compiler, which means the lib version. (Of course, we want it to wind up as stage0/libstd.so and not stage0/lib/libstd.so.) I think that it probably does not make sense to build a stage0/lib/rustrt. Since calls into the runtime are generally inserted by the compiler and not called directly, the stage1 compiler won't depend on new runtime features since the stage0 compiler won't be generating calls to them anyways. I might be mistaken about how rustrt is used, though, so... |
brson
commented
Jul 21, 2011
Isn't it true that stageN/rustc always dynamically links to stageN/libstd.so? If that's true then no matter which stage you're at, the stageN/ version of std is the one you need to hold on to, I think. Anyway, that doesn't really affect this patch. |
msullivan
commented
Jul 21, 2011
I updated the patch to instantiate the rules from stage0.mk. |
brson
commented
Jul 21, 2011
Integrated. |
Add more fcntl and seal constants for Android/Linux
document `bind_by_move_pattern_guards`
Update the libm submodule
Refactored the codebase to use Function instead of RValue where possible.
* Updated Caesar Cipher to handle large inputs and rotations * Restored previously removed tests to ensure comprehensive test coverage. * Renamed Caesar function and make it public * Code formatting * Removed code example from function docs because it's breaking the tests * Removed unused trait that has not been warned by the `cargo clippy --all -- -D warnings` * Fix rust docs * Fix rust docs * Separate the cipher rotation on its own function * Added rotation range validation * Improvement in Caesar algorithm testing * Separated the caesar tests Dedicated macro_rule for happy path and error cases * Resolving requested changes Defined the alphabet length as a constant: `b'z' - b'a' + 1` * Resolved requested changes * Removed unecessary tests
916: Error handling for macros r=matklad a=detrumi Part of rust-lang#720 Co-authored-by: Wilco Kusee <wilcokusee@gmail.com>
1105: [WIP] Implement ra_mbe meta variables support r=matklad a=edwin0cheng This PR implements the following meta variable support in `ra_mba` crate (issue rust-lang#720): - [x] `path` - [ ] `expr` - [ ] `ty` - [ ] `pat` - [ ] `stmt` - [ ] `block` - [ ] `meta` - [ ] `item` *Implementation Details* In the macro expanding lhs phase, if we see a meta variable type, we try to create a `tt:TokenTree` from the remaining input. And then we use a special set of `ra_parser` to parse it to `SyntaxNode`. Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
fix for latest Rust
This essentially starts the bootstrapping one step earlier by building
the stdlib from source using the stage0 compiler and then using that
stdlib to build the stage1 compiler. (Instead of starting by building
the stage1 compiler and then building a stdlib with it).
This means we should now be able to add features to the stdlib and use
them in the compiler without having to do a snapshot. (On the flip
side, this means that we now need to do a snapshot if we want to use a
new language feature in the stdlib, but that doesn't really seem too
burdensome (we already need to snapshot if we want to use a new
language feature in the compiler)).