about summary refs log tree commit diff
path: root/compiler/rustc_lint/src
AgeCommit message (Collapse)AuthorLines
2022-10-09`for_loop_over_fallibles`: don't use `MachineApplicable`Maybe Waffle-1/+1
The loop could contain `break;` that won't work with an `if let`
2022-10-09`for_loop_over_fallibles`: fix suggestion for "remove `.next()`" caseMaybe Waffle-1/+1
if the iterator is used after the loop, we need to use `.by_ref()`
2022-10-09`for_loop_over_fallibles`: remove duplication from the messageMaybe Waffle-3/+1
2022-10-09`for_loop_over_fallibles`: suggest using `?` in some casesMaybe Waffle-3/+65
2022-10-09`for_loop_over_fallibles`: suggest `while let` loopMaybe Waffle-0/+10
2022-10-09`for_loop_over_fallibles`: Suggest removing `.next()`Maybe Waffle-11/+38
2022-10-09Use structured suggestions for `for_loop_over_fallibles` lintMaybe Waffle-8/+14
2022-10-09Start uplifting `clippy::for_loops_over_fallibles`Maybe Waffle-0/+102
I refactored the code: - Removed handling of methods, as it felt entirely unnecessary - Removed clippy utils (obviously...) - Used some shiny compiler features (let-else is very handy for lints :eyes:) - I also renamed the lint to `for_loop_over_fallibles` (note: no `s`). I'm not sure what's the naming convention here, so maybe I'm wrong.
2022-10-07Auto merge of #102091 - RalfJung:const_err, r=oli-obkbors-0/+5
make const_err a hard error This lint has been deny-by-default with future incompat wording since [Rust 1.51](https://github.com/rust-lang/rust/pull/80394) and the stable release of this week starts showing it in cargo's future compat reports. I can't wait to finally get rid of at least some of the mess in our const-err-reporting-code. ;) r? `@oli-obk` Fixes https://github.com/rust-lang/rust/issues/71800 Fixes https://github.com/rust-lang/rust/issues/100114
2022-10-07make const_err a hard errorRalf Jung-0/+5
2022-10-07Change InferCtxtBuilder from enter to buildCameron Steffen-89/+83
2022-10-06Rollup merge of #102725 - nnethercote:rm-Z-time, r=davidtwcoMatthias Krüger-8/+11
Remove `-Ztime` Because it has a lot of overlap with `-Ztime-passes` but is generally less useful. Plus some related cleanups. Best reviewed one commit at a time. r? `@davidtwco`
2022-10-06Remove `-Ztime` option.Nicholas Nethercote-8/+11
The compiler currently has `-Ztime` and `-Ztime-passes`. I've used `-Ztime-passes` for years but only recently learned about `-Ztime`. What's the difference? Let's look at the `-Zhelp` output: ``` -Z time=val -- measure time of rustc processes (default: no) -Z time-passes=val -- measure time of each rustc pass (default: no) ``` The `-Ztime-passes` description is clear, but the `-Ztime` one is less so. Sounds like it measures the time for the entire process? No. The real difference is that `-Ztime-passes` prints out info about passes, and `-Ztime` does the same, but only for a subset of those passes. More specifically, there is a distinction in the profiling code between a "verbose generic activity" and an "extra verbose generic activity". `-Ztime-passes` prints both kinds, while `-Ztime` only prints the first one. (It took me a close reading of the source code to determine this difference.) In practice this distinction has low value. Perhaps in the past the "extra verbose" output was more voluminous, but now that we only print stats for a pass if it exceeds 5ms or alters the RSS, `-Ztime-passes` is less spammy. Also, a lot of the "extra verbose" cases are for individual lint passes, and you need to also use `-Zno-interleave-lints` to see those anyway. Therefore, this commit removes `-Ztime` and the associated machinery. One thing to note is that the existing "extra verbose" activities all have an extra string argument, so the commit adds the ability to accept an extra argument to the "verbose" activities.
2022-10-05Use proper subdiagnosticMichael Goulet-15/+9
2022-10-05Fix opaque_hidden_inferred_bound lint ICEMichael Goulet-18/+37
2022-10-04Rollup merge of #102568 - compiler-errors:lint-unsatisfied-opaques, r=oli-obkDylan DPC-0/+159
Lint against nested opaque types that don't satisfy associated type bounds See the test failures for examples of places where this lint would fire. r? `@oli-obk`
2022-10-04We are able to resolve methods even if they need substMichael Goulet-6/+0
2022-10-04Normalize substs before resolving instance in NoopMethodCall lintMichael Goulet-5/+6
2022-10-02Slightly tweak comments wrt `lint_overflowing_range_endpoint`Maybe Waffle-38/+40
2022-10-02Add example to opaque_hidden_inferred_bound lintMichael Goulet-6/+37
2022-10-02Make it a lint for all opaque typesMichael Goulet-146/+128
2022-10-02Lint for unsatisfied nested opaquesMichael Goulet-0/+146
2022-10-01Add sanity Drop impl.Camille GILLOT-0/+8
2022-10-01Add FIXME.Camille GILLOT-0/+1
2022-10-01Replace retain with assertion.Camille GILLOT-2/+6
2022-10-01Add fast path without visiting.Camille GILLOT-12/+30
2022-10-01Simplify LintLevelsProvider.Camille GILLOT-18/+16
2022-10-01Compute by owner instead of HirId.Camille GILLOT-16/+110
2022-10-01Add FIXME.Camille GILLOT-0/+2
2022-10-01Comment LintLevelSets.Camille GILLOT-1/+12
2022-10-01Move lint level computation to rustc_middle::lint.Camille GILLOT-26/+32
2022-10-01Reduce visibilities and remove dead code.Camille GILLOT-17/+15
2022-10-01Move code to rustc_lint.Camille GILLOT-2/+69
2022-10-01Remove unused tool_name.Camille GILLOT-4/+0
2022-10-01Compute `lint_levels` by definitionDeadbeef-280/+315
2022-10-01Auto merge of #101986 - WaffleLapkin:move_lint_note_to_the_bottom, r=estebankbors-955/+1105
Move lint level source explanation to the bottom So, uhhhhh r? `@estebank` ## User-facing change "note: `#[warn(...)]` on by default" and such are moved to the bottom of the diagnostic: ```diff - = note: `#[warn(unsupported_calling_conventions)]` on by default = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #87678 <https://github.com/rust-lang/rust/issues/87678> + = note: `#[warn(unsupported_calling_conventions)]` on by default ``` Why warning is enabled is the least important thing, so it shouldn't be the first note the user reads, IMO. ## Developer-facing change `struct_span_lint` and similar methods have a different signature. Before: `..., impl for<'a> FnOnce(LintDiagnosticBuilder<'a, ()>)` After: `..., impl Into<DiagnosticMessage>, impl for<'a, 'b> FnOnce(&'b mut DiagnosticBuilder<'a, ()>) -> &'b mut DiagnosticBuilder<'a, ()>` The reason for this is that `struct_span_lint` needs to edit the diagnostic _after_ `decorate` closure is called. This also makes lint code a little bit nicer in my opinion. Another option is to use `impl for<'a> FnOnce(LintDiagnosticBuilder<'a, ()>) -> DiagnosticBuilder<'a, ()>` altough I don't _really_ see reasons to do `let lint = lint.build(message)` everywhere. ## Subtle problem By moving the message outside of the closure (that may not be called if the lint is disabled) `format!(...)` is executed earlier, possibly formatting `Ty` which may call a query that trims paths that crashes the compiler if there were no warnings... I don't think it's that big of a deal, considering that we move from `format!(...)` to `fluent` (which is lazy by-default) anyway, however this required adding a workaround which is unfortunate. ## P.S. I'm sorry, I do not how to make this PR smaller/easier to review. Changes to the lint API affect SO MUCH 😢
2022-10-01`ui-fulldeps`: adopt to the new rustc lint APIMaybe Waffle-1/+1
2022-10-01Refactor rustc lint APIMaybe Waffle-955/+1105
2022-09-29Auto merge of #101887 - nnethercote:shrink-Res, r=spastorinobors-2/+2
Shrink `hir::def::Res` r? `@spastorino`
2022-09-29Use let-chaining in `WhileTrue::check_expr`.Nicholas Nethercote-24/+22
This has been bugging me for a while.
2022-09-29Shrink `hir::def::Res`.Nicholas Nethercote-2/+2
`Res::SelfTy` currently has two `Option`s. When the second one is `Some` the first one is never consulted. So we can split it into two variants, `Res::SelfTyParam` and `Res::SelfTyAlias`, reducing the size of `Res` from 24 bytes to 12. This then shrinks `hir::Path` and `hir::PathSegment`, which are the HIR types that take up the most space.
2022-09-27Rollup merge of #102281 - RalfJung:invalid-enums, r=cjgillotMatthias Krüger-51/+117
make invalid_value lint a bit smarter around enums Fixes https://github.com/rust-lang/rust/issues/102043
2022-09-27also query type_uninhabited_fromRalf Jung-3/+11
2022-09-26remove cfg(bootstrap)Pietro Albini-1/+1
2022-09-26make invalid_value lint a bit smarter around enumsRalf Jung-51/+109
2022-09-24separate definitions and `HIR` ownersTakayuki Maeda-15/+15
fix a ui test use `into` fix clippy ui test fix a run-make-fulldeps test implement `IntoQueryParam<DefId>` for `OwnerId` use `OwnerId` for more queries change the type of `ParentOwnerIterator::Item` to `(OwnerId, OwnerNode)`
2022-09-22Revert "Auto merge of #101620 - cjgillot:compute_lint_levels_by_def, r=oli-obk"Camille GILLOT-402/+286
This reverts commit 2cb9a65684dba47c52de8fa938febf97a73e70a9, reversing changes made to 750bd1a7ff3e010611b97ee75d30b7cbf5f3a03c.
2022-09-21FIX - adopt new Diagnostic naming in newly migrated modulesJhonny Bill Mena-2/+2
FIX - ambiguous Diagnostic link in docs UPDATE - rename diagnostic_items to IntoDiagnostic and AddToDiagnostic [Gardening] FIX - formatting via `x fmt` FIX - rebase conflicts. NOTE: Confirm wheather or not we want to handle TargetDataLayoutErrorsWrapper this way DELETE - unneeded allow attributes in Handler method FIX - broken test FIX - Rebase conflict UPDATE - rename residual _SessionDiagnostic and fix LintDiag link
2022-09-21UPDATE - rename SessionSubdiagnostic macro to SubdiagnosticJhonny Bill Mena-3/+3
Also renames: - sym::AddSubdiagnostic to sym:: Subdiagnostic - rustc_diagnostic_item = "AddSubdiagnostic" to rustc_diagnostic_item = "Subdiagnostic"
2022-09-21UPDATE - rename DiagnosticHandler macro to DiagnosticJhonny Bill Mena-11/+11