about summary refs log tree commit diff
path: root/compiler/rustc_lint/src
AgeCommit message (Collapse)AuthorLines
2021-01-13Auto merge of #79322 - jyn514:refactor-impl, r=estebankbors-1/+1
Separate out a `hir::Impl` struct This makes it possible to pass the `Impl` directly to functions, instead of having to pass each of the many fields one at a time. It also simplifies matches in many cases. See `rustc_save_analysis::dump_visitor::process_impl` or `rustdoc::clean::clean_impl` for a good example of how this makes `impl`s easier to work with. r? `@petrochenkov` maybe?
2021-01-12Separate out a `hir::Impl` structJoshua Nelson-1/+1
This makes it possible to pass the `Impl` directly to functions, instead of having to pass each of the many fields one at a time. It also simplifies matches in many cases.
2021-01-11Rename `rustc_middle::lint::LevelSource` to `LevelAndSource`pierwill-3/+3
2021-01-12Add FIXME note about storing &'tcx strjumbatm-0/+5
2021-01-12Remove unnecessary allocation.jumbatm-4/+4
2021-01-12Use tcx.symbol_name to check for clashes.jumbatm-7/+9
2021-01-10Auto merge of #79414 - ↵bors-0/+3
sasurau4:feature/add-suggestion-for-pattern-in-fns-without-body, r=matthewjasper Add suggestion for PATTERNS_IN_FNS_WITHOUT_BODY ## Overview Fix #78927
2021-01-03Rollup merge of #80628 - matthiaskrgr:match_ref_pats, r=varkorGuillaume Gomez-7/+7
reduce borrowing and (de)referencing around match patterns (clippy::match_ref_pats)
2021-01-02reduce borrowing and (de)referencing around match patterns ↵Matthias Krüger-7/+7
(clippy::match_ref_pats)
2021-01-02Add snake case lint note about keyword identifiers which cannot be rawSkynoodle-0/+1
2021-01-01Add suggestion to use raw identifiers when fixing snake-case lintsSkynoodle-2/+16
2020-12-31Auto merge of #80500 - jyn514:track-caller, r=nagisabors-0/+1
Add `#[track_caller]` to `bug!` and `register_renamed` Before: ``` thread 'rustc' panicked at 'compiler/rustc_lint/src/context.rs:267:18: invalid lint renaming of broken_intra_doc_links to rustdoc::broken_intra_doc_links', compiler/rustc_middle/src/util/bug.rs:34:26 ``` After: ``` thread 'rustc' panicked at 'src/librustdoc/core.rs:455:24: invalid lint renaming of broken_intra_doc_links to rustdoc::broken_intra_doc_links', compiler/rustc_middle/src/util/bug.rs:35:26 ``` The reason I added it to `register_renamed` too is that any panic in that function will be the caller's fault.
2020-12-30Rollup merge of #80495 - jyn514:rename-empty, r=petrochenkovMara Bos-2/+2
Rename kw::Invalid -> kw::Empty See https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Is.20there.20a.20symbol.20for.20the.20empty.20string.3F/near/220054471 for context. r? `@petrochenkov`
2020-12-30Rename kw::Invalid -> kw::EmptyJoshua Nelson-2/+2
See https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Is.20there.20a.20symbol.20for.20the.20empty.20string.3F/near/220054471 for context.
2020-12-29Add `#[track_caller]` to `bug!` and `register_renamed`Joshua Nelson-0/+1
Before: ``` thread 'rustc' panicked at 'compiler/rustc_lint/src/context.rs:267:18: invalid lint renaming of broken_intra_doc_links to rustdoc::broken_intra_doc_links', compiler/rustc_middle/src/util/bug.rs:34:26 ``` After: ``` thread 'rustc' panicked at 'src/librustdoc/core.rs:455:24: invalid lint renaming of broken_intra_doc_links to rustdoc::broken_intra_doc_links', compiler/rustc_middle/src/util/bug.rs:35:26 ``` The reason I added it to `register_renamed` too is that any panic in that function will be the caller's fault.
2020-12-29Lint on redundant trailing semicolon after itemAaron Hill-17/+3
We now lint on code like this: ```rust fn main() { fn foo() {}; struct Bar {}; } ``` Previously, this caused warnings in Cargo, so it was disabled.
2020-12-26stabilize min_const_genericsBastian Kauschke-1/+1
2020-12-25Rollup merge of #80274 - pierwill:lintlevelsource, r=petrochenkovDylan DPC-10/+12
Rename rustc_middle::lint::LintSource Rename [`rustc_middle::lint::LintSource`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/lint/enum.LintSource.html) to `rustc_middle::lint::LintLevelSource`. This enum represents the source of a *lint level*, not a lint. This should improve code readability. Update: Also documents `rustc_middle::lint::LevelSource` to clarify.
2020-12-22Auto merge of #78242 - Nadrieril:rename-overlapping_endpoints-lint, r=varkorbors-1/+1
Rename `overlapping_patterns` lint As discussed in https://github.com/rust-lang/rust/issues/65477. I also tweaked a few things along the way. r? `@varkor` `@rustbot` modify labels: +A-exhaustiveness-checking
2020-12-21Document rustc_middle::lint::LevelSourcepierwill-1/+3
This is to clarify the difference between `LevelSource` and `LintLevelSource`. Appease x.py fmt.
2020-12-21Rename rustc_middle::lint::LintSourcepierwill-10/+10
Rename rustc_middle::lint::LintSource to rustc_middle::lint::LintLevelSource.
2020-12-21add suggest for PatternsInWithoutBodyDaiki Ihara-0/+3
2020-12-12Add 'consider using' message to overflowing_literalsCamelid-12/+17
Ironically, the overflowing_literals handler for binary or hex already had this message! You would think it would be the other way around :)
2020-12-11Move binder for dyn to each list itemJack Huey-3/+5
2020-12-10Types with a hidden niche are not known to be non-nullTomasz Miąsko-1/+7
2020-12-08don't create owned values for comparison (clippy::cmp_owned)Matthias Krüger-3/+3
2020-12-03Only deny doc_keyword in std and set it as "allow" by defaultGuillaume Gomez-1/+1
2020-12-03Add lint pass for doc keywordGuillaume Gomez-1/+48
2020-12-02Auto merge of #78864 - Mark-Simulacrum:warn-on-forbids, r=pnkfelixbors-49/+21
Use true previous lint level when detecting overriden forbids Previously, cap-lints was ignored when checking the previous forbid level, which meant that it was a hard error to do so. This is different from the normal behavior of lints, which are silenced by cap-lints; if the forbid would not take effect regardless, there is not much point in complaining about the fact that we are reducing its level. It might be considered a bug that even `--cap-lints deny` would suffice to silence the error on overriding forbid, depending on if one cares about failing the build or precisely forbid being set. But setting cap-lints to deny is quite odd and not really done in practice, so we don't try to handle it specially. This also unifies the code paths for nested and same-level scopes. However, the special case for CLI lint flags is left in place (introduced by #70918) to fix the regression noted in #70819. That means that CLI flags do not lint on forbid being overridden by a non-forbid level. It is unclear whether this is a bug or a desirable feature, but it is certainly inconsistent. CLI flags are a sufficiently different "type" of place though that this is deemed out of scope for this commit. r? `@pnkfelix` perhaps? cc #77713 -- not marking as "Fixes" because of the lack of proper unused attribute handling in this PR
2020-11-29`overlapping_range_endpoints` does not belong in the `unused` lint groupNadrieril-1/+0
2020-11-29Rename the `overlapping_patterns` lint to `overlapping_range_endpoints`Nadrieril-1/+2
2020-11-28Cleanup: shorter and faster codeAleksey Kladov-2/+2
2020-11-27Don't lint on redundant semicolons after item statementsAaron Hill-3/+18
This preserves the current lint behavior for now. Linting after item statements currently prevents the compiler from bootstrapping. Fixing this is blocked on fixing this upstream in Cargo, and bumping the Cargo submodule.
2020-11-26Fix new 'unnecessary trailing semicolon' warningsAaron Hill-2/+2
2020-11-24Move lev_distance to rustc_ast, make non-genericArlie Davis-2/+2
rustc_ast currently has a few dependencies on rustc_lexer. Ideally, an AST would not have any dependency its lexer, for minimizing unnecessarily design-time dependencies. Breaking this dependency would also have practical benefits, since modifying rustc_lexer would not trigger a rebuild of rustc_ast. This commit does not remove the rustc_ast --> rustc_lexer dependency, but it does remove one of the sources of this dependency, which is the code that handles fuzzy matching between symbol names for making suggestions in diagnostics. Since that code depends only on Symbol, it is easy to move it to rustc_span. It might even be best to move it to a separate crate, since other tools such as Cargo use the same algorithm, and have simply contain a duplicate of the code. This changes the signature of find_best_match_for_name so that it is no longer generic over its input. I checked the optimized binaries, and this function was duplicated at nearly every call site, because most call sites used short-lived iterator chains, generic over Map and such. But there's no good reason for a function like this to be generic, since all it does is immediately convert the generic input (the Iterator impl) to a concrete Vec<Symbol>. This has all of the costs of generics (duplicated method bodies) with no benefit. Changing find_best_match_for_name to be non-generic removed about 10KB of code from the optimized binary. I know it's a drop in the bucket, but we have to start reducing binary size, and beginning to tame over-use of generics is part of that.
2020-11-21More consistently use spaces after commas in lists in docsCarol (Nichols || Goulding)-1/+1
2020-11-21Auto merge of #77805 - JohnTitor:non-standard-char-sugg, r=Dylan-DPCbors-19/+35
lint: Do not provide suggestions for non standard characters Fixes #77273 Only provide suggestions if the case-fixed result is different than the original.
2020-11-14Use true previous lint level when detecting overriden forbidsMark Rousskov-49/+21
Previously, cap-lints was ignored when checking the previous forbid level, which meant that it was a hard error to do so. This is different from the normal behavior of lints, which are silenced by cap-lints; if the forbid would not take effect regardless, there is not much point in complaining about the fact that we are reducing its level. It might be considered a bug that even `--cap-lints deny` would suffice to silence the error on overriding forbid, depending on if one cares about failing the build or precisely forbid being set. But setting cap-lints to deny is quite odd and not really done in practice, so we don't try to handle it specially. This also unifies the code paths for nested and same-level scopes. However, the special case for CLI lint flags is left in place (introduced by #70918) to fix the regression noted in #70819. That means that CLI flags do not lint on forbid being overridden by a non-forbid level. It is unclear whether this is a bug or a desirable feature, but it is certainly inconsistent. CLI flags are a sufficiently different "type" of place though that this is deemed out of scope for this commit.
2020-11-09Rollup merge of #78710 - petrochenkov:macvisit, r=davidtwcoDylan DPC-8/+2
rustc_ast: Do not panic by default when visiting macro calls Panicking by default made sense when we didn't have HIR or MIR and everything worked on AST, but now all AST visitors run early and majority of them have to deal with macro calls, often by ignoring them. The second commit renames `visit_mac` to `visit_mac_call`, the corresponding structures were renamed earlier in https://github.com/rust-lang/rust/pull/69589.
2020-11-05Rename lint to non_autolinksGuillaume Gomez-2/+2
2020-11-05Rename automatic_links to url_improvementsGuillaume Gomez-3/+3
2020-11-05Add new lint for automatic_links improvementsGuillaume Gomez-1/+2
2020-11-04`u128` truncation and sign extension are not just interpreter relatedoli-3/+2
2020-11-03rustc_ast: `visit_mac` -> `visit_mac_call`Vadim Petrochenkov-1/+1
2020-11-03rustc_ast: Do not panic by default when visiting macro callsVadim Petrochenkov-7/+1
2020-11-03Rollup merge of #78663 - Aaron1011:fix/cap-future-compat, r=tmandryYuki Okushi-4/+5
Fix ICE when a future-incompat-report has its command-line level capped Fixes #78660 With PR https://github.com/rust-lang/rust/pull/75534 merged, we now run more lint-related code for future-incompat-report, even when their final level is Allow. Some lint-related code was not expecting `Level::Allow`, and had an explicit panic. This PR explicitly tracks the lint level set on the command line before `--cap-lints` is applied. This is used to emit a more precise error note (e.g. we don't say that `-W lint-name` was specified on the command line just because a lint was capped to Warn). As a result, we can now correctly emit a note that `-A` was used if we got `Level::Allow` from the command line (before the cap is applied).
2020-11-02Treat trailing semicolon as a statement in macro callAaron Hill-0/+5
See https://github.com/rust-lang/rust/issues/61733#issuecomment-716188981 We now preserve the trailing semicolon in a macro invocation, even if the macro expands to nothing. As a result, the following code no longer compiles: ```rust macro_rules! empty { () => { } } fn foo() -> bool { //~ ERROR mismatched { true } //~ ERROR mismatched empty!(); } ``` Previously, `{ true }` would be considered the trailing expression, even though there's a semicolon in `empty!();` This makes macro expansion more token-based.
2020-11-02Fix ICE when a future-incompat-report has its command-line level cappedAaron Hill-4/+5
Fixes #78660 With PR https://github.com/rust-lang/rust/pull/75534 merged, we now run more lint-related code for future-incompat-report, even when their final level is Allow. Some lint-related code was not expecting `Level::Allow`, and had an explicit panic. This PR explicitly tracks the lint level set on the command line before `--cap-lints` is applied. This is used to emit a more precise error note (e.g. we don't say that `-W lint-name` was specified on the command line just because a lint was capped to Warn). As a result, we can now correctly emit a note that `-A` was used if we got `Level::Allow` from the command line (before the cap is applied).
2020-11-01Auto merge of #75534 - Aaron1011:feature/new-future-breakage, r=pnkfelixbors-5/+22
Implement rustc side of report-future-incompat cc https://github.com/rust-lang/rust/issues/71249 This is an alternative to `@pnkfelix's` initial implementation in https://github.com/pnkfelix/rust/commits/prototype-rustc-side-of-report-future-incompat (mainly because I started working before seeing that branch :smile: ). My approach outputs the entire original `Diagnostic`, in a way that is compatible with incremental compilation. This is not yet integrated with compiletest, but can be used manually by passing `-Z emit-future-incompat-report` to `rustc`. Several changes are made to support this feature: * The `librustc_session/lint` module is moved to a new crate `librustc_lint_defs` (name bikesheddable). This allows accessing lint definitions from `librustc_errors`. * The `Lint` struct is extended with an `Option<FutureBreakage>`. When present, it indicates that we should display a lint in the future-compat report. `FutureBreakage` contains additional information that we may want to display in the report (currently, a `date` field indicating when the crate will stop compiling). * A new variant `rustc_error::Level::Allow` is added. This is used when constructing a diagnostic for a future-breakage lint that is marked as allowed (via `#[allow]` or `--cap-lints`). This allows us to capture any future-breakage diagnostics in one place, while still discarding them before they are passed to the `Emitter`. * `DiagnosticId::Lint` is extended with a `has_future_breakage` field, indicating whether or not the `Lint` has future breakage information (and should therefore show up in the report). * `Session` is given access to the `LintStore` via a new `SessionLintStore` trait (since `librustc_session` cannot directly reference `LintStore` without a cyclic dependency). We use this to turn a string `DiagnosticId::Lint` back into a `Lint`, to retrieve the `FutureBreakage` data. Currently, `FutureBreakage.date` is always set to `None`. However, this could potentially be interpreted by Cargo in the future. I've enabled the future-breakage report for the `ARRAY_INTO_ITER` lint, which can be used to test out this PR. The intent is to use the field to allow Cargo to determine the date of future breakage (as described in [RFC 2834](https://github.com/rust-lang/rfcs/blob/master/text/2834-cargo-report-future-incompat.md)) without needing to parse the diagnostic itself. cc `@pnkfelix`
2020-10-30Implement rustc side of report-future-incompatAaron Hill-5/+22
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-09-13 19:48:22 +0000