-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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 5 pull requests #81718
Merged
Merged
Rollup of 5 pull requests #81718
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
The issue: See this Rust playground link: https://play.rust-lang.org/?edition=2018&gist=12cb5d1e7527f8c37743b87fc4a53748 Run the above with clippy to see the following warning: ``` warning: returning the result of a `let` binding from a block --> src/main.rs:24:5 | 23 | let value = Foo::new(&x).value(); | --------------------------------- unnecessary `let` binding 24 | value | ^^^^^ | = note: `#[warn(clippy::let_and_return)]` on by default = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#let_and_return help: return the expression directly | 23 | 24 | Foo::new(&x).value() | ``` Implementing the suggested fix, removing the temporary let binding, yields a compiler error: ``` error[E0597]: `x` does not live long enough --> src/main.rs:23:14 | 23 | Foo::new(&x).value() | ---------^^- | | | | | borrowed value does not live long enough | a temporary with access to the borrow is created here ... 24 | } | - | | | `x` dropped here while still borrowed | ... and the borrow might be used here, when that temporary is dropped and runs the `Drop` code for type `Foo` | = note: the temporary is part of an expression at the end of a block; consider forcing this temporary to be dropped sooner, before the block's local variables are dropped help: for example, you could save the expression's value in a new local variable `x` and then make `x` be the expression at the end of the block | 23 | let x = Foo::new(&x).value(); x | ^^^^^^^ ^^^ ``` The fix: Of course, clippy looks like it should already handle this edge case; however, it appears `utils::fn_def_id` is not returning a `DefId` for `Foo::new`. Changing the `qpath_res` lookup to use the child Path `hir_id` instead of the parent Call `hir_id` fixes the issue.
…=flip1995 clippy_dev: Pass stderr to CommandFailed This improves error reporting when running `rustfmt` fails for some reason, as seen [on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/Issue.20with.20rustfmt). It will now include the stderr output in the `CliError::CommandFailed` error. changelog: none
…1995 Do not lint when range is completely included into another one This fix has been developed following this [comment](rust-lang/rust-clippy#5986 (comment)). So this will be linted: ``` |----------| |-----------| ``` Now this won't be linted: ``` |---| |--------------------| ``` and this will still lint: ``` |--------| |--------------| ``` Fixes: rust-lang#5986 changelog: Fix FPs in match_overlapping_arm, when first arm is completely included in second arm
Implement Rust 2021 panic This implements the Rust 2021 versions of `panic!()`. See rust-lang#80162 and rust-lang/rfcs#3007. It does so by replacing `{std, core}::panic!()` by a bulitin macro that expands to either `$crate::panic::panic_2015!(..)` or `$crate::panic::panic_2021!(..)` depending on the edition of the caller. This does not yet make std's panic an alias for core's panic on Rust 2021 as the RFC proposes. That will be a separate change: rust-lang@c5273bd That change is blocked on figuring out what to do with rust-lang#80846 first.
exhaustive_structs: don't trigger for structs with private fields changelog: Restrict `exhaustive_structs` to structs with all-public fields
Fix let_and_return false positive The issue: See this Rust playground link: https://play.rust-lang.org/?edition=2018&gist=12cb5d1e7527f8c37743b87fc4a53748 Run the above with clippy to see the following warning: ``` warning: returning the result of a `let` binding from a block --> src/main.rs:24:5 | 23 | let value = Foo::new(&x).value(); | --------------------------------- unnecessary `let` binding 24 | value | ^^^^^ | = note: `#[warn(clippy::let_and_return)]` on by default = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#let_and_return help: return the expression directly | 23 | 24 | Foo::new(&x).value() | ``` Implementing the suggested fix, removing the temporary let binding, yields a compiler error: ``` error[E0597]: `x` does not live long enough --> src/main.rs:23:14 | 23 | Foo::new(&x).value() | ---------^^- | | | | | borrowed value does not live long enough | a temporary with access to the borrow is created here ... 24 | } | - | | | `x` dropped here while still borrowed | ... and the borrow might be used here, when that temporary is dropped and runs the `Drop` code for type `Foo` | = note: the temporary is part of an expression at the end of a block; consider forcing this temporary to be dropped sooner, before the block's local variables are dropped help: for example, you could save the expression's value in a new local variable `x` and then make `x` be the expression at the end of the block | 23 | let x = Foo::new(&x).value(); x | ^^^^^^^ ^^^ ``` The fix: Of course, clippy looks like it should already handle this edge case; however, it appears `utils::fn_def_id` is not returning a `DefId` for `Foo::new`. Changing the `qpath_res` lookup to use the child Path `hir_id` instead of the parent Call `hir_id` fixes the issue. changelog: none
…ip1995 Add new lint "missing_panics_doc" fixes rust-lang#1974 changelog: Added the "missing_panics_doc" lint which lints when public functions that may panic are missing "# Panics" in their doc comment
Remove Option from `path_to_res` return type changelog: none Tiny cleanup for `path_to_res` to return `Res` instead of `Option<Res>`.
Editorconfig is a lightweight specification that helps maintaining consistent coding/formatting style accross editors, especially those editors that are not explicitly aware of Rust and rustfmt. https://editorconfig.org/
Box the biggest ast::ItemKind variants This PR is a different approach on rust-lang#81400, aiming to save memory in humongous ASTs. The three affected item kind enums are: - `ast::ItemKind` (208 -> 112 bytes) - `ast::AssocItemKind` (176 -> 72 bytes) - `ast::ForeignItemKind` (176 -> 72 bytes)
…ion-some-nits, r=flip1995 Updated some NITs in the documentation from rust-lang#6630 I've implemented the two suggestions from rust-lang#6630 that were added after the merge. This PR also changes the example code to use `register_*_pass` instead of `register_late_pass`. I'm not sure if this is better or worse, but it makes it clearer in my opinion. Let me know if I should change it back. --- changelog: none r? `@flip1995`
…Simulacrum Add .editorconfig This adds a .editorconfig file to rust-lang/rust, matching Clippy's. It's not clear that this will benefit many people, but the cost is low and the rewards are potentially meaningful.
Rustup Pulling in AST changes changelog: none
The following code is supposed to compile ```rust use std::ops::BitOr; pub trait IntWrapper { type InternalStorage; } impl<T> BitOr for dyn IntWrapper<InternalStorage = T> where Self: Sized, T: BitOr + BitOr<Output = T>, { type Output = Self; fn bitor(self, _other: Self) -> Self { todo!() } } ``` Before this change it would ICE. In rust-lang#70998 the removed logic was added to provide better suggestions, and the `delay_span_bug` guard was added to protect against a potential logic error when returning traits. As it happens, there are cases, like the one above, where traits can indeed be returned, so valid code was being rejected. Fix rust-lang#80207.
The tab replacement for diagnostics added in rust-lang#79757 included a few assertions to ensure all tab characters are handled appropriately. We've started getting reports of these assertions firing (rust-lang#81614). Since it's only a cosmetic issue, this downgrades the assertions to debug only, so we at least continue compiling even if the diagnostics might be a tad wonky. Fixes rust-lang#81614
Co-authored-by: eddyb <eddyb@lyken.rs>
make const_err a future incompat lint This is the first step for rust-lang#71800: make const_err a future-incompat lint. I also rewrote the const_err lint description as the old one seemed wrong. This has the unfortunate side-effect of making const-eval error even more verbose by making the const_err message longer without fixing the redundancy caused by additionally emitting an error on each use site of the constant. We cannot fix that redundancy until const_err is a *hard* error (at that point the error-on-use-site can be turned into a `delay_span_bug!` for uses of monomorphic consts, and into a nicely rendered error for [lazily / post-monomorhization evaluated] associated consts). ~~The one annoying effect of this PR is that `let _x = &(1/(1-1));` now also shows the future-incompat warning, even though of course we will *not* make this a hard error. We'll instead (hopefully) stop promoting it -- see rust-lang/rfcs#3027. The only way I see to avoid the future-incompat warning is to use a different lint for "failure to evaluate promoted".~~ Cc `@rust-lang/wg-const-eval`
Remove incorrect `delay_span_bug` The following code is supposed to compile ```rust use std::ops::BitOr; pub trait IntWrapper { type InternalStorage; } impl<T> BitOr for dyn IntWrapper<InternalStorage = T> where Self: Sized, T: BitOr + BitOr<Output = T>, { type Output = Self; fn bitor(self, _other: Self) -> Self { todo!() } } ``` Before this change it would ICE. In rust-lang#70998 the removed logic was added to provide better suggestions, and the `delay_span_bug` guard was added to protect against a potential logic error when returning traits. As it happens, there are cases, like the one above, where traits can indeed be returned, so valid code was being rejected. Fix (but not close) rust-lang#80207.
Update clippy r? `@flip1995`
…tebank Reduce tab formatting assertions to debug only The tab replacement for diagnostics added in rust-lang#79757 included a few assertions to ensure all tab characters are handled appropriately. We've started getting reports of these assertions firing (rust-lang#81614). Since it's only a cosmetic issue, this downgrades the assertions to debug only, so we at least continue compiling even if the diagnostics might be a tad wonky. Minimizes the impact of rust-lang#81614
Fix non-existent-field ICE for generic fields. I mentioned this ICE in a chat and it took about 3 milliseconds before `@eddyb` found the problem and said this change would fix it. :) This also changes one the field types in the related test to one that triggered the ICE. Fixes rust-lang#81627. Fixes rust-lang#81672. Fixes rust-lang#81709. Cc rust-lang#81480 `@b-naber` `@estebank.`
@bors r+ p=19 rollup=never There's five high-priority PRs in the queue. Rolling them up and adding the sum of their prioriry. |
📌 Commit 4617418 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
Feb 3, 2021
Good thinking! This way they'll all be in the next nightly :) |
☀️ Test successful - checks-actions |
rust-highfive
added a commit
to rust-lang-nursery/rust-toolstate
that referenced
this pull request
Feb 3, 2021
Tested on commit rust-lang/rust@120b2a7. Direct link to PR: <rust-lang/rust#81718> 💔 miri on windows: test-pass → test-fail (cc @oli-obk @eddyb @RalfJung). 💔 miri on linux: test-pass → test-fail (cc @oli-obk @eddyb @RalfJung).
This was referenced Feb 3, 2021
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:
delay_span_bug
#81532 (Remove incorrectdelay_span_bug
)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup