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 11 pull requests #85005

Closed
wants to merge 38 commits into from

Conversation

Dylan-DPC-zz
Copy link

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

mzohreva and others added 30 commits April 21, 2021 14:45
std::sync::mpsc uses thread locals and depending on the order TLS dtors
are run `rx.recv()` can panic when used in a TLS dtor.
This controls whether run-* tests actually get run.
I was wary of doing any automatic disabling here, since should-fail
is how we test compiletest itself.
I came up with this idea ages ago, but rustdoc used to ICE on it. Now it
doesn't.
The comment says that build dependencies shouldn't matter unless they do
some kind of codegen. It is safer to always check it though.
using allow_internal_unstable (as recommended)

Fixes: rust-lang#84836

```shell
$ ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc     src/test/run-make-fulldeps/coverage/no_cov_crate.rs
error[E0554]: `#![feature]` may not be used on the dev release channel
 --> src/test/run-make-fulldeps/coverage/no_cov_crate.rs:2:1
  |
2 | #![feature(no_coverage)]
  | ^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

For more information about this error, try `rustc --explain E0554`.
```
I just need this until rustbuild supports -Cpanic=abort std directly.
This will make it easier for tools to programmatically detect which
channel CI is building.
…r=jethrogb

Ensure TLS destructors run before thread joins in SGX

The excellent test is from `@jethrogb`

For context see: rust-lang#83416 (comment)
…k-Simulacrum

Add --run flag to compiletest

This controls whether run-* tests actually get run.

r? `@Mark-Simulacrum`
…=Mark-Simulacrum

Add `needs-unwind` and beginning of support for testing `panic=abort` std to compiletest

For the Fuchsia platform we build libstd with `panic=abort` and would like a way to run tests with that enabled. This adds low-level support for this directly to compiletest.

In the future I'd like to add high-level support in rustbuild, e.g. having target-specific flags that allow configuring a panic strategy. (Side note: It would be nice if we could also build multiple configurations for the same target, but I'm getting ahead of myself.)

This plus rust-lang#84500 have everything that's needed to get ui tests passing on fuchsia targets.

Part of rust-lang#84766. Note that this change only includes the header on tests which need an unwinder to _build_, not those which need it to _run_.

r? ``@Mark-Simulacrum``
Allow using `core::` in intra-doc links within core itself

I came up with this idea ages ago, but rustdoc used to ICE on it. Now it doesn't.

Helps with rust-lang#73445. Doesn't fix it completely since `extern crate self as std;` in std still gives strange errors.
…, r=nagisa

Disallows `#![feature(no_coverage)]` on stable and beta (using standard crate-level gating)

Fixes: rust-lang#84836

Removes the function-level feature gating solution originally implemented, and solves the same problem using `allow_internal_unstable`, so normal crate-level feature gating mechanism can still be used (which disallows the feature on stable and beta).

I tested this, building the compiler with and without `CFG_DISABLE_UNSTABLE_FEATURES=1`

With unstable features disabled, I get the expected result as shown here:

```shell
$ ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc     src/test/run-make-fulldeps/coverage/no_cov_crate.rs
error[E0554]: `#![feature]` may not be used on the dev release channel
 --> src/test/run-make-fulldeps/coverage/no_cov_crate.rs:2:1
  |
2 | #![feature(no_coverage)]
  | ^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

For more information about this error, try `rustc --explain E0554`.
```

r? ``@Mark-Simulacrum``
cc: ``@tmandry`` ``@wesleywiser``
Wire up tidy dependency checks for cg_clif

Also contains a fix and improvement to tidy.

Required for rust-lang#81746.
Handle incorrect placement of parentheses in trait bounds more gracefully

Fix rust-lang#84772.

CC ````@jonhoo````
CTFE engine: rename copy → copy_intrinsic, move to intrinsics.rs

The `copy` name is confusing for this function because we also have `copy_op` which is pretty different. I hope `copy_intrinsic` is clearer. Also `step.rs` should really just contain the main loop and opcode dispatch, so move this helper function to a more appropriate place.

r? ````@oli-obk````
…_default_session_globals, r=jyn514

Remove unneeded call to with_default_session_globals in rustdoc highlight

This was the origin of the `Span` bug in rust-lang#84176.

cc ```@Aaron1011```
r? ```@jyn514```
…ark-Simulacrum

Error out if a PR is sent to the wrong channel

It happened multiple times that a PR meant to go on beta ends up being opened (and occasionally merged) to master. This PR does two things:

* Moves the definition of the channel in `src/ci/channel` so it's easier for tools to read it. I was not sure whether to move it to `src/channel` (like `src/version`): ended up with `src/ci` as it's currently only used for CI, but I'm open to moving it to `src`. We'll need to update the release process after this.
* Adds a check on **non-bors** builds that errors out if the base branch is not the expected one for the currently defined channel. This will not cause problems for promotion PRs, as those PRs are meant to also update the channel name.

r? `@Mark-Simulacrum`
@rustbot rustbot added the rollup A PR which is a rollup label May 6, 2021
@Dylan-DPC-zz Dylan-DPC-zz deleted the rollup-dgbyle1 branch May 6, 2021 21:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet