about summary refs log tree commit diff
path: root/src/test/ui/lint
AgeCommit message (Collapse)AuthorLines
2020-11-28Auto merge of #78296 - Aaron1011:fix/stmt-tokens, r=petrochenkovbors-0/+10
Properly handle attributes on statements We now collect tokens for the underlying node wrapped by `StmtKind` nstead of storing tokens directly in `Stmt`. `LazyTokenStream` now supports capturing a trailing semicolon after it is initially constructed. This allows us to avoid refactoring statement parsing to wrap the parsing of the semicolon in `parse_tokens`. Attributes on item statements (e.g. `fn foo() { #[bar] struct MyStruct; }`) are now treated as item attributes, not statement attributes, which is consistent with how we handle attributes on other kinds of statements. The feature-gating code is adjusted so that proc-macro attributes are still allowed on item statements on stable. Two built-in macros (`#[global_allocator]` and `#[test]`) needed to be adjusted to support being passed `Annotatable::Stmt`.
2020-11-27Don't lint on redundant semicolons after item statementsAaron Hill-0/+10
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-26Store ForeignItem in a side table.Camille GILLOT-18/+18
2020-11-22Drop support for cloudabi targetsLzu Tao-54/+53
2020-11-21Auto merge of #77805 - JohnTitor:non-standard-char-sugg, r=Dylan-DPCbors-0/+56
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-18Rollup merge of #79158 - lcnr:lazy-norm-coerce, r=oli-obkMara Bos-2/+2
type is too big -> values of the type are too big strictly speaking, `[u8; usize::MAX]` or even `[[[u128; usize::MAX]; usize::MAX]; usize::MAX]` are absolutely fine types as long as you don't try to deal with any values of it. This error message seems to cause some confusion imo, for example in https://github.com/rust-lang/rust/pull/79135#issuecomment-729361380 so I would prefer us to be more precise here. See the added test case which uses one of these types without causing an error. r? ``@oli-obk``
2020-11-18change error for `LayoutErr::SizeOverflow`Bastian Kauschke-2/+2
2020-11-14Use true previous lint level when detecting overriden forbidsMark Rousskov-164/+84
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-12stability: More precise location for deprecation lint on macrosVadim Petrochenkov-1/+11
2020-11-07Use a semicolon instead of a dash in lint noteAaron Hill-4/+4
2020-11-07Don't fire `CONST_ITEM_MUTATION` lint when borrowing a derefAaron Hill-8/+13
Fixes #78819 This extends the check for dereferences added in PR #77324 to cover mutable borrows, as well as direct writes. If we're operating on a dereference of a `const` item, we shouldn't be firing the lint.
2020-11-03Rollup merge of #78659 - ayrtonm:fn-ref-lint-fix, r=oli-obkMara Bos-31/+75
Corrected suggestion for generic parameters in `function_item_references` lint This commit handles functions with generic type parameters like you pointed out as well as const generics. Also this is probably a minor thing, but the type alias you used in the example doesn't show up so the suggestion right now would be `size_of::<[u8; 16]> as fn() ->`. This is because the lint checker works with MIR instead of HIR. I don't think we can get the alias at that point, but let me know if I'm wrong and there's a way to fix this. Also I put you as the reviewer, but I'm not sure if you want to review it or if it makes more sense to ask one of the original reviewers of this lint. closes #78571
2020-11-02Fix ICE when a future-incompat-report has its command-line level cappedAaron Hill-0/+21
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-01Corrected suggestion for generic parameters in `function_item_references` lintAyrton-31/+75
This lint was incorrectly suggesting casting a function to a pointer without specifying generic type parameters or const generics. This would cause a compiler error since the missing parameters couldn't be inferred. This commit fixed the suggestion and added a few tests with generics.
2020-10-29Rollup merge of #78431 - Rustin-Liu:rustin-patch-lint, r=estebankJonas Schievink-4/+4
Prefer new associated numeric consts in float error messages Fix https://github.com/rust-lang/rust/issues/78382
2020-10-27Auto merge of #75671 - nathanwhit:cstring-temp-lint, r=oli-obkbors-0/+56
Uplift `temporary-cstring-as-ptr` lint from `clippy` into rustc The general consensus seems to be that this lint covers a common enough mistake to warrant inclusion in rustc. The diagnostic message might need some tweaking, as I'm not sure the use of second-person perspective matches the rest of rustc, but I'd like to hear others' thoughts on that. (cc #53224). r? `@oli-obk`
2020-10-27Added suggestion to `function_item_references` lint and fixed warning messageAyrton-84/+84
Also updated tests accordingly and tweaked some wording in the lint declaration.
2020-10-27Added documentation for `function_item_references` lintAyrton-29/+29
Added documentation for `function_item_references` lint to the rustc book and fixed comments in the lint checker itself.
2020-10-27Fixed compiler error in lint checker triggered by associated typesAyrton-30/+57
When a function argument bound by `Pointer` is an associated type, we only perform substitutions using the parameters from the callsite but don't attempt to normalize since it may not succeed. A simplified version of the scenario that triggered this error was added as a test case. Also fixed `Pointer::fmt` which was being double-counted when called outside of macros and added a test case for this.
2020-10-27Removed test for unhandled case in function_item_references lintAyrton-88/+85
Removed test for the unhandled case of calls to `fn f<T>(x: &T)` where `x` is a function reference and is formatted as a pointer in `f`. This compiles since `&T` implements `Pointer`, but is unlikely to occur in practice. Also tweaked the lint's wording and modified tests accordingly.
2020-10-27Changed lint to check for `std::fmt::Pointer` and `transmute`Ayrton-73/+204
The lint checks arguments in calls to `transmute` or functions that have `Pointer` as a trait bound and displays a warning if the argument is a function reference. Also checks for `std::fmt::Pointer::fmt` to handle formatting macros although it doesn't depend on the exact expansion of the macro or formatting internals. `std::fmt::Pointer` and `std::fmt::Pointer::fmt` were also added as diagnostic items and symbols.
2020-10-27modified lint to work with MIRAyrton-24/+156
Working with MIR let's us exclude expressions like `&fn_name as &dyn Something` and `(&fn_name)()`. Also added ABI, unsafety and whether a function is variadic in the lint suggestion, included the `&` in the span of the lint and updated the test.
2020-10-27changed lint to suggest casting to the proper function type and added a testAyrton-0/+44
2020-10-27Fix testNathan Whitaker-2/+3
2020-10-27Prefer new associated numeric consts in float error messagesRustin-Liu-4/+4
2020-10-26Address review commentsNathan Whitaker-8/+8
2020-10-26Write docs for lint / fix review nitNathan Whitaker-6/+5
2020-10-26Address review commentsNathan Whitaker-2/+33
2020-10-26Change to warn by default / fix typoNathan Whitaker-2/+7
2020-10-26Tweak diagnosticNathan Whitaker-7/+4
2020-10-26Address review commentsNathan Whitaker-8/+7
2020-10-26Add basic testNathan Whitaker-0/+24
2020-10-26simplify-locals: Remove unused set-discriminant statementsTomasz Miąsko-1/+2
Update affected ui & incremental tests to use a user declared variable bindings instead of temporaries. The former are preserved because of debuginfo, the latter are not.
2020-10-24Fix inconsistencies in handling of inert attributes on statementsAaron Hill-4/+49
When the 'early' and 'late' visitors visit an attribute target, they activate any lint attributes (e.g. `#[allow]`) that apply to it. This can affect warnings emitted on sibiling attributes. For example, the following code does not produce an `unused_attributes` for `#[inline]`, since the sibiling `#[allow(unused_attributes)]` suppressed the warning. ```rust trait Foo { #[allow(unused_attributes)] #[inline] fn first(); #[inline] #[allow(unused_attributes)] fn second(); } ``` However, we do not do this for statements - instead, the lint attributes only become active when we visit the struct nested inside `StmtKind` (e.g. `Item`). Currently, this is difficult to observe due to another issue - the `HasAttrs` impl for `StmtKind` ignores attributes for `StmtKind::Item`. As a result, the `unused_doc_comments` lint will never see attributes on item statements. This commit makes two interrelated fixes to the handling of inert (non-proc-macro) attributes on statements: * The `HasAttr` impl for `StmtKind` now returns attributes for `StmtKind::Item`, treating it just like every other `StmtKind` variant. The only place relying on the old behavior was macro which has been updated to explicitly ignore attributes on item statements. This allows the `unused_doc_comments` lint to fire for item statements. * The `early` and `late` lint visitors now activate lint attributes when invoking the callback for `Stmt`. This ensures that a lint attribute (e.g. `#[allow(unused_doc_comments)]`) can be applied to sibiling attributes on an item statement. For now, the `unused_doc_comments` lint is explicitly disabled on item statements, which preserves the current behavior. The exact locatiosn where this lint should fire are being discussed in PR #78306
2020-10-14Fixed false positive for `unused_parens` lintaticu-4/+8
2020-10-11Do not provide suggestions for non standard charactersYuki Okushi-0/+56
2020-10-04Prevent forbid from being ignored if overriden at the same level.Felix S. Klock II-0/+78
That is, this changes `#[forbid(foo)] #[allow(foo)]` from allowing foo to forbidding foo.
2020-09-30Warn on method call mutating const, even if it has destructorDavid Tolnay-2/+27
2020-09-30Add test of VEC.push on a constDavid Tolnay-7/+9
2020-09-30Test a type with drop glue but no Drop implDavid Tolnay-13/+33
2020-09-30Add test of const item mutation with Drop implDavid Tolnay-12/+24
2020-10-01Rollup merge of #77324 - Aaron1011:fix/const-item-mutation-ptr, r=petrochenkovDylan DPC-24/+35
Don't fire `const_item_mutation` lint on writes through a pointer Fixes #77321
2020-09-28Don't fire `const_item_mutation` lint on writes through a pointerAaron Hill-24/+35
Fixes #77321
2020-09-26Normalise `BITS` in UI testvarkor-7/+7
2020-09-26Make invalid integer operation messages consistentvarkor-72/+72
2020-09-22dead_code: look at trait impls even if they don't contain itemsBastian Kauschke-0/+19
2020-09-22lint missing docs for extern itemsBastian Kauschke-2/+37
2020-09-10Note when a a move/borrow error is caused by a deref coercionAaron Hill-1/+1
Fixes #73268 When a deref coercion occurs, we may end up with a move error if the base value has been partially moved out of. However, we do not indicate anywhere that a deref coercion is occuring, resulting in an error message with a confusing span. This PR adds an explicit note to move errors when a deref coercion is involved. We mention the name of the type that the deref-coercion resolved to, as well as the `Deref::Target` associated type being used.
2020-09-07Add CONST_ITEM_MUTATION lintAaron Hill-0/+110
Fixes #74053 Fixes #55721 This PR adds a new lint `CONST_ITEM_MUTATION`. Given an item `const FOO: SomeType = ..`, this lint fires on: * Attempting to write directly to a field (`FOO.field = some_val`) or array entry (`FOO.array_field[0] = val`) * Taking a mutable reference to the `const` item (`&mut FOO`), including through an autoderef `FOO.some_mut_self_method()` The lint message explains that since each use of a constant creates a new temporary, the original `const` item will not be modified.
2020-09-03rustc_lint: avoid trimmed paths for ty_find_init_errorDan Aloni-5/+5
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-10 14:09:24 +0000