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 8 pull requests #78697

Merged
merged 26 commits into from
Nov 3, 2020
Merged

Rollup of 8 pull requests #78697

merged 26 commits into from
Nov 3, 2020

Conversation

JohnTitor
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

GuillaumeGomez and others added 26 commits October 26, 2020 21:34
No functional changes intended.
Fixes rust-lang#78660

With PR rust-lang#75534 merged, we now run
more lint-related code for future-incompat-report, even when their final
level is Allow. Some lint-related code was not expecting `Level::Allow`,
and had an explicit panic.

This PR explicitly tracks the lint level set on the command line before
`--cap-lints` is applied. This is used to emit a more precise error
note (e.g. we don't say that `-W lint-name` was specified on the
command line just because a lint was capped to Warn). As a result, we
can now correctly emit a note that `-A` was used if we got
`Level::Allow` from the command line (before the cap is applied).
I noticed that it is pointing to the same link when I was reading
rust-lang/rust-clippy#2997
See rust-lang#61733 (comment)

We now preserve the trailing semicolon in a macro invocation, even if
the macro expands to nothing. As a result, the following code no longer
compiles:

```rust
macro_rules! empty {
    () => { }
}

fn foo() -> bool { //~ ERROR mismatched
    { true } //~ ERROR mismatched
    empty!();
}
```

Previously, `{ true }` would be considered the trailing expression, even
though there's a semicolon in `empty!();`

This makes macro expansion more token-based.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
…expr, r=petrochenkov

Treat trailing semicolon as a statement in macro call

See rust-lang#61733 (comment)

We now preserve the trailing semicolon in a macro invocation, even if
the macro expands to nothing. As a result, the following code no longer
compiles:

```rust
macro_rules! empty {
    () => { }
}

fn foo() -> bool { //~ ERROR mismatched
    { true } //~ ERROR mismatched
    empty!();
}
```

Previously, `{ true }` would be considered the trailing expression, even
though there's a semicolon in `empty!();`

This makes macro expansion more token-based.
…ron1011

Add a test for compiletest rustc-env & unset-rustc-env directives

... and move compiletest meta tests into a separate directory.
…r=tmandry

Document -Zinstrument-coverage

r? ``@tmandry``
FYI ``@wesleywiser``

Here is my proposed document for LLVM source-based code coverage.

I based it on the `profile.md` page, in the same directory, and on the Clang guide for LLVM source-based coverage.
…tmandry

Fix ICE when a future-incompat-report has its command-line level capped

Fixes rust-lang#78660

With PR rust-lang#75534 merged, we now run
more lint-related code for future-incompat-report, even when their final
level is Allow. Some lint-related code was not expecting `Level::Allow`,
and had an explicit panic.

This PR explicitly tracks the lint level set on the command line before
`--cap-lints` is applied. This is used to emit a more precise error
note (e.g. we don't say that `-W lint-name` was specified on the
command line just because a lint was capped to Warn). As a result, we
can now correctly emit a note that `-A` was used if we got
`Level::Allow` from the command line (before the cap is applied).
Fix intrinsic size_of stable link

I noticed that it is pointing to the same link when I was reading
rust-lang/rust-clippy#2997
inliner: Remove redundant loop

No functional changes intended.
…s-schievink

add mipsel-unknown-none target

This adds a target for bare MIPS32r2, little endian, softfloat. This target can be used for PIC32 microcontrollers (or possibly for other devices that have a MIPS MCU core such as the M4K core).

Tried to find a name for the target that is in line with the naming scheme apparently used for the other MIPS targets.

r? `@jonas-schievink`
@rustbot rustbot added the rollup A PR which is a rollup label Nov 3, 2020
@JohnTitor
Copy link
Member Author

@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented Nov 3, 2020

📌 Commit 1cb137b has been approved by JohnTitor

@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 Nov 3, 2020
@bors
Copy link
Contributor

bors commented Nov 3, 2020

⌛ Testing commit 1cb137b with merge d662f80...

@bors
Copy link
Contributor

bors commented Nov 3, 2020

☀️ Test successful - checks-actions
Approved by: JohnTitor
Pushing d662f80 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Nov 3, 2020
@bors bors merged commit d662f80 into rust-lang:master Nov 3, 2020
@rustbot rustbot added this to the 1.49.0 milestone Nov 3, 2020
@JohnTitor JohnTitor deleted the rollup-q0fchpv branch November 3, 2020 12:32
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.

9 participants