- 11 8月, 2023 4 次提交
-
-
由 Philipp Krones 提交于
-
由 Philipp Krones 提交于
-
由 Philipp Krones 提交于
-
由 Philipp Krones 提交于
-
- 09 8月, 2023 6 次提交
-
-
由 bors 提交于
[`slow_vector_initialization`]: clarify why `Vec::new()` + resize is worse #11198 extended this lint to also warn on `Vec::new()` + `resize(0, len)`, but did not update the lint documentation, so it left some confused (https://github.com/rust-lang/rust-clippy/issues/10938#issuecomment-1663880083). This PR should make it a bit more clear. (cc `@djc` `@vi` what do you think about this?) <details> <summary>More details</summary> Godbolt for `Vec::new()` + `.resize(x, 0)`: https://godbolt.org/z/e7q9xc9rG The resize call first does a normal allocation (`__rust_alloc`): ```asm alloc::raw_vec::finish_grow: ... cmp qword ptr [rcx + 8], 0 je .LBB1_7 ; if capacity == 0 -> LBB1_7 .LBB1_7: ... call qword ptr [rip + __rust_alloc@GOTPCREL] ``` *Then* a memset for zero initialization: ```asm example::f: ... xor esi, esi ; 0 call qword ptr [rip + memset@GOTPCREL] ``` ------------ Godbolt for `vec![0; len]`: https://godbolt.org/z/M3vr53vWY Important bit: ```asm example::f: ... call qword ptr [rip + __rust_alloc_zeroed@GOTPCREL] ``` </details> changelog: [`slow_vector_initialization`]: clarify why `Vec::new()` + resize is worse than `vec![0; len]`
-
由 y21 提交于
-
由 Timo 提交于
Co-authored-by: NDirkjan Ochtman <dirkjan@ochtman.nl>
-
由 y21 提交于
-
由 bors 提交于
[`redundant_guards`]: don't lint on float literals Fixes #11304 changelog: [`redundant_guards`]: don't lint on float literals r? `@Centri3` i figured you are probably a good reviewer for this since you implemented the lint ^^
-
由 y21 提交于
-
- 08 8月, 2023 2 次提交
-
-
由 y21 提交于
-
由 Matthias Krüger 提交于
Store the laziness of type aliases in their `DefKind` Previously, we would treat paths referring to type aliases as *lazy* type aliases if the current crate had lazy type aliases enabled independently of whether the crate which the alias was defined in had the feature enabled or not. With this PR, the laziness of a type alias depends on the crate it is defined in. This generally makes more sense to me especially if / once lazy type aliases become the default in a new edition and we need to think about *edition interoperability*: Consider the hypothetical case where the dependency crate has an older edition (and thus eager type aliases), it exports a type alias with bounds & a where-clause (which are void but technically valid), the dependent crate has the latest edition (and thus lazy type aliases) and it uses that type alias. Arguably, the bounds should *not* be checked since at any time, the dependency crate should be allowed to change the bounds at will with a *non*-major version bump & without negatively affecting downstream crates. As for the reverse case (dependency: lazy type aliases, dependent: eager type aliases), I guess it rules out anything from slight confusion to mild annoyance from upstream crate authors that would be caused by the compiler ignoring the bounds of their type aliases in downstream crates with older editions. --- This fixes #114468 since before, my assumption that the type alias associated with a given weak projection was lazy (and therefore had its variances computed) did not necessarily hold in cross-crate scenarios (which [I kinda had a hunch about](https://github.com/rust-lang/rust/pull/114253#discussion_r1278608099)) as outlined above. Now it does hold. `@rustbot` label F-lazy_type_alias r? `@oli-obk`
-
- 07 8月, 2023 5 次提交
-
-
-
由 bors 提交于
Small code style adjustments changelog: none
-
由 bors 提交于
redundant_type_annotations: only pass certain def kinds to type_of Fixes #11190 Fixes rust-lang/rust#113516 Also adds an `is_lint_allowed` check to skip the lint when it's not needed changelog: none
-
由 bors 提交于
New lints: `impossible_comparisons` and `redundant_comparisons` Inspired by a bug we had in production, like all good lints ;) Adds two lints for "double" comparisons, specifically when the same expression is being compared against two different constants. `impossible_comparisons` checks for expressions that can never be true at all. Example: ```rust status_code <= 400 && status_code > 500 ``` Presumably, the programmer intended to write `status_code >= 400 && status_code < 500` in this case. `redundant_comparisons` checks for expressions where either half has no effect. Example: ```rust status_code <= 400 && status_code < 500 ``` Works with other literal types like floats and strings, and *some* cases where the constant is more complex than a literal, see the tests for more. **Limitations and/or future work:** * Doesn't work if the LHS can have side-effects at all, for example by being a function call * Only works for exactly two comparison expressions, so `x > y && x > z && x < w` won't get checked * Doesn't check for comparison expressions combined with `||`. Very similar logic could be applied there. changelog: New lints [`impossible_comparisons`] and [`redundant_comparisons`]
-
由 Manish Goregaokar 提交于
Co-authored-by: NCatherine Flores <catherine.3.flores@gmail.com>
-
- 06 8月, 2023 12 次提交
-
-
由 Matthias Krüger 提交于
Add documentation to has_deref Documentation of `has_deref` needed some polish to be more clear about where it should be used and what's it's purpose. cc https://github.com/rust-lang/rust/issues/114401 r? `@RalfJung`
-
由 ouz-a 提交于
-
由 Morten Lohne 提交于
-
由 Morten Lohne 提交于
Replace ConstEvalLateContext::new() with two calls to constant() to simplify the code, after PR suggestion
-
由 Morten Lohne 提交于
-
由 Morten Lohne 提交于
Rename 'impossible_double_const_comparisons' -> 'impossible_comparisons' and 'ineffective_double_const_comparisons' -> 'redundant_comparisons', after discussion on Zulip
-
由 Morten Lohne 提交于
-
由 Morten Lohne 提交于
-
由 Morten Lohne 提交于
-
由 Morten Lohne 提交于
Add descriptions for 'impossible_double_const_comparisons' and 'ineffective_double_const_comparisons'
-
由 Morten Lohne 提交于
-
由 Morten Lohne 提交于
fix: Make ConstEvalLateContext::new() public, to match the 'constant_context()' function that it replaced
-
- 05 8月, 2023 4 次提交
-
-
由 lengyijun 提交于
-
由 bors 提交于
Rollup of 9 pull requests Successful merges: - #113945 (Fix wrong span for trait selection failure error reporting) - #114351 ([rustc_span][perf] Remove unnecessary string joins and allocs.) - #114418 (bump parking_lot to 0.12) - #114434 (Improve spans for indexing expressions) - #114450 (Fix ICE failed to get layout for ReferencesError) - #114461 (Fix unwrap on None) - #114462 (interpret: add mplace_to_ref helper method) - #114472 (Reword `confusable_idents` lint) - #114477 (Account for `Rc` and `Arc` when suggesting to clone) r? `@ghost` `@rustbot` modify labels: rollup
-
由 Matthias Krüger 提交于
Improve spans for indexing expressions fixes #114388 Indexing is similar to method calls in having an arbitrary left-hand-side and then something on the right, which is the main part of the expression. Method calls already have a span for that right part, but indexing does not. This means that long method chains that use indexing have really bad spans, especially when the indexing panics and that span in coverted into a panic location. This does the same thing as method calls for the AST and HIR, storing an extra span which is then put into the `fn_span` field in THIR. r? compiler-errors
-
由 bors 提交于
Lots of tiny incremental simplifications of `EmitterWriter` internals ignore the first commit, it's https://github.com/rust-lang/rust/pull/114088 squashed and rebased, but it's needed to use to use `derive_setters`, as they need a newer `syn` version. Then this PR starts out with removing many arguments that are almost always defaulted to `None` or `false` and replace them with builder methods that can set these fields in the few cases that want to set them. After that it's one commit after the other that removes or merges things until everything becomes some very simple trait objects
-
- 04 8月, 2023 5 次提交
-
-
由 Nilstrieb 提交于
Indexing is similar to method calls in having an arbitrary left-hand-side and then something on the right, which is the main part of the expression. Method calls already have a span for that right part, but indexing does not. This means that long method chains that use indexing have really bad spans, especially when the indexing panics and that span in coverted into a panic location. This does the same thing as method calls for the AST and HIR, storing an extra span which is then put into the `fn_span` field in THIR.
-
由 Matthias Krüger 提交于
Perform OpaqueCast field projection on HIR, too. fixes #105819 This is necessary for closure captures in 2021 edition, as they capture individual fields, not the full mentioned variables. So it may try to capture a field of an opaque (because the hidden type is known to be something with a field). See https://github.com/rust-lang/rust/pull/99806 for when and why we added OpaqueCast to MIR.
-
由 bors 提交于
Add `internal_features` lint Implements https://github.com/rust-lang/compiler-team/issues/596 Also requires some more test blessing for codegen tests etc `@jyn514` had the idea of just `allow`ing the lint by default in the test suite. I'm not sure whether this is a good idea, but it's definitely one worth considering. Additional input encouraged.
-
由 bors 提交于
Fix `suspicious_xor_used_as_pow.rs` performance The original `suspicious_xor_used_as_pow` lint had poor performance, so I fixed that + a little refactor so that module is readable. **107 millis. -> 106 millis.** Using `SPEEDTEST` on Rust's VMs fix #11060 changelog: [`suspicious_xor_used_as_pow`]: Improve performance by 0.934%
-
由 blyxyas 提交于
-
- 03 8月, 2023 2 次提交
-
-
由 Matthias Krüger 提交于
Expand, rename and improve `incorrect_fn_null_checks` lint This PR, - firstly, expand the lint by now linting on references - secondly, it renames the lint `incorrect_fn_null_checks` -> `useless_ptr_null_checks` - and thirdly it improves the lint by catching `ptr::from_mut`, `ptr::from_ref`, as well as `<*mut _>::cast` and `<*const _>::cast_mut` Fixes https://github.com/rust-lang/rust/issues/113601 cc ```@est31```
-
由 Nilstrieb 提交于
It lints against features that are inteded to be internal to the compiler and standard library. Implements MCP #596. We allow `internal_features` in the standard library and compiler as those use many features and this _is_ the standard library from the "internal to the compiler and standard library" after all. Marking some features as internal wasn't exactly the most scientific approach, I just marked some mostly obvious features. While there is a categorization in the macro, it's not very well upheld (should probably be fixed in another PR). We always pass `-Ainternal_features` in the testsuite About 400 UI tests and several other tests use internal features. Instead of throwing the attribute on each one, just always allow them. There's nothing wrong with testing internal features^^
-