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 6 pull requests #80055

Merged
merged 14 commits into from Dec 15, 2020
Merged

Rollup of 6 pull requests #80055

merged 14 commits into from Dec 15, 2020

Conversation

GuillaumeGomez
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

GuillaumeGomez and others added 14 commits November 24, 2020 14:13
Fixes: rust-lang#79569

Fixes: rust-lang#79566
Fixes: rust-lang#79565

For the first issue (rust-lang#79569), I got hit a `debug_assert!()` before
encountering the reported error message (because I have `debug = true`
enabled in my config.toml).

The assertion showed me that some `SwitchInt`s can have more than one
target pointing to the same `BasicBlock`.

I had thought that was invalid, but since it seems to be possible, I'm
allowing this now.

I added a new test for this.

----

In the last two cases above, both tests (intentionally) fail to compile,
but the `InstrumentCoverage` pass is invoked anyway.

The MIR starts with an `Unreachable` `BasicBlock`, which I hadn't
encountered before. (I had assumed the `InstrumentCoverage` pass
would only be invoked with MIRs from successful compilations.)

I don't have test infrastructure set up to test coverage on files that
fail to compile, so I didn't add a new test.
Adds checks for:

* `no_core` attribute
* explicitly-enabled `legacy` symbol mangling
* mir_opt_level > 1 (which enables inlining)

I removed code from the `Inline` MIR pass that forcibly disabled
inlining if `-Zinstrument-coverage` was set. The default `mir_opt_level`
does not enable inlining anyway. But if the level is explicitly set and
is greater than 1, I issue a warning.

The new warnings show up in tests, which is much better for diagnosing
potential option conflicts in these cases.
This ensures consistent handling of default values for options that are
None if not specified on the command line.
…Nemo157

Show hidden elements by default when JS is disabled

Fixes  rust-lang#79301.

A lot of things are hidden by default which shouldn't when JS is disabled. This PR fixes it.

Before:

![Screenshot from 2020-11-24 14-10-16](https://user-images.githubusercontent.com/3050060/100099361-a16d5580-2e5f-11eb-891b-a4c005aeb1d0.png)

After:

![after](https://user-images.githubusercontent.com/3050060/100099382-a6caa000-2e5f-11eb-8190-14f330aff9a2.png)

r? `@jyn514`
…t-when-collapsing, r=jyn514

Hide associated constants too when collapsing implementation

Fixes rust-lang#71849.

r? `@jyn514`
…2.0, r=tmandry

Fixes reported bugs in Rust Coverage

Fixes: rust-lang#79569

Fixes: rust-lang#79566
Fixes: rust-lang#79565

For the first issue (rust-lang#79569), I got hit a `debug_assert!()` before
encountering the reported error message (because I have `debug = true`
enabled in my config.toml).

The assertion showed me that some `SwitchInt`s can have more than one
target pointing to the same `BasicBlock`.

I had thought that was invalid, but since it seems to be possible, I'm
allowing this now.

I added a new test for this.

----

In the last two cases above, both tests (intentionally) fail to compile,
but the `InstrumentCoverage` pass is invoked anyway.

The MIR starts with an `Unreachable` `BasicBlock`, which I hadn't
encountered before. (I had assumed the `InstrumentCoverage` pass
would only be invoked with MIRs from successful compilations.)

I don't have test infrastructure set up to test coverage on files that
fail to compile, so I didn't add a new test.

r? `@tmandry`
FYI: `@wesleywiser`
Use imports instead of rewriting the type signature of `RustcOptGroup::stable`

This was an adventure; see https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/'higher.20ranked.20subtype.20error'

r? `@GuillaumeGomez`
…crum

Replace some `println!` with `tidy_error!` to simplify
@rustbot rustbot added the rollup A PR which is a rollup label Dec 15, 2020
@GuillaumeGomez
Copy link
Member Author

@bors: r+ p=6

@bors
Copy link
Contributor

bors commented Dec 15, 2020

📌 Commit 0dcf99b has been approved by GuillaumeGomez

@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 Dec 15, 2020
@bors
Copy link
Contributor

bors commented Dec 15, 2020

⌛ Testing commit 0dcf99b with merge e15ec66...

@bors
Copy link
Contributor

bors commented Dec 15, 2020

☀️ Test successful - checks-actions
Approved by: GuillaumeGomez
Pushing e15ec66 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Dec 15, 2020
@bors bors merged commit e15ec66 into rust-lang:master Dec 15, 2020
@rustbot rustbot added this to the 1.50.0 milestone Dec 15, 2020
@GuillaumeGomez GuillaumeGomez deleted the rollup-p09mweg branch December 15, 2020 19:43
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.

None yet

7 participants