-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Clippy subtree update #119013
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
Clippy subtree update #119013
Conversation
and add more test cases
Thanks @y21 for the hint!
& apply review suggestions;
add more test cases with `match`; minor fixes in message output regarding review feedback
Before this fix, the lint had a false positive, namely when a reference was taken to a field when the field operand implements a custom Drop. The compiler will refuse to partially move a type that implements Drop, because that would put the operand in a weird state. See added regression test.
…ilstrieb Stabilize C string literals RFC: https://rust-lang.github.io/rfcs/3348-c-str-literal.html Tracking issue: rust-lang#105723 Documentation PR (reference manual): rust-lang/reference#1423 # Stabilization report Stabilizes C string and raw C string literals (`c"..."` and `cr#"..."#`), which are expressions of type [`&CStr`](https://doc.rust-lang.org/stable/core/ffi/struct.CStr.html). Both new literals require Rust edition 2021 or later. ```rust const HELLO: &core::ffi::CStr = c"Hello, world!"; ``` C strings may contain any byte other than `NUL` (`b'\x00'`), and their in-memory representation is guaranteed to end with `NUL`. ## Implementation Originally implemented by PR rust-lang#108801, which was reverted due to unintentional changes to lexer behavior in Rust editions < 2021. The current implementation landed in PR rust-lang#113476, which restricts C string literals to Rust edition >= 2021. ## Resolutions to open questions from the RFC * Adding C character literals (`c'.'`) of type `c_char` is not part of this feature. * Support for `c"..."` literals does not prevent `c'.'` literals from being added in the future. * C string literals should not be blocked on making `&CStr` a thin pointer. * It's possible to declare constant expressions of type `&'static CStr` in stable Rust (as of v1.59), so C string literals are not adding additional coupling on the internal representation of `CStr`. * The unstable `concat_bytes!` macro should not accept `c"..."` literals. * C strings have two equally valid `&[u8]` representations (with or without terminal `NUL`), so allowing them to be used in `concat_bytes!` would be ambiguous. * Adding a type to represent C strings containing valid UTF-8 is not part of this feature. * Support for a hypothetical `&Utf8CStr` may be explored in the future, should such a type be added to Rust.
new lint: `repeat_vec_with_capacity` Closes rust-lang#11537 [Lint description](https://github.com/y21/rust-clippy/blob/repeat_vec_with_capacity/clippy_lints/src/repeat_vec_with_capacity.rs#L14) should explain this PR :) changelog: new lint: `repeat_vec_with_capacity`
[`missing_asserts_for_indexing`]: accept length equality checks Fixes rust-lang#11835 The lint now allows indexing with indices 0 and 1 when an `assert!(x.len() == 2);` is found. (Also fixed a typo in the doc example) changelog: [`missing_asserts_for_indexing`]: accept len equality checks as a valid assertion
Because the variant name in `Level` is `Note`, and the `without_error` suffix is omitted in similar cases like `struct_allow` and `struct_help`.
…bug`. Because the corresponding `Level` is `DelayedBug` and `span_delayed_bug` follows the pattern used everywhere else: `span_err`, `span_warning`, etc.
…r=compiler-errors Cleanup error handlers Mostly by making function naming more consistent. More to do after this, but this is enough for one PR. r? compiler-errors
…hiaskrgr Clippy subtree sync r? `@Manishearth`
Avoid scanning temporary files created by editors like this one created by Vim: ---- old_test_headers stdout ---- thread 'old_test_headers' panicked at tests/headers.rs:19:74: tests/ui/.regex.rs.swp: stream did not contain valid UTF-8 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
expending lint [`blocks_in_if_conditions`] to check match expr as well closes: rust-lang#11814 changelog: rename lint `blocks_in_if_conditions` to [`blocks_in_conditions`] and expand it to check blocks in match scrutinees
Do not check twice whether `qpath` is a `QPath::TypeRelative` variant This is a style fix: the outer `if` check was useless. changelog: none
Tolerate hidden, binary files in tests/ Avoid scanning temporary files created by editors like this one created by Vim: ---- old_test_headers stdout ---- thread 'old_test_headers' panicked at tests/headers.rs:19:74: tests/ui/.regex.rs.swp: stream did not contain valid UTF-8 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace changelog: none
It's hard to check whether oprator is overrided through context of lint So assume nontrivial has overrided binary operator
From the regex v1.10.0 release notes [1]: This is a new minor release of regex that adds support for start and end word boundary assertions. [...] The new word boundary assertions are: • \< or \b{start}: a Unicode start-of-word boundary (\W|\A on the left, \w on the right). • \> or \b{end}: a Unicode end-of-word boundary (\w on the left, \W|\z on the right)). • \b{start-half}: half of a Unicode start-of-word boundary (\W|\A on the left). • \b{end-half}: half of a Unicode end-of-word boundary (\W|\z on the right). [1]: https://github.com/rust-lang/regex/blob/master/CHANGELOG.md#1100-2023-10-09
close rust-lang#11066 close rust-lang#11665 close rust-lang#11911
Check whether operator is overrided with a `struct` operand. The struct here refers to `struct`, `enum`, `union`. Add and fix test for `no_effect` lint.
Rustup r? `@ghost` changelog: none
Some changes occurred in src/tools/clippy cc @rust-lang/clippy These commits modify the If this was unintentional then you should revert the changes before this PR is merged. |
This comment was marked as resolved.
This comment was marked as resolved.
Could not assign reviewer from: |
Whoops, messed up the PR name (not on my usual workstation where this is automated). Fixed it and removed the labels. |
r? @Manishearth |
huh weird, I'll check in an hour or two when I'm back home |
@bors r+ |
☀️ Test successful - checks-actions |
Finished benchmarking commit (e223c41): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 672.699s -> 672.461s (-0.04%) |
r? @matthiaskrgr (As Manish wrote that he is a bit inactive until the new year)