| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
zackmdavis:and_the_case_of_the_unused_field_pattern, r=estebank
correct unused field pattern suggestions
r? @estebank
|
|
zackmdavis:and_the_case_of_the_necessary_unnecessary_parens, r=nikomatsakis
decline to lint technically-unnecessary parens in function or method arguments inside of nested macros
In #46980 ("in which the unused-parens lint..." (14982db2d6)), the
unused-parens lint was made to check function and method arguments,
which it previously did not (seemingly due to oversight rather than
willful design). However, in #47775 and discussion thereon,
user–developers of Geal/nom and graphql-rust/juniper reported that the
lint was seemingly erroneously triggering on certain complex macros in
those projects. While this doesn't seem like a bug in the lint in the
particular strict sense that the expanded code would, in fact, contain
unncecessary parentheses, it also doesn't seem like the sort of thing
macro authors should have to think about: the spirit of the
unused-parens lint is to prevent needless clutter in code, not to give
macro authors extra heartache in the handling of token trees.
We propose the expediency of declining to lint unused parentheses in
function or method args inside of nested expansions: we believe that
this should eliminate the petty, troublesome lint warnings reported
in the issue, without forgoing the benefits of the lint in simpler
macros.
It seemed like too much duplicated code for the `Call` and `MethodCall`
match arms to duplicate the nested-macro check in addition to each
having their own `for` loop, so this occasioned a slight refactor so
that the function and method cases could share code—hopefully the
overall intent is at least no less clear to the gentle reader.
This is concerning #47775.
|
|
Previously, unused variables would get a note that the warning could be
silenced by prefixing the variable with an underscore, but that doesn't
work for field shorthand patterns, which the liveness analysis didn't
know about.
The "to avoid this warning" verbiage seemed unnecessary.
Resolves #47390.
|
|
In #46980 ("in which the unused-parens lint..." (14982db2d6)), the
unused-parens lint was made to check function and method arguments,
which it previously did not (seemingly due to oversight rather than
willful design). However, in #47775 and discussion thereon,
user–developers of Geal/nom and graphql-rust/juniper reported that the
lint was seemingly erroneously triggering on certain complex macros in
those projects. While this doesn't seem like a bug in the lint in the
particular strict sense that the expanded code would, in fact, contain
unncecessary parentheses, it also doesn't seem like the sort of thing
macro authors should have to think about: the spirit of the
unused-parens lint is to prevent needless clutter in code, not to give
macro authors extra heartache in the handling of token trees.
We propose the expediency of declining to lint unused parentheses in
function or method args inside of nested expansions: we believe that
this should eliminate the petty, troublesome lint warnings reported
in the issue, without forgoing the benefits of the lint in simpler
macros.
It seemed like too much duplicated code for the `Call` and `MethodCall`
match arms to duplicate the nested-macro check in addition to each
having their own `for` loop, so this occasioned a slight refactor so
that the function and method cases could share code—hopefully the
overall intent is at least no less clear to the gentle reader.
This is concerning #47775.
|
|
|
|
|
|
The incompetent fool who added these suggestions in 38e5a964f2 apparently
thought it was safe to assume that, because the offending function or
static was unreachable, it would therefore have not have any existing
visibility modifiers, making it safe for us to unconditionally suggest
inserting `pub`. This isn't true.
This resolves #47383.
|
|
Due to the disable-cloudabi tags being added to the source files, the
expected output of the compiler is altered slightly.
|
|
It looks like many of these tests are already disabled on emscripten,
which also doesn't seem to support environment variables and subprocess
spawning. Just add a similar tag for CloudABI. While there, sort some of
the lists of operating systems alphabetically.
|
|
|
|
Resolve type on return type suggestion
Partially address #45871.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Pretty print json in ui tests
I found the json output in one line to not be useful for reviewing
r? @petrochenkov
|
|
|
|
`unreachable-pub` lint (as authorized by RFC 2126)
To whom it may concern:
RFC 2126 commissions the creation of a lint for `pub` items that are not visible from crate root (#45521). We understand (but seek confirmation from more knowledgable compiler elders) that this can be implemented by linting HIR items that are _not_ ~~`cx.access_levels.is_exported`~~ `cx.access_levels.is_reachable` but have a `vis` (-ibility) field of `hir::Visibility::Public`.
The lint, tentatively called ~~`unexported-pub`~~ `unreachable-pub` (with the understanding that much could be written on the merits of various names, as it is said of the colors of bicycle-sheds), suggests `crate` as a replacement for `pub` if the `crate_visibility_modifier` feature is enabled (see #45388), and `pub(crate)` otherwise. We also use help messaging to suggest the other potential fix of exporting the item; feedback is desired as to whether this may be confusing or could be worded better.
As a preview of what respecting the proposed lint would look like (and to generate confirmatory evidence that this implementation doesn't issue false positives), ~~we take its suggestions for `libcore`~~ (save one, which is deferred to another pull request because it brings up an unrelated technical matter). I remain your obedient servant.
r? @petrochenkov
|
|
|
|
|
|
This is with deepest thanks to Vadim Petrochenkov for thorough review, and
resolves #45521.
|
|
|
|
Remove a couple of obsolete lints
|
|
|
|
|
|
Issue 44986/fix windows ui path
#44968
|
|
|
|
This updates the borrowck query to return a result, and this result is then used
to incrementally check for unused mutable nodes given sets of all the used
mutable nodes.
Closes #42384
|
|
|
|
|
|
|
|
(It was put forward that all tests related to a feature being in their own
directory makes stabilization decisionmaking more convenient.)
|
|
|
|
We'll actually want a new "soft" warning-only gate to maintain
backwards-compatibility, but it's cleaner to start out with the established,
well-understood gate before implementing the alternative warn-only behavior in
a later commit.
This is in the matter of #43302.
|
|
In preparation for incremental compilation this commit refactors the lint
handling infrastructure in the compiler to be more "eager" and overall more
incremental-friendly. Many passes of the compiler can emit lints at various
points but before this commit all lints were buffered in a table to be emitted
at the very end of compilation. This commit changes these lints to be emitted
immediately during compilation using pre-calculated lint level-related data
structures.
Linting today is split into two phases, one set of "early" lints run on the
`syntax::ast` and a "late" set of lints run on the HIR. This commit moves the
"early" lints to running as late as possible in compilation, just before HIR
lowering. This notably means that we're catching resolve-related lints just
before HIR lowering. The early linting remains a pass very similar to how it was
before, maintaining context of the current lint level as it walks the tree.
Post-HIR, however, linting is structured as a method on the `TyCtxt` which
transitively executes a query to calculate lint levels. Each request to lint on
a `TyCtxt` will query the entire crate's 'lint level data structure' and then go
from there about whether the lint should be emitted or not.
The query depends on the entire HIR crate but should be very quick to calculate
(just a quick walk of the HIR) and the red-green system should notice that the
lint level data structure rarely changes, and should hopefully preserve
incrementality.
Overall this resulted in a pretty big change to the test suite now that lints
are emitted much earlier in compilation (on-demand vs only at the end). This in
turn necessitated the addition of many `#![allow(warnings)]` directives
throughout the compile-fail test suite and a number of updates to the UI test
suite.
|
|
The return value of a function annotated with `must_use`, must be used.
This is in the matter of #43302.
|
|
Prior to this PR, when we aborted because a "critical pass" failed, we
displayed the number of errors from that critical pass. While that's the
number of errors that caused compilation to abort in *that place*,
that's not what people really want to know. Instead, always report the
total number of errors, and don't bother to track the number of errors
from the last pass that failed.
This changes the compiler driver API to handle errors more smoothly,
and therefore is a compiler-api-[breaking-change].
Fixes #42793.
|
|
This reverts commit 5558c64f33446225739c1153b43d2e309bb4f50e.
|
|
r=eddyb
make lint on-by-default/implied-by messages appear only once
From review discussion on #38103 (https://github.com/rust-lang/rust/pull/38103#discussion_r94845060).
r? @nikomatsakis
|
|
From review discussion on #38103
(https://github.com/rust-lang/rust/pull/38103#discussion_r94845060).
|
|
Previously, conflicting forbid/allow attributes for a lint group would
result in a separate "allow(L) overruled by outer forbid(L)" error for
every lint L in the group. This was needlessly and annoyingly verbose;
we prefer to just have one error pointing out the conflicting
attributes.
Resolves #42873.
|
