-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 10 pull requests #64510
Merged
Merged
Rollup of 10 pull requests #64510
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
… always intern constants as immutable
The early error is more than sufficient for fixing the problem.
GitHub only allows people explicitly listed as collaborators on the repository or who commented on the issue/PR to be assignees, failing to create the issue if non-assignable people are assigned. This adds an extra check on CI to make sure all the people listed as tool maintainers can be assigned to toolstate issues. The check won't be executed on PR builds due to the lack of a valid token.
They don't contribute to rust-by-example anymore.
Make sure interned constants are immutable This makes sure that interning for constants (not statics) creates only immutable allocations. Previously, the "main" allocation of `const FOO: Cell<i32> = Cell::new(0);` was marked as mutable, but I don't think we want that. It can be only copied, not written to. Also, "leftover" allocations (behind raw pointers etc) were left mutable. I don't think we want to support that. I tried asserting that these are all already immutable (to double-check our static checks), but that failed in this one: ```rust const NON_NULL_PTR2: NonNull<u8> = unsafe { mem::transmute(&0) }; ``` Seems like maybe we want more precise mutability annotation inside Miri for locals (like `&0` here) so that this would actually become immutable to begin with? I also factored `intern_shallow` out of the visitor so that we don't have to construct a visitor when we do not plan to visit anything. That confused me at first.
…excrichton Stabilize `Vec::new` and `String::new` as `const fn`s Closes rust-lang#64022. r? @oli-obk
…ntainers, r=kennytm ci: ensure all tool maintainers are assignable on issues GitHub only allows people explicitly listed as collaborators on the repository or who commented on the issue/PR to be assignees, failing to create the issue if non-assignable people are assigned. This adds an extra check on CI to make sure all the people listed as tool maintainers can be assigned to toolstate issues. The check won't be executed on PR builds due to the lack of a valid token. r? @kennytm
fix building libstd without backtrace feature Fixes rust-lang#64410 r? @alexcrichton
…ichton Fix build script sanitizer check. rust-lang#64166 changed the way the sanitizer build scripts work. However, they were changed so that they switch between new-style to old-style cargo fingerprints. This trips up on rust-lang/cargo#6779. It also causes rustbuild to panic. If you build stage1 std (with sanitizers off), and then enable sanitizers, it panics. (This is because the build scripts don't declare that they need to re-run.) This PR will trip rust-lang/cargo#6779 again, unfortunately. I've been having way too many unexplained rebuilds in rust-lang/rust recently, but at least I'll know why this time. This doesn't fix all problems with the build scripts, but arguably they should be fixed in cargo. For example, the build scripts change which rerun-if statements they declare between runs which triggers rust-lang/cargo#7362. The test for this is: 1. Turn off sanitizers (which is the default) 2. `./x.py build --stage=1 src/libstd` 3. `./x.py build --stage=1 src/libstd` again should be a null build. 4. Enable sanitizers. 5. `./x.py build --stage=1 src/libstd` should rebuild with sanitizers enabled. 6. `./x.py build --stage=1 src/libstd` again should be a null build. This actually rebuilds due to rust-lang/cargo#7362 because the rerun-if directives changed between step 3 and 5. A 3rd attempt should be a null build.
when Miri tests are not passing, do not add Miri component This makes build-manifest query the toolstate repo at https://github.com/rust-lang-nursery/rust-toolstate to figure out if the tests of the Miri component are passing. If they are not, we remove the component from the manifest, to avoid shipping a broken Miri. I tested this locally by running build-manifest and making sure that it correctly detects the toolstate of 02785da as broken. r? @pietroalbini Cc @kennytm @alexcrichton Fixes rust-lang#60301
…r=estebank Hide diagnostics emitted during --cfg parsing The early error is more than sufficient for fixing the problem. Fixes rust-lang#31496.
Don't print the "total" `-Ztime-passes` output if `--prints=...` is also given Fixes rust-lang#64339.
…functions, r=petrochenkov Use `Symbol` in two more functions. r? @petrochenkov
…tr, r=jonas-schievink use println!() instead of println!("") The empty string is unnecessary.
@bors r+ p=10 rollup=never |
📌 Commit f4ff418 has been approved by |
bors
added
the
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
label
Sep 16, 2019
bors
added a commit
that referenced
this pull request
Sep 16, 2019
Rollup of 10 pull requests Successful merges: - #63955 (Make sure interned constants are immutable) - #64028 (Stabilize `Vec::new` and `String::new` as `const fn`s) - #64119 (ci: ensure all tool maintainers are assignable on issues) - #64444 (fix building libstd without backtrace feature) - #64446 (Fix build script sanitizer check.) - #64451 (when Miri tests are not passing, do not add Miri component) - #64467 (Hide diagnostics emitted during --cfg parsing) - #64497 (Don't print the "total" `-Ztime-passes` output if `--prints=...` is also given) - #64499 (Use `Symbol` in two more functions.) - #64504 (use println!() instead of println!("")) Failed merges: r? @ghost
☀️ Test successful - checks-azure |
This was referenced Sep 16, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
merged-by-bors
This PR was explicitly merged by bors.
rollup
A PR which is a rollup
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
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.
Successful merges:
Vec::new
andString::new
asconst fn
s #64028 (StabilizeVec::new
andString::new
asconst fn
s)-Ztime-passes
output if--prints=...
is also given #64497 (Don't print the "total"-Ztime-passes
output if--prints=...
is also given)Symbol
in two more functions. #64499 (UseSymbol
in two more functions.)Failed merges:
r? @ghost