This needs a review this time. Especially https://github.com/rust-lang/rust-clippy/commit/521bf8f0fa18c7f130505f0a902ab0e65a76cec2 cc `@camsteffen` I think this is necessary now, because `itertools` is no longer a dependency of `clippy_utils` and therefore this path can't be found :thinking:
( I forgot about the sync last week. I should get to document this process better, so other people can do it when I'm not around )
Auto merge of #7608 - andrewpollack:7594/while_let_some_result, r=Manishearth
#7594: Adding new 'while_let_some_result' linting
Excited for the opportunity to contribute to Clippy! Since the latest Bay Area Rust Meetup, I've been looking for an opportunity and found it :smile:
Please let me know how I can improve this PR! Much of it is similar to ``[`if_let_some_result`]``, but I followed the description in the issue to create its own linting rules. Looking forward to feedback, and continuing to work on Clippy in the future!
changelog: Renamed Lint: `if_let_some_result` is now called [`match_result_ok`]. Now also handles `while let` case.
Auto merge of #7692 - workingjubilee:float-cmp-not-wrong, r=giraffate
Demote float_cmp to pedantic
See this issue: https://github.com/rust-lang/rust-clippy/issues/7666
This is one of the most frequently suppressed lints. It is deny-by-default. It is not actually clearly wrong, as there are many instances where direct float comparison is actually desirable. It is only after operating on floats that they may lose precision, and that depends greatly on the operation. As most correctness lints have a much higher standard of error, being based on hard and fast binary logic, this should not be amongst them.
A linter is not a substitute for observing the math carefully and running tests, and doing the desirable thing is even more likely to lead one to want exact comparisons.
changelog: Demote [`float_cmp`] from correctness to pedantic lints
Auto merge of #7722 - dtolnay-contrib:float, r=giraffate
Stop suggesting a float truncation that is not shorter
Fixes #7721.
Previously Clippy would say that a number has excessive precision even if it has the minimum possible precision for the floating point value that it corresponds to.
changelog: Fix [`excessive_precision`] being triggered on floats that are already written in shortest form
Auto merge of #89030 - nbdd0121:box2, r=jonas-schievink
Introduce `Rvalue::ShallowInitBox`
Polished version of #88700.
Implements MCP rust-lang/compiler-team#460, and should allow #43596 to go forward.
In short, creating an empty box is split from a nullary-op `NullOp::Box` into two steps, first a call to `exchange_malloc`, then a `Rvalue::ShallowInitBox` which transmutes `*mut u8` to a shallow-initialized `Box<T>`. This allows the `exchange_malloc` call to unwind. Details can be found in the MCP.
`NullOp::Box` is not yet removed, purely to make reverting easier in case anything goes wrong as the result of this PR. If revert is needed a reversion of "Use Rvalue::ShallowInitBox for box expression" commit followed by a test bless should be sufficient.
Experiments in #88700 showed a very slight compile-time perf regression due to (supposedly) slightly more time spent in LLVM. We could omit unwind edge generation (in non-`oom=panic` case) in box expression MIR construction to restore perf; but I don't think it's necessary since runtime perf isn't affected and perf difference is rather small.
Rollup merge of #89001 - jackh726:binder-cleanup, r=nikomatsakis
Be explicit about using Binder::dummy
This is somewhat of a late followup to the binder refactor PR. It removes `ToPredicate` and `ToPolyTraitImpls` that hide the use of `Binder::dummy`. While this does make code a bit more verbose, it allows us be more careful about where we create binders.
Another alternative here might be to add a new trait `ToBinder` or something with a `dummy()` fn. Which could still allow grepping but allows doing something like `trait_ref.dummy()` (but I also wonder if longer-term, it would be better to be even more explicit with a `bind_with_vars(ty::List::empty())` *but* that's not clear yet.
Auto merge of #7704 - camsteffen:pedantic-occasional, r=Manishearth
Tweak pedantic description for occasional FPs
changelog: none
Okay this is getting a bit picky (you might even say pedantic). I think we need to be careful not use the pedantic category as cover-all for lints with any amount of false positives. Lints with a high degree of FPs should be nursery or restriction IMO. If the pedantic category were to yield, say hypothetically, over 50% FPs, it would just be too annoying to use at all (to be sure, "too picky for me" is not a FP).
Auto merge of #89158 - the8472:rollup-3e4ijth, r=the8472
Rollup of 12 pull requests
Successful merges:
- #88795 (Print a note if a character literal contains a variation selector)
- #89015 (core::ascii::escape_default: reduce struct size)
- #89078 (Cleanup: Remove needless reference in ParentHirIterator)
- #89086 (Stabilize `Iterator::map_while`)
- #89096 ([bootstrap] Improve the error message when `ninja` is not found to link to installation instructions)
- #89113 (dont `.ensure()` the `thir_abstract_const` query call in `mir_build`)
- #89114 (Fixes a technicality regarding the size of C's `char` type)
- #89115 (:arrow_up: rust-analyzer)
- #89126 (Fix ICE when `indirect_structural_match` is allowed)
- #89141 (Impl `Error` for `FromSecsError` without foreign type)
- #89142 (Fix match for placeholder region)
- #89147 (add case for checking const refs in check_const_value_eq)
Auto merge of #89103 - Mark-Simulacrum:migrate-2021, r=estebank
Migrate in-tree crates to 2021
This replaces #89075 (cherry picking some of the commits from there), and closes #88637 and fixes #89074.
It excludes a migration of the library crates for now (see tidy diff) because we have some pending bugs around macro spans to fix there.
I instrumented bootstrap during the migration to make sure all crates moved from 2018 to 2021 had the compatibility warnings applied first.
Originally, the intent was to support cargo fix --edition within bootstrap, but this proved fairly difficult to pull off. We'd need to architect the check functionality to support running cargo check and cargo fix within the same x.py invocation, and only resetting sysroots on check. Further, it was found that cargo fix doesn't behave too well with "not quite workspaces", such as Clippy which has several crates. Bootstrap runs with --manifest-path ... for all the tools, and this makes cargo fix only attempt migration for that crate. We can't use e.g. --workspace due to needing to maintain sysroots for different phases of compilation appropriately.
It is recommended to skip the mass migration of Cargo.toml's to 2021 for review purposes; you can also use `git diff d6cd2c6c877110748296760aefddc21a0ea1d316 -I'^edition = .20...$'` to ignore the edition = 2018/21 lines in the diff.
Auto merge of #7694 - Jarcho:lintcheck_retry, r=matthiaskrgr
Retry on some download errors in lintcheck
I'm currently on spotty wifi right now. It is shocking the number of things that break when you lose connection for a few seconds. Some 500 errors should probably also be retried, but this fixes my issue.
This allows the format_args! macro to keep the pre-expansion code out of
the unsafe block without doing gymnastics with nested `match`
expressions. This reduces codegen.
Mark Rousskov [Sat, 18 Sep 2021 21:37:24 +0000 (17:37 -0400)]
Enable 2021 compatibility lints for all in-tree code
This just applies the suggested fixes from the compatibility warnings,
leaving any that are in practice spurious in. This is primarily intended to
provide a starting point to identify possible fixes to the migrations (e.g., by
avoiding spurious warnings).
A secondary commit cleans these up where they are false positives (as is true in
many of the cases).
Auto merge of #7690 - Jarcho:while_loop_by_ref, r=xFrednet
Change `while_let_on_iterator` suggestion to use `by_ref()`
It came up in the discussion #7659 that suggesting `iter.by_ref()` is a clearer suggestion than `&mut iter`. I personally think they're equivalent, but if `by_ref()` is clearer to people then that should be the suggestion.
changelog: Change `while_let_on_iterator` suggestion when using `&mut` to use `by_ref()`
Auto merge of #7671 - dtolnay-contrib:singlecharnames, r=xFrednet
Downgrade many_single_char_names to pedantic
As suggested by `@flip1995` in https://github.com/rust-lang/rust-clippy/issues/7666#issuecomment-918993215, by today's standards this lint would be considered `pedantic`.
This is one of the most widely suppressed Clippy lints on crates.io according to https://github.com/dtolnay/noisy-clippy.
In my opinion this lint is just too domain specific for Clippy to have reliable visibility into. Sure there are some cases where the author is just being lazy and could use a kick in the butt, but we're still left with an enormous number of suppressions where single chars are the most appropriate name. For example in the context of colors, a function using `h`, `s`, `l`, `r`, `g`, `b` is 100% sensible and spelling all those out is silly, but it's past the default lint threshold.
---
changelog: Moved [`many_single_char_names`] to `pedantic`
Auto merge of #7640 - kneasle:mut-key-false-positive, r=camsteffen
Improve accuracy of `mut_key`
Fixes #6745.
Whilst writing the tests for this, I noticed what I believe is a false negative (the code in `@xFrednet's` [comment](https://github.com/rust-lang/rust-clippy/issues/6745#issuecomment-909658267) doesn't trigger the lint). Currently the tests contain a case for this (which is blatantly ignored), but I'm not at all sure how to implement this (since the lint currently behaves completely differently for ADTs). I'm not sure what should be done - on the one hand the extra test cases are misleading, but on the other hand they don't cause much harm and would save effort for anyone fixing that false negative.
---
changelog: Improve accuracy of `clippy::mutable_key_type`.
Auto merge of #7646 - camsteffen:relative-target, r=flip1995
Target directory cleanup
changelog: none
* .cargo/config now has `target-dir` specified so that it is inherited by child projects. The target directory needs to be shared with clippy_dev, but not necessarily at the project root. (cc #7625)
* Uses `std::env::current_exe` (and its parent directories) whenever possible
* `CLIPPY_DRIVER_PATH` and `TARGET_LIBS` are no longer required from rustc bootstrap (but `HOST_LIBS` still is). These can be removed from the rustc side after merging.
* `CLIPPY_DOGFOOD` and the separate target directory are removed. This was originally added to mitigate #7343.
This PR introduces `Rvalue::NullaryOp(NullOp::AlignOf, ty)`, which will be lowered from `align_of`, similar to `size_of` lowering to `Rvalue::NullaryOp(NullOp::SizeOf, ty)`.
The changes are originally part of #88700 but since it's not dependent on other changes and could have performance impact on its own, it's separated into its own PR.
Auto merge of #84373 - cjgillot:resolve-span, r=michaelwoerister,petrochenkov
Encode spans relative to the enclosing item
The aim of this PR is to avoid recomputing queries when code is moved without modification.
MCP at https://github.com/rust-lang/compiler-team/issues/443
This is achieved by :
1. storing the HIR owner LocalDefId information inside the span;
2. encoding and decoding spans relative to the enclosing item in the incremental on-disk cache;
3. marking a dependency to the `source_span(LocalDefId)` query when we translate a span from the short (`Span`) representation to its explicit (`SpanData`) representation.
Since all client code uses `Span`, step 3 ensures that all manipulations
of span byte positions actually create the dependency edge between
the caller and the `source_span(LocalDefId)`.
This query return the actual absolute span of the parent item.
As a consequence, any source code motion that changes the absolute byte position of a node will either:
- modify the distance to the parent's beginning, so change the relative span's hash;
- dirty `source_span`, and trigger the incremental recomputation of all code that
depends on the span's absolute byte position.
With this scheme, I believe the dependency tracking to be accurate.
For the moment, the spans are marked during lowering.
I'd rather do this during def-collection,
but the AST MutVisitor is not practical enough just yet.
The only difference is that we attach macro-expanded spans
to their expansion point instead of the macro itself.
Auto merge of #88214 - notriddle:notriddle/for-loop-span-drop-temps-mut, r=nagisa
rustc: use more correct span data in for loop desugaring
Fixes #82462
Before:
help: consider adding semicolon after the expression so its temporaries are dropped sooner, before the local variables declared by the block are dropped
|
LL | for x in DroppingSlice(&*v).iter(); {
| +
After:
help: consider adding semicolon after the expression so its temporaries are dropped sooner, before the local variables declared by the block are dropped
|
LL | };
| +
This seems like a reasonable fix: since the desugared "expr_drop_temps_mut" contains the entire desugared loop construct, its span should contain the entire loop construct as well.
projects / rust.git / log