| Age | Commit message (Collapse) | Author | Lines |
|---|
|
- remove unused (pun intentional) `continue`
- improve wording with assoc items in general
|
|
|
|
with repect to other dead code lints
|
|
Rollup of 8 pull requests
Successful merges:
- #110153 (Fix typos in compiler)
- #110165 (rustdoc: use CSS `overscroll-behavior` instead of JavaScript)
- #110175 (Symbol cleanups)
- #110203 (Remove `..` from return type notation)
- #110205 (rustdoc: make settings radio and checks thicker, less contrast)
- #110222 (Improve the error message when forwarding a matched fragment to another macro)
- #110237 (Split out a separate feature gate for impl trait in associated types)
- #110241 (tidy: Issue an error when UI test limits are too high)
Failed merges:
- #110218 (Remove `ToRegionVid`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Add regression test for #59003
Closes #59003
r? compiler-errors
|
|
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
|
|
|
|
|
|
diagnostics: account for glob shadowing when linting redundant imports
Fixes #92904
|
|
Co-Authored-By: Vadim Petrochenkov <vadim.petrochenkov@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
r=cjgillot
Add `useless_anonymous_reexport` lint
This is a follow-up of https://github.com/rust-lang/rust/pull/108936. We once again show all anonymous re-exports in rustdoc, however we also wanted to add a lint to let users know that it very likely doesn't have the effect they think it has.
|
|
error-msg: expand suggestion for `unused_def` lint
Fixes #108885
Expands `let _ = ..` suggestion into more positions.
|
|
|
|
|
|
|
|
|
|
Make `unused_allocation` lint against `Box::new` too
Previously it only linted against `box` syntax, which likely won't ever be stabilized, which is pretty useless. Even now I'm not sure if it's a meaningful lint, but it's at least something :shrug:
This means that code like the following will be linted against:
```rust
Box::new([1, 2, 3]).len();
f(&Box::new(1)); // where f : &i32 -> ()
```
The lint works by checking if a `Box::new` (or `box`) expression has an a borrow adjustment, meaning that the code that first stores the box in a variable won't be linted against:
```rust
let boxed = Box::new([1, 2, 3]); // no lint
boxed.len();
```
|
|
|
|
|
|
(how come we didn't have one already??)
|
|
Exit when there are unmatched delims to avoid noisy diagnostics
From https://github.com/rust-lang/rust/pull/104012#issuecomment-1311764832
r? ``@petrochenkov``
|
|
|
|
|
|
|
|
|
|
|
|
r=compiler-errors,davidtwco,estebank,oli-obk
diagnostics: if AssocFn has self argument, describe as method
Discussed in https://rust-lang.zulipchat.com/#narrow/stream/147480-t-compiler.2Fwg-diagnostics/topic/.22associated.20function.22.20vs.20.22method.22/near/329265515
This commit also changes the tooltips on rustdoc intra-doc links targeting methods.
For anyone not sure why this is being done, see the Reference definitions of these terms in <https://doc.rust-lang.org/1.67.1/reference/items/associated-items.html#methods>
> Associated functions whose first parameter is named `self` are called methods and may be invoked using the [method call operator](https://doc.rust-lang.org/1.67.1/reference/expressions/method-call-expr.html), for example, `x.foo()`, as well as the usual function call notation.
In particular, while this means it's technically correct for rustc to refer to a method as an associated function (and there are a few cases where it'll still do so), rustc *must never* use the term "method" to refer to an associated function that does not have a `self` parameter.
|
|
|
|
|
|
lint: don't suggest MaybeUninit::assume_init for uninhabited types
Creating a zeroed uninhabited type such as `!` or an empty enum with `mem::zeroed()` (or transmuting `()` to `!`) currently triggers this lint:
```rs
warning: the type `!` does not permit zero-initialization
--> test.rs:5:23
|
5 | let _val: ! = mem::zeroed();
| ^^^^^^^^^^^^^
| |
| this code causes undefined behavior when executed
| help: use `MaybeUninit<T>` instead, and only call `assume_init` after initialization is done
|
= note: the `!` type has no valid value
```
The `MaybeUninit` suggestion in the help message seems confusing/useless for uninhabited types, as such a type cannot be fully initialized in the first place (as the note implies).
This PR limits this help message to inhabited types which can be initialized
|
|
Properly check for builtin derived code
Fixes #108122
|
|
|
|
|
|
|
|
|
|
Support `true` and `false` as boolean flag params
Implements [MCP 577](https://github.com/rust-lang/compiler-team/issues/577).
|
|
Add explanatory message for [#must_use] in ops
Fixes #103320
|
|
Emit warnings on unused parens in index expressions
Fixes: #96606.
I am not sure what the best term for "index expression" is. Is there a better term we could use?
|
|
|
|
|
|
|
|
The previous output was unintuitive to users.
|
