Skip to content
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 35 commits into from
Sep 16, 2019
Merged

Rollup of 10 pull requests #64510

merged 35 commits into from
Sep 16, 2019

Conversation

Centril
Copy link
Contributor

@Centril Centril commented Sep 16, 2019

Successful merges:

Failed merges:

r? @ghost

ehuss and others added 30 commits September 13, 2019 20:59
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
…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.
@Centril
Copy link
Contributor Author

Centril commented Sep 16, 2019

@bors r+ p=10 rollup=never

@bors
Copy link
Contributor

bors commented Sep 16, 2019

📌 Commit f4ff418 has been approved by Centril

@bors 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
Copy link
Contributor

bors commented Sep 16, 2019

⌛ Testing commit f4ff418 with merge a44881d...

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
@bors
Copy link
Contributor

bors commented Sep 16, 2019

☀️ Test successful - checks-azure
Approved by: Centril
Pushing a44881d to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Sep 16, 2019
@bors bors merged commit f4ff418 into rust-lang:master Sep 16, 2019
@Centril Centril deleted the rollup-m03zsq8 branch September 16, 2019 20:02
@Centril Centril added the rollup A PR which is a rollup label Oct 2, 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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants