-
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 8 pull requests #78697
Merged
Merged
Rollup of 8 pull requests #78697
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
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.
Fix unindent in doc comments Fixes rust-lang#70732 r? ``@jyn514``
…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`
@bors r+ rollup=never p=5 |
📌 Commit 1cb137b 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
Nov 3, 2020
☀️ Test successful - checks-actions |
This was referenced Nov 3, 2020
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:
Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup