Rollup of 7 pull requests #31210
Merged
Rollup of 7 pull requests #31210
Conversation
This file contains 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
… in format_args! and derive to maintain compatability
Following RFC 1462 (amending 550). Closes rust-lang#31135.
Also remove a "finally" in the section about building for release to make it feel a bit friendlier.
The implementation changed in 33a2191, but the comments did not change to match.
…lexcrichton Version of Clang in repository is 3.9 So, error is caused by ``` ./configure --enable-dist-host-only --enable-clang ``` Then, I got ``` configure: error: bad CLANG version: 3.9.0 (http://llvm.org/git/clang.git 3d5d4c39659f11dfbe8e11c857cadf5c449b559b) (http://llvm.org/git/llvm.git, need >=3.0svn ``` I fixed this issue by appending 3.9* in the if sentence. Thanks.
The implementation changed in 33a2191, but the comments did not change to match. r? @alexcrichton
…klabnik Also remove a "finally" in the section about building for release to make it feel a bit friendlier.
LLVM was upgraded to a new version in this commit: rust-lang@f9d4149 which was part of this pull request: rust-lang#26025 Consider the following two lines from that commit: rust-lang@f9d4149#diff-a3b24dbe2ea7c1981f9ac79f9745f40aL462 rust-lang@f9d4149#diff-a3b24dbe2ea7c1981f9ac79f9745f40aL469 The purpose of these lines is to register LLVM passes. Prior to the that commit, the passes being handled were assumed to be ModulePasses (a specific type of LLVM pass) since they were being added to a ModulePass manager. After that commit, both lines were refactored (presumably in an attempt to DRY out the code), but the ModulePasses were changed to be registered to a FunctionPass manager. This change resulted in ModulePasses being run, but a Function object was being passed as a parameter to the pass instead of a Module, which resulted in segmentation faults. In this commit, I changed relevant sections of the code to check the type of the passes being added and register them to the appropriate pass manager. Closes rust-lang#31067
In 95d9046 output was accidentally moved from STDERR to STDOUT. This commit also changes the order of debug output. Previously, it was: ``` /* id 22: … */ { … } DEBUG:rustc::middle::dataflow: ``` Now, it is: ``` DEBUG:rustc::middle::dataflow: /* id 22: … */ { … } ```
Register LLVM passes with the correct LLVM pass manager. LLVM was upgraded to a new version in this commit: rust-lang@f9d4149 which was part of this pull request: rust-lang#26025 Consider the following two lines from that commit: rust-lang@f9d4149#diff-a3b24dbe2ea7c1981f9ac79f9745f40aL462 rust-lang@f9d4149#diff-a3b24dbe2ea7c1981f9ac79f9745f40aL469 The purpose of these lines is to register LLVM passes. Prior to the that commit, the passes being handled were assumed to be ModulePasses (a specific type of LLVM pass) since they were being added to a ModulePass manager. After that commit, both lines were refactored (presumably in an attempt to DRY out the code), but the ModulePasses were changed to be registered to a FunctionPass manager. This change resulted in ModulePasses being run, but a Function object was being passed as a parameter to the pass instead of a Module, which resulted in segmentation faults. In this commit, I changed relevant sections of the code to check the type of the passes being added and register them to the appropriate pass manager. Closes rust-lang#31067
In 95d9046 output was accidentally moved from STDERR to STDOUT. This commit also changes the order of debug output. Previously, it was: ``` /* id 22: … */ { … } DEBUG:rustc::middle::dataflow: ``` Now, it is: ``` DEBUG:rustc::middle::dataflow: /* id 22: … */ { … } ```
it is pre-RFC1214 junk
Also got rid of some code repetition in `const_eval`
It was moved in rust-lang#29538.
It was removed in rust-lang#30595. Also delete the old learn-rust.md.
Also altered the format_args! syntax extension, and \#[derive(debug)], to maintain compatability. r? @ nrc
This PR adds some minor error correction to the parser - if there is a missing ident, we recover and carry on. It also makes compilation more robust so that non-fatal errors (which is still most of them, unfortunately) in parsing do not cause us to abort compilation. The effect is that a program with a missing or incorrect ident can get all the way to type checking.
…tsakis it is pre-RFC1214 junk and completely useless. r? @nikomatsakis
|
@bors r+ p=10 force |
|
📌 Commit 79157b3 has been approved by |
|
r? @brson (rust_highfive has picked a reviewer for you, use r? to override) |
bors
added a commit
that referenced
this pull request
Jan 26, 2016
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
[to FOLLOW(ty)) #31152, remove implicator #31184, Fix a couple of dead links in the book #31189, RefCell::borrow_mut example should demonstrate mut #31192, Fix typo in "Loops" section of the book #31197, Mention the need for a linker #31199, Describe next_back() wrt Iterator protocol #31201