about summary refs log tree commit diff
path: root/src/test/ui/lint
AgeCommit message (Collapse)AuthorLines
2022-06-09Use `multipart_suggestion` to create an applicable suggestion.Aaron Kofsky-4/+4
The "consider explicitly droping" can now suggest a machine applicable suggestion now.
2022-06-06Auto merge of #97795 - Dylan-DPC:rollup-dxilagr, r=Dylan-DPCbors-0/+156
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
2022-06-06Rollup merge of #97495 - clarfonthey:e0788-no-coverage, r=nagisaDylan DPC-0/+156
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.
2022-06-06Auto merge of #97086 - 5225225:link-section-is-unsafe, r=davidtwcobors-16/+35
Report unsafe for overriding link sections I'm not too sure about the lint wording here, but I couldn't think of anything better.
2022-06-05Changes from code reviewltdk-19/+46
2022-06-05Add diagnostic items to MutexGuard and RwLock GuardsAaron Kofsky-1/+1
I forgot to add the diagnostic to the actual types in `std` earlier.
2022-06-05Remove `let_underscore_must_use`Aaron Kofsky-46/+0
The `let_underscore_must_use` lint was really only added because clippy included it, but it doesn't actually seem very useful.
2022-06-04Use `check-pass` instead of `run-pass`Aaron Kofsky-2/+3
We don't actually care about running these programs, only checking the warnings they generate.
2022-06-04Move `let_underscore` tests into the `lint` subfolder.Aaron Kofsky-0/+102
2022-06-04Support the `#[expect]` attribute on fn parameters (RFC-2383)xFrednet-0/+25
2022-06-04Fix `delayed_good_path_bug` ice for expected diagnostics (RFC 2383)xFrednet-0/+8
2022-06-03Auto merge of #96296 - cjgillot:remove-label-lt-shadow, r=petrochenkovbors-9/+9
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
2022-06-02Stop warning against unrelated labels.Camille GILLOT-13/+3
2022-06-02Bless tests.Camille GILLOT-12/+22
2022-06-02don't use a `span_note` for ignored implslcnr-6/+1
2022-05-28Add E0788 for improper #[no_coverage] usageltdk-0/+129
2022-05-28Make some tests check-passYuki Okushi-7/+5
2022-05-25Tweak memory ordering diagnostic.Mara Bos-36/+18
2022-05-25Update tests.Mara Bos-180/+216
2022-05-24Emit weird lint name lints after expansionest31-8/+173
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.
2022-05-21Remove `crate` visibility modifier in libs, testsJacob Pratt-272/+49
2022-05-20Do not warn on inherent doc(hidden) assoc itemsLeón Orell Valerian Liehr-9/+35
2022-05-16Report unsafe for overriding link sections5225225-16/+35
2022-05-12Auto merge of #96150 - est31:unused_macro_rules, r=petrochenkovbors-43/+195
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
2022-05-10Add regression test for #68408Yuki Okushi-0/+22
2022-05-09Rollup merge of #96008 - ↵Matthias Krüger-0/+151
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
2022-05-08Warn on unused doc(hidden) on trait impl itemsLeón Orell Valerian Liehr-0/+151
2022-05-08Test `expect` attribute for tool lints, rustc edition (RFC 2383)xFrednet-0/+171
2022-05-08Only assert for unstable expectation ids after conversion (RFC 2383)xFrednet-0/+36
This ICE was reported by `@matthiaskrgr`. A big THANK YOU to him. See `rust#94953`
2022-05-05Add testsest31-43/+195
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.
2022-04-23Fix lints.Camille GILLOT-18/+28
2022-04-22Auto merge of #96144 - c410-f3r:z-errors, r=petrochenkovbors-0/+80
Move some tests to more reasonable places cc #73494 r? `@petrochenkov`
2022-04-21Move some tests to more reasonable directoriesCaio-0/+80
2022-04-17Auto merge of #95779 - cjgillot:ast-lifetimes-undeclared, r=petrochenkovbors-8/+10
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`
2022-04-17Lint elided lifetimes in path on the AST.Camille GILLOT-8/+10
2022-04-17Auto merge of #96010 - eduardosm:Unique-on-top-of-NonNull, r=m-ou-se,tmiaskobors-16/+6
Implement `core::ptr::Unique` on top of `NonNull` Removes the use `rustc_layout_scalar_valid_range_start` and some `unsafe` blocks.
2022-04-17Rollup merge of #96112 - niluxv:strict-provenance-lint-improvements, r=nagisaDylan DPC-4/+39
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
2022-04-16Improve `fuzzy_provenance_casts` lint diagnosticsniluxv-1/+1
Use `multipart_suggestion` instead of getting a snippet.
2022-04-16Improve `lossy_provenance_casts` lint diagnosticsniluxv-3/+38
Use `multipart_suggestion` and don't suggested unnecessary parenthesis.
2022-04-16Rollup merge of #95372 - RalfJung:unaligned_references, r=oli-obkDylan DPC-0/+149
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.
2022-04-14make unaligned_reference warning visible in future compat reportRalf Jung-0/+149
2022-04-14`Unique<T>` is now considered FFI-safeEduardo Sánchez Muñoz-16/+6
2022-04-12Rollup merge of #95910 - ehuss:fix-crate-type-duplicate, r=Dylan-DPCMatthias Krüger-60/+44
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
2022-04-10Fix crate_type attribute to not warn on duplicatesEric Huss-60/+44
2022-04-09Fix missing space in lossy provenance cast lintniluxv-2/+2
2022-04-08Split `fuzzy_provenance_casts` into lossy and fuzzy, feature gate and test itniluxv-0/+60
* split `fuzzy_provenance_casts` into a ptr2int and a int2ptr lint * feature gate both lints * update documentation to be more realistic short term * add tests for these lints
2022-04-01invalid_value lint: detect invalid initialization of arraysRalf Jung-11/+52
2022-03-28Revert "Auto merge of #93893 - oli-obk:sad_revert, r=oli-obk"Oli Scherer-14/+16
This reverts commit 6499c5e7fc173a3f55b7a3bd1e6a50e9edef782d, reversing changes made to 78450d2d602b06d9b94349aaf8cece1a4acaf3a8.
2022-03-20Filter OnceNote in diagnostic infra.Camille GILLOT-25/+0
2022-03-15Rollup merge of #94947 - Dylan-DPC:fix/typos, r=oli-obkMatthias Krüger-1/+1
fix typos Rework of #94603 which got closed as I was trying to unmerge and repush. This is a subset of changes from the original pr as I sed'd whatever typos I remembered from the original PR thanks to `@cuishuang` for the original PR