| Age | Commit message (Collapse) | Author | Lines |
|---|
|
r=estebank
Collapse multiple dead code warnings into a single diagnostic
closes #97643
|
|
Remove the unused-`#[doc(hidden)]` logic from the `unused_attributes` lint
Fixes #96890.
It was found out that `#[doc(hidden)]` on trait impl items does indeed have an effect on the generated documentation (see the linked issue). In my opinion and the one of [others](https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/Validy.20checks.20for.20.60.23.5Bdoc.28hidden.29.5D.60/near/281846219), rustdoc's output is actually a bit flawed in that regard but that should be tracked in a new issue I suppose (I will open an issue for that in the near future).
The check was introduced in #96008 which is marked to be part of version `1.62` (current `beta`). As far as I understand, this means that **this PR needs to be backported** to `beta` to fix #96890 on time. Correct me if I am wrong.
CC `@dtolnay` (in case you would like to agree or disagree with my decision to fully remove this check)
`@rustbot` label A-lint T-compiler T-rustdoc
r? `@rust-lang/compiler`
|
|
|
|
|
|
add comments in `store_dead_field_or_variant`
support multiple log level
add a item ident label
fix ui tests
fix a ui test
fix a rustdoc ui test
use let chain
refactor: remove `store_dead_field_or_variant`
fix a tiny bug
|
|
|
|
|
|
r=wesleywiser,flip1995
Support lint expectations for `--force-warn` lints (RFC 2383)
Rustc has a `--force-warn` flag, which overrides lint level attributes and forces the diagnostics to always be warn. This means, that for lint expectations, the diagnostic can't be suppressed as usual. This also means that the expectation would not be fulfilled, even if a lint had been triggered in the expected scope.
This PR now also tracks the expectation ID in the `ForceWarn` level. I've also made some minor adjustments, to possibly catch more bugs and make the whole implementation more robust.
This will probably conflict with https://github.com/rust-lang/rust/pull/97718. That PR should ideally be reviewed and merged first. The conflict itself will be trivial to fix.
---
r? `@wesleywiser`
cc: `@flip1995` since you've helped with the initial review and also discussed this topic with me. :upside_down_face:
Follow-up of: https://github.com/rust-lang/rust/pull/87835
Issue: https://github.com/rust-lang/rust/issues/85549
Yeah, and that's it.
|
|
|
|
Never regard macro rules with compile_error! invocations as unused
The very point of compile_error! is to never be reached, and one of
the use cases of the macro, currently also listed as examples in the
documentation of compile_error, is to create nicer errors for wrong
macro invocations. Thus, we should never warn about unused macro arms
that contain invocations of compile_error.
See also https://github.com/rust-lang/rust/pull/96150#issuecomment-1126599107 and the discussion after that.
Furthermore, the PR also contains two commits to silence `unused_macro_rules` when a macro has an invalid rule, and to add a test that `unused_macros` does not behave badly in the same situation.
r? `@petrochenkov` as I've talked to them about this
|
|
r=wesleywiser
Fix `delayed_good_path_bug` ice for expected diagnostics (RFC 2383)
Fixes a small ICE with the `delayed_good_path_bug` check.
---
r? ``@wesleywiser``
cc: ``@eddyb`` this might be interesting, since you've added a `FIXME` comment above the modified check which kind of discusses a case like this
closes: https://github.com/rust-lang/rust/issues/95540
cc: https://github.com/rust-lang/rust/issues/85549
|
|
The unused_macro_rules lint had a bug where it would regard all rules of
a macro as unused if one rule were malformed. This bug doesn't exist
with the unused_macros lint. To ensure it doesn't appear in the future,
we add a test for it.
|
|
Prior to this commit, if a macro had any malformed rules, all rules would
be reported as unused, regardless of whether they were used or not.
So we just turn off unused rule checking completely for macros with
malformed rules.
|
|
The very point of compile_error! is to never be reached, and one of
the use cases of the macro, currently also listed as examples in the
documentation of compile_error, is to create nicer errors for wrong
macro invocations. Thus, we shuuld never warn about unused macro arms
that contain invocations of compile_error.
|
|
Rollup of 5 pull requests
Successful merges:
- #97312 (Compute lifetimes in scope at diagnostic time)
- #97495 (Add E0788 for improper #[no_coverage] usage)
- #97579 (Avoid creating `SmallVec`s in `global_llvm_features`)
- #97767 (interpret: do not claim UB until we looked more into variadic functions)
- #97787 (E0432: rust 2018 -> rust 2018 or later in --explain message)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Add E0788 for improper #[no_coverage] usage
Essentially, this adds proper checking for the attribute (tracking issue #84605) and throws errors when it's put in obviously-wrong places, like on struct or const definitions. Most of the code is taken directly from the checks for the `#[inline]` attribute, since it's very similar.
Right now, the code only checks at the function level, but it seems reasonable to allow adding `#[no_coverage]` to individual blocks or expressions, so, for now those just throw `unused_attributes` warnings. Similarly, since there was a lot of desire to eventually allow recursive definitions as well on modules and impl blocks, these also throw `unused_attributes` instead of an error.
I'm not sure if anything has to be done since this error is technically for an unstable feature, but since an error for using unstable features will show up anyway, I think it's okay.
This is the first big piece needed for stabilising this attribute, although I personally would like to explore renaming it to `#[coverage(never)]` on a separate PR, which I will offer soon. There's a lot of discussion still to be had about that, which is why it will be kept separate.
I don't think much is needed besides adding this simple check and a UI test, but let me know if there's something else that should be added to make this happen.
|
|
Report unsafe for overriding link sections
I'm not too sure about the lint wording here, but I couldn't think of anything better.
|
|
|
|
|
|
|
|
Remove label/lifetime shadowing warnings
This PR removes some pre-1.0 shadowing warnings for labels and lifetimes.
The current behaviour of the compiler is to warn
* labels that shadow unrelated labels in the same function --> removed
```rust
'a: loop {}
'a: loop {} // STOP WARNING
```
* labels that shadow enclosing labels --> kept, but only if shadowing is hygienic
```rust
'a: loop {
'a: loop {} // KEEP WARNING
}
```
* labels that shadow lifetime --> removed
```rust
fn foo<'a>() {
'a: loop {} // STOP WARNING
}
```
* lifetimes that shadow labels --> removed
```rust
'a: loop {
let b = Box::new(|x: &i8| *x) as Box<dyn for <'a> Fn(&'a i8) -> i8>; // STOP WARNING
}
```
* lifetimes that shadow lifetimes --> kept
```rust
fn foo<'a>() {
let b = Box::new(|x: &i8| *x) as Box<dyn for <'a> Fn(&'a i8) -> i8>; // KEEP WARNING
}
```
Closes https://github.com/rust-lang/rust/issues/31745.
-----
From `@petrochenkov` in https://github.com/rust-lang/rust/pull/95781#issuecomment-1105199014
> I think we should remove these silly checks entirely.
> They were introduced long time ago in case some new language features appear and require this space.
> Now we have another mechanism for such language changes - editions, and if "lifetimes in expressions" or something like that needs to be introduced it could be introduced as an edition change.
> However, there was no plans to introduce anything like for years, so it's unlikely that even the edition mechanism will be necessary.
r? rust-lang/lang
|
|
|
|
|
|
|
|
|
|
|
|
Previously, we were emitting weird name lints (for renamed or unknown lints)
before expansion, most importantly before cfg expansion.
This meant that the weird name lints would not fire
for lint attributes hidden inside cfg_attr. The same applied
for lint level specifications of those lints.
By moving the lints for the lint names to the post-expansion
phase, these issues are resolved.
|
|
|
|
|
|
|
|
Implement a lint to warn about unused macro rules
This implements a new lint to warn about unused macro rules (arms/matchers), similar to the `unused_macros` lint added by #41907 that warns about entire macros.
```rust
macro_rules! unused_empty {
(hello) => { println!("Hello, world!") };
() => { println!("empty") }; //~ ERROR: 1st rule of macro `unused_empty` is never used
}
fn main() {
unused_empty!(hello);
}
```
Builds upon #96149 and #96156.
Fixes #73576
|
|
|
|
fmease:warn-on-useless-doc-hidden-on-assoc-impl-items, r=lcnr
Warn on unused `#[doc(hidden)]` attributes on trait impl items
[Zulip conversation](https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/.E2.9C.94.20Validy.20checks.20for.20.60.23.5Bdoc.28hidden.29.5D.60).
Whether an associated item in a trait impl is shown or hidden in the documentation entirely depends on the corresponding item in the trait declaration. Rustdoc completely ignores `#[doc(hidden)]` attributes on impl items. No error or warning is emitted:
```rust
pub trait Tr { fn f(); }
pub struct Ty;
impl Tr for Ty { #[doc(hidden)] fn f() {} }
// ^^^^^^^^^^^^^^ ignored by rustdoc and currently
// no error or warning issued
```
This may lead users to the wrong belief that the attribute has an effect. In fact, several such cases are found in the standard library (I've removed all of them in this PR).
There does not seem to exist any incentive to allow this in the future either: Impl'ing a trait for a type means the type *fully* conforms to its API. Users can add `#[doc(hidden)]` to the whole impl if they want to hide the implementation or add the attribute to the corresponding associated item in the trait declaration to hide the specific item. Hiding an implementation of an associated item does not make much sense: The associated item can still be found on the trait page.
This PR emits the warn-by-default lint `unused_attribute` for this case with a future-incompat warning.
`@rustbot` label T-compiler T-rustdoc A-lint
|
|
|
|
|
|
This ICE was reported by `@matthiaskrgr`. A big THANK YOU to him. See `rust#94953`
|
|
Also rename the test files for the unused_macros lint to avoid confusion.
The test files now follow a <lint_name><-maybe-decl>.rs scheme.
|
|
|
|
Move some tests to more reasonable places
cc #73494
r? `@petrochenkov`
|
|
|
|
Report undeclared lifetimes during late resolution.
First step in https://github.com/rust-lang/rust/pull/91557
We reuse the rib design of the current resolution framework. Specific `LifetimeRib` and `LifetimeRibKind` types are introduced. The most important variant is `LifetimeRibKind::Generics`, which happens each time we encounter something which may introduce generic lifetime parameters. It can be an item or a `for<...>` binder. The `LifetimeBinderKind` specifies how this rib behaves with respect to in-band lifetimes.
r? `@petrochenkov`
|
|
|
|
Implement `core::ptr::Unique` on top of `NonNull`
Removes the use `rustc_layout_scalar_valid_range_start` and some `unsafe` blocks.
|
|
Strict provenance lint diagnostics improvements
Use `multipart_suggestion` instead of `span_suggestion` and getting a snippet for the expression. Also don't suggest unnecessary parenthesis in `lossy_provenance_casts`.
cc ``@estebank``
``@rustbot`` label A-diagnostics
|
|
Use `multipart_suggestion` instead of getting a snippet.
|
|
Use `multipart_suggestion` and don't suggested unnecessary parenthesis.
|
|
make unaligned_references lint deny-by-default
This lint has been warn-by-default for a year now (since https://github.com/rust-lang/rust/pull/82525), so I think it is time to crank it up a bit. Code that triggers the lint causes UB (without `unsafe`) when executed, so we really don't want people to write code like this.
|
|
|
|
|
|
Fix crate_type attribute to not warn on duplicates
In #88681 I accidentally marked the `crate_type` attribute as only allowing a single attribute. However, multiple attributes are allowed (they are joined together [here](https://github.com/rust-lang/rust/blob/027a232755fa9728e9699337267f6675dfd0a8ba/compiler/rustc_interface/src/util.rs#L530-L542)). This fixes it to not report a warning if duplicates are found.
Closes #95902
|
