about summary refs log tree commit diff
path: root/compiler/rustc_lint/src
AgeCommit message (Collapse)AuthorLines
2021-07-08Update to last upstream versionGuillaume Gomez-4/+6
2021-07-08Rollup merge of #86639 - eholk:lint-tool, r=petrochenkovYuki Okushi-34/+101
Support lint tool names in rustc command line options When rustc is running without a lint tool such as clippy enabled, options for lints such as `clippy::foo` are meant to be ignored. This was already working for those specified by attrs, such as `#![allow(clippy::foo)]`, but this did not work for command line arguments like `-A clippy::foo`. This PR fixes that issue. Note that we discovered this issue while discussing https://github.com/rust-lang/cargo/issues/5034. Fixes #86628.
2021-07-07Cleanup: unify lint name checkingEric Holk-21/+14
This change merges `check_lint_and_tool_name` into `check_lint_name` in order to avoid having two very similar functions. Also adds the `.stderr` file back for the test case, since apparently it is still needed.
2021-07-06Unify lint tool and lint name checkingEric Holk-36/+69
This shares a little more code between checking command line and attribute lint specifications.
2021-07-06Parse tool name for command line lint optionsEric Holk-3/+44
2021-07-06Add s to non_fmt_panicRyan Levick-6/+7
2021-07-06Change or_patterns_back_compat lint to rust_2021_incompatible_or_patternsRyan Levick-0/+1
2021-07-06Rename lintRyan Levick-0/+1
2021-07-06Auto merge of #82985 - cjgillot:lint, r=jackh726bors-8/+8
Cleanup the computation of lint levels This now uses an `IndexVec` and a special root `LintStackIndex = 0` to encode command-line levels.
2021-07-03Warn when `rustdoc::` group is omitted from lint namesJoshua Nelson-16/+0
2021-07-03Add a help message to `unused_doc_comments` lintYuki Okushi-2/+13
2021-07-01Rollup merge of #85520 - FabianWolff:issue-85475, r=jackh726Yuki Okushi-1/+1
Fix typo and improve documentation for E0632 Edit: After https://github.com/rust-lang/rust/pull/85520#issuecomment-870095546, this PR has been boiled down to just an extended description for `E0632` and a fixed typo.
2021-06-30Improve wording of the `drop_bounds` lintFabian Wolff-16/+20
2021-06-30Auto merge of #86689 - rylev:future-compat-lint-group, r=nikomatsakisbors-10/+13
Only include lint in future_incompatible lint group if not an edition lint A follow up to #86330 - this only includes lints annotated with `FutureIncompatibleInfo` in the `future_incompatibile` lint group if the future compatibility is not tied to an edition. We probably want to rename `FutureIncompatibleInfo` to something else since this type is now used to indicate future breakages of all kinds (even those that happen in editions). I'd prefer to do that in a separate PR though. r? `@nikomatsakis`
2021-06-29Encode CommandLine in the index only.Camille GILLOT-2/+2
2021-06-29Use a newtype_index instead of a u32.Camille GILLOT-8/+8
2021-06-29Auto merge of #86009 - cjgillot:fwarn, r=davidtwcobors-39/+30
Make ForceWarn a lint level. Follow-up to #85788 cc `@rylev`
2021-06-29Auto merge of #86446 - Smittyvb:rustc_insignificant_dtor-ice, r=Mark-Simulacrumbors-1/+1
Don't make `rustc_insignificant_dtor` feature gate This isn't a feature gate, it's an attribute that is feature gated behind the `rustc_attrs` attribute. Closes #85680.
2021-06-29Rollup merge of #86671 - m-ou-se:non-fmt-panic-future-incompatible, ↵Yuki Okushi-1/+8
r=nikomatsakis Turn non_fmt_panic into a future_incompatible edition lint. This turns the `non_fmt_panic` lint into a future_incompatible edition lint, so it becomes part of the `rust_2021_compatibility` group. See https://github.com/rust-lang/rust/issues/85894. This lint produces both warnings about semantical changes (e.g. `panic!("{{")`) and things that will become hard errors (e.g. `panic!("{")`). So I added a `explain_reason: false` that supresses the default "this will become a hard error" or "the semantics will change" message, and instead added a note depending on the situation. (cc `@rylev)` r? `@nikomatsakis`
2021-06-29Fix typo and improve documentation for E0632Fabian Wolff-1/+1
2021-06-28Make incomplete features part of delcarationSmitty-1/+1
This prevents mistakes where the feature is in the list of incomplete features but not actually a feature by making the incompleteness a part of the declaration.
2021-06-28Add comment for future_incompatible lint groupRyan Levick-0/+3
2021-06-28Only include lint in future_incompatible lint group if not an edition lintRyan Levick-10/+10
2021-06-27Auto merge of #85359 - lrh2000:reserved-prefixes, r=nikomatsakisbors-0/+9
Reserve prefixed identifiers and literals (RFC 3101) This PR denies any identifiers immediately followed by one of three tokens `"`, `'` or `#`, which is stricter than the requirements of RFC 3101 but may be necessary according to the discussion at [Zulip]. [Zulip]: https://rust-lang.zulipchat.com/#narrow/stream/268952-edition-2021/topic/reserved.20prefixes/near/238470099 The tracking issue #84599 says we'll add a feature gate named `reserved_prefixes`, but I don't think I can do this because it is impossible for the lexer to know whether a feature is enabled or not. I guess determining the behavior by the edition information should be enough. Fixes #84599
2021-06-27Turn non_fmt_panic into a future_incompatible edition lint.Mara Bos-1/+8
2021-06-26Add migration lint for reserved prefixes.Mara Bos-0/+9
2021-06-26Better suggestion for array_into_iter in for loop.Mara Bos-18/+45
2021-06-26Add new suggestion to array_into_iter lint.Mara Bos-0/+8
2021-06-26Change wording on array_into_iter lint for 1.53 and edition changes.Mara Bos-17/+11
2021-06-26Make ForceWarn a lint level.Camille GILLOT-39/+30
2021-06-25Address PR feedbackRyan Levick-1/+0
2021-06-25Change how edition based future compatibility warnings are handledRyan Levick-10/+10
2021-06-18Lint for unused borrows as part of UNUSED_MUST_USEhi-rustin-0/+1
2021-06-10Add support for using qualified paths with structs in expression and patternRyan Levick-2/+2
position.
2021-06-08Rollup merge of #85906 - LingMan:iter_find, r=matthewjasperYuki Okushi-8/+3
Use `Iterator::find` instead of open-coding it ```@rustbot``` modify labels +C-cleanup +T-compiler
2021-06-07Rollup merge of #85912 - LingMan:iter_any, r=nagisaGuillaume Gomez-9/+4
Use `Iterator::any` and `filter_map` instead of open-coding them ``@rustbot`` modify labels +C-cleanup +T-compiler
2021-06-04Make *const (), *mut () okay for FFIDavid Tolnay-0/+9
2021-06-05Auto merge of #85457 - jyn514:remove-doc-include, r=GuillaumeGomezbors-1/+1
Remove `doc(include)` This nightly feature is redundant now that `extended_key_value_attributes` is stable (https://github.com/rust-lang/rust/pull/83366). `@rust-lang/rustdoc` not sure if you think this needs FCP; there was already an FCP in #82539, but technically it was for deprecating, not removing the feature altogether. This should not be merged before #83366. cc `@petrochenkov`
2021-06-05Rollup merge of #85853 - marmeladema:improper-ctypes-definitions-boxed-dst, ↵Yuki Okushi-4/+11
r=petrochenkov Warn against boxed DST in `improper_ctypes_definitions` lint Fixes #85714
2021-06-04Auto merge of #85788 - rylev:force-warns, r=nikomatsakisbors-14/+39
Support for force-warns Implements https://github.com/rust-lang/rust/issues/85512. This PR adds a new command line option `force-warns` which will force the provided lints to warn even if they are allowed by some other mechanism such as `#![allow(warnings)]`. Some remaining issues: * https://github.com/rust-lang/rust/issues/85512 mentions that `force-warns` should also be capable of taking lint groups instead of individual lints. This is not implemented. * If a lint has a higher warning level than `warn`, this will cause that lint to warn instead. We probably want to allow the lint to error if it is set to a higher lint and is not allowed somewhere else. * One test is currently ignored because it's not working - when a deny-by-default lint is allowed, it does not currently warn under `force-warns`. I'm not sure why, but I wanted to get this in before the weekend. r? `@nikomatsakis`
2021-06-04Remove `doc(include)`Joshua Nelson-1/+1
2021-06-04Rollup merge of #85850 - bjorn3:less_feature_gates, r=jyn514Yuki Okushi-2/+0
Remove unused feature gates The first commit removes a usage of a feature gate, but I don't expect it to be controversial as the feature gate was only used to workaround a limitation of rust in the past. (closures never being `Clone`) The second commit uses `#[allow_internal_unstable]` to avoid leaking the `trusted_step` feature gate usage from inside the index newtype macro. It didn't work for the `min_specialization` feature gate though. The third commit removes (almost) all feature gates from the compiler that weren't used anyway.
2021-06-03Warn against boxed DST in `improper_ctypes_definitions` lintmarmeladema-4/+11
2021-06-03Rollup merge of #85900 - LingMan:pat_mat, r=petrochenkovYuki Okushi-19/+7
Use pattern matching instead of checking lengths explicitly This piece of code checks that there are exaclty two variants, one having exactly one field, the other having exactly zero fields. If any of these conditions is violated, it returns `None`. Otherwise it assigns that one field's ty to `field_ty`. Instead of fiddling with indices and length checks explicitly, use pattern matching to simplify this. `@rustbot` modify labels +C-cleanup +T-compiler
2021-06-02Restrict access to crate_name.Camille GILLOT-1/+1
Also remove original_crate_name, which had the exact same implementation
2021-06-02Force warn on lint groups as wellRyan Levick-16/+32
2021-06-01Use pattern matching instead of checking lengths explicitlyLingMan-19/+7
This piece of code checks that there are exaclty two variants, one having exactly one field, the other having exactly zero fields. If any of these conditions is violated, it returns `None`. Otherwise it assigns that one field's ty to `field_ty`. Instead of fiddling with indices and length checks explicitly, use pattern matching to simplify this.
2021-06-01Use `Iterator::any` and `filter_map` instead of open-coding themLingMan-9/+4
2021-06-01Use `Iterator::find` instead of open-coding itLingMan-8/+3
2021-06-01Fix issues and add testRyan Levick-1/+1