Add AST validation pass and move some checks to it
The purpose of this pass is to catch constructions that fit into AST data structures, but not permitted by the language. As an example, `impl`s don't have visibilities, but for convenience and uniformity with other items they are represented with a structure `Item` which has `Visibility` field.
This pass is intended to run after expansion of macros and syntax extensions (and before lowering to HIR), so it can catch erroneous constructions that were generated by them. This pass allows to remove ad hoc semantic checks from the parser, which can be overruled by syntax extensions and occasionally macros.
The checks can be put here if they are simple, local, don't require results of any complex analysis like name resolution or type checking and maybe don't logically fall into other passes. I expect most of errors generated by this pass to be non-fatal and allowing the compilation to proceed.
I intend to move some more checks to this pass later and maybe extend it with new checks, like, for example, identifier validity. Given that syntax extensions are going to be stabilized in the measurable future, it's important that they would not be able to subvert usual language rules.
In this patch I've added two new checks - a check for labels named `'static` and a check for lifetimes and labels named `'_`. The first one gives a hard error, the second one - a future compatibility warning.
Fixes https://github.com/rust-lang/rust/issues/33059 ([breaking-change])
cc https://github.com/rust-lang/rfcs/pull/1177
r? @nrc
resolve: record pattern def when `resolve_pattern` returns `Err(true)`
I propose a fix for issue #33293.
In 1a374b8, (pr #33046) fixed the error reporting of a specific case, but the change that was introduced did not make sure that `record_def` was called in all cases, which lead to an ICE in [1].
This change restores the original `else` case, but keeps the changes that were committed in 1a374b8.
[1] `rustc::middle::mem_categorization::MemCategorizationContext::cat_pattern_`
In 1a374b8, (pr #33046) fixed the error reporting of a specific
case, but the change that was introduced did not make sure that
`record_def` was called in all cases, which lead to an ICE in [1].
This change restores the original `else` case, but keeps the changes
that were committed in 1a374b8.
This commit fixes issue #33293.
[1] `rustc::middle::mem_categorization::MemCategorizationContext::cat_pattern_`
This makes the \"shadowing labels\" warning *not* print the entire loop as a span, but only the lifetime.
Also makes #31719 go away, but does not fix its root cause (the span of the expanded loop is still wonky, but not used anymore).
This makes the "shadowing labels" warning *not* print the entire loop
as a span, but only the lifetime.
Also makes #31719 go away, but does not fix its root cause (the span
of the expanded loop is still wonky, but not used anymore).
Remove ExplicitSelf from HIR
`self` argument is already kept in the argument list and can be retrieved from there if necessary, so there's no need for the duplication.
The same changes can be applied to AST, I'll make them in the next breaking batch.
The first commit also improves parsing of method declarations and fixes https://github.com/rust-lang/rust/issues/33413.
r? @eddyb
Batch of improvements to errors for new error format
This is a batch of improvements to existing errors to help get the most out of the new error format.
* Added labels to primary spans (^^^) for a set of errors that didn't currently have them
* Highlight the source blue under the secondary notes for better readability
* Move some of the "Note:" into secondary spans+labels
* Fix span_label to take &mut instead, which makes it work the same as other methods in that set
re-introduce a cache for ast-ty-to-ty
It turns out that `ast_ty_to_ty` is supposed to be updating the `def`
after it finishes, but at some point in the past it stopped doing
so. This was never noticed because of the `ast_ty_to_ty_cache`, but that
cache was recently removed. This PR fixes the code to update the def
properly, but apparently that is not quite enough to make the operation
idempotent, so for now we reintroduce the cache too.
Fixes#33586.
r? @eddyb
rustbuild: Add support for crate tests + doctests
This commit adds support to rustbuild to run crate unit tests (those defined by
`#[test]`) as well as documentation tests. All tests are powered by `cargo test`
under the hood.
Each step requires the `libtest` library is built for that corresponding stage.
Ideally the `test` crate would be a dev-dependency, but for now it's just easier
to ensure that we sequence everything in the right order.
Currently no filtering is implemented, so there's not actually a method of
testing *only* libstd or *only* libcore, but rather entire swaths of crates are
tested all at once.
A few points of note here are:
* The `coretest` and `collectionstest` crates are just listed as `[[test]]`
entires for `cargo test` to naturally pick up. This mean that `cargo test -p
core` actually runs all the tests for libcore.
* Libraries that aren't tested all mention `test = false` in their `Cargo.toml`
* Crates aren't currently allowed to have dev-dependencies due to
rust-lang/cargo#860, but we can likely alleviate this restriction once
workspaces are implemented.
cc #31590
It turns out that `ast_ty_to_ty` is supposed to be updating the `def`
after it finishes, but at some point in the past it stopped doing
so. This was never noticed because of the `ast_ty_to_ty_cache`, but that
cache was recently removed. This PR fixes the code to update the def
properly, but apparently that is not quite enough to make the operation
idempotent, so for now we reintroduce the cache too.
Fixes#33425.
This commit adds support to rustbuild to run crate unit tests (those defined by
`#[test]`) as well as documentation tests. All tests are powered by `cargo test`
under the hood.
Each step requires the `libtest` library is built for that corresponding stage.
Ideally the `test` crate would be a dev-dependency, but for now it's just easier
to ensure that we sequence everything in the right order.
Currently no filtering is implemented, so there's not actually a method of
testing *only* libstd or *only* libcore, but rather entire swaths of crates are
tested all at once.
A few points of note here are:
* The `coretest` and `collectionstest` crates are just listed as `[[test]]`
entires for `cargo test` to naturally pick up. This mean that `cargo test -p
core` actually runs all the tests for libcore.
* Libraries that aren't tested all mention `test = false` in their `Cargo.toml`
* Crates aren't currently allowed to have dev-dependencies due to
rust-lang/cargo#860, but we can likely alleviate this restriction once
workspaces are implemented.
cc #31590
resolve: do not modify span of non-importable name
This span modification is probably leftover from a time when import spans were assigned differently.
With this change, error spans for the following are properly reported:
```
use abc::one_el;
use abc::{a, bbb, cccccc};
use a_very_long_name::{el, el2};
```
before (spans only):
```
x.rs:3 use abc::one_el;
^~~
x.rs:4 use abc::{a, bbb, cccccc};
^~~
x.rs:4 use abc::{a, bbb, cccccc};
^~~
x.rs:4 use abc::{a, bbb, cccccc};
^~~
(internal compiler error: unprintable span)
(internal compiler error: unprintable span)
```
after:
```
x.rs:3 use abc::one_el;
^~~~~~~~~~~
x.rs:4 use abc::{a, bbb, cccccc};
^
x.rs:4 use abc::{a, bbb, cccccc};
^~~
x.rs:4 use abc::{a, bbb, cccccc};
^~~~~~
x.rs:5 use a_very_long_name::{el, el2};
^~
x.rs:5 use a_very_long_name::{el, el2};
^~~
```
Fixes: #33464
This span modification is probably leftover from a time when
import spans were assigned differently.
With this change, error spans for the following are properly reported:
```
use abc::one_el;
use abc::{a, bbb, cccccc};
use a_very_long_name::{el, el2};
```
before (spans only):
```
x.rs:3 use abc::one_el;
^~~
x.rs:4 use abc::{a, bbb, cccccc};
^~~
x.rs:4 use abc::{a, bbb, cccccc};
^~~
x.rs:4 use abc::{a, bbb, cccccc};
^~~
(internal compiler error: unprintable span)
(internal compiler error: unprintable span)
```
after:
```
x.rs:3 use abc::one_el;
^~~~~~~~~~~
x.rs:4 use abc::{a, bbb, cccccc};
^
x.rs:4 use abc::{a, bbb, cccccc};
^~~
x.rs:4 use abc::{a, bbb, cccccc};
^~~~~~
x.rs:5 use a_very_long_name::{el, el2};
^~
x.rs:5 use a_very_long_name::{el, el2};
^~~
```
Fixes: #33464
Perform name resolution before and during ast->hir lowering
This PR performs name resolution before and during ast->hir lowering instead of in phase 3.
r? @nrc
Improve diagnostics for constants being used in irrefutable patterns
It's pretty confusing and this error triggers in resolve only when "shadowing" a const, so let's make that clearer.
r? @steveklabnik
resolve: print location of static for "static in pattern" error
The implementation mirrors the one for "constant defined here" annotation used for constant patterns in the irrefutable-pattern case.
Fixes: #23716
diagnostics for E0432: imports are relative to crate root
This is curiously missing from both the short message and this long diagnostic.
Refs #31573 (not sure if it should be considered "fixed" as the short message still only refers to extern crates).
The extra filename and line was mainly there to keep the indentation
relative to the main snippet; now that this doesn't include
filename/line-number as a prefix, it is distracted.
This is curiously missing from both the short message and this
long diagnostic.
Refs #31573 (not sure if it should be considered "fixed" as the
short message still only refers to extern crates).
resolve: improve diagnostics and lay groundwork for resolving before ast->hir
This PR improves diagnostics in `resolve` and lays some groundwork for resolving before ast->hir.
More specifically,
- It removes an API in `resolve` intended for external refactoring tools (see #27493) that appears not to be in active use. The API is incompatible with resolving before ast->hir, but could be rewritten in a more compatible and less intrusive way.
- It improves the diagnostics for pattern bindings that conflict with `const`s.
- It improves the diagnostics for modules used as expressions (fixes#33186).
- It refactors away some uses of the hir map, which is unavavailable before ast->hir lowering.
r? @eddyb
syntax: Merge PathParsingMode::NoTypesAllowed and PathParsingMode::ImportPrefix
syntax: Rename PathParsingMode and its variants to better express their purpose
syntax: Remove obsolete error message about 'self lifetime
syntax: Remove ALLOW_MODULE_PATHS workaround
syntax/resolve: Adjust some error messages
resolve: Compare unhygienic (not renamed) names with keywords::Invalid, invalid identifiers may appear to be valid after renaming
resolve: Improve duplicate glob detection
This fixes a bug introduced in #31726 in which we erroneously allow multiple imports of the same item under some circumstances.
More specifically, we erroneously allow a module that is in a cycle of glob re-exports to have other re-exports (besides the glob from the cycle).
For example,
```rust
pub fn f() {}
mod foo {
pub use f; // (1) This defines `foo::f`.
pub use bar::*; // (3) This also defines `foo::f`, which should be a duplicate error but is currently allowed.
}
mod bar {
pub use foo::*; // (2) This defines `bar::f`.
}
```
A module in a glob re-export cycle can still have `pub` items after this PR. For example,
```rust
mod foo {
pub fn f() {}; // (1) This defines `foo::f`.
pub use bar::*; // (3) This is not a duplicate error since items shadow glob-imported re-exports (cf #31337).
}
mod bar {
pub use foo::*; // (2) This defines `bar::f`.
}
```
r? @nikomatsakis
Fix issue: Global paths in `use` directives can begin with `super` or `self` #32225
This PR fixes#32225 by warning on `use ::super::...` and `use ::self::...` on `resolve`.
Current changes is the most minimal and ad-hoc.
resolve: Improve import failure detection and lay groundwork for RFC 1422
This PR improves import failure detection and lays some groundwork for RFC 1422.
More specifically, it
- Avoids recomputing the resolution of an import directive's module path.
- Refactors code in `resolve_imports` that does not scale to the arbitrarily many levels of visibility that will be required by RFC 1422.
- Replaces `ModuleS`'s fields `public_glob_count`, `private_glob_count`, and `resolved_globs` with a list of glob import directives `globs`.
- Replaces `NameResolution`'s fields `pub_outstanding_references` and `outstanding_references` with a field `single_imports` of a newly defined type `SingleImports`.
- Improves import failure detection by detecting cycles that include single imports (currently, only cycles of globs are detected). This fixes#32119.
r? @nikomatsakis
resolve: Minimize hacks in name resolution of primitive types
When resolving the first unqualified segment in a path with `n` segments and `n - 1` associated item segments, e.g. (`a` or `a::assoc` or `a::assoc::assoc` etc) try to resolve `a` without considering primitive types first. If the "normal" lookup fails or results in a module, then try to resolve `a` as a primitive type as a fallback.
This way backward compatibility is respected, but the restriction from E0317 can be lifted, i.e. primitive names mostly can be shadowed like any other names.
Furthermore, if names of primitive types are [put into prelude](https://github.com/petrochenkov/rust/tree/prim2) (now it's possible to do), then most of names will be resolved in conventional way and amount of code relying on this fallback will be greatly reduced. Although, it's not entirely convenient to put them into prelude right now due to temporary conflicts like `use prelude::v1::*; use usize;` in libcore/libstd, I'd better wait for proper glob shadowing before doing it.
I wish the `no_prelude` attribute were unstable as intended :(
cc @jseyfried @arielb1
r? @eddyb
Disallow methods from traits that are not in scope
This PR only allows a trait method to be used if the trait is in scope (fixes#31379).
This is a [breaking-change]. For example, the following would break:
```rust
mod foo {
pub trait T { fn f(&self) {} }
impl T for () {}
}
mod bar { pub use foo::T; }
fn main() {
pub use bar::*;
struct T; // This shadows the trait `T`,
().f() // making this an error.
}
```
r? @nikomatsakis
The initial wording does not make sense due to an extra 'to'.
There are two potential candidates we can change this to:
- 'you can import it into scope'
- 'to import it into scope'
In keeping the changes minimal, we choose the first, as this is more in line with the grammar of the extended candidates help message.
Fix name resolution in lexical scopes
Currently, `resolve_item_in_lexical_scope` does not check the "ribs" (type parameters and local variables). This can allow items that should be shadowed by type parameters to be named.
For example,
```rust
struct T { i: i32 }
fn f<T>() {
let t = T { i: 0 }; // This use of `T` resolves to the struct, not the type parameter
}
mod Foo {
pub fn f() {}
}
fn g<Foo>() {
Foo::f(); // This use of `Foo` resolves to the module, not the type parameter
}
```
This PR changes `resolve_item_in_lexical_scope` so that it fails when the item is shadowed by a rib (fixes#32120).
This is a [breaking-change], but it looks unlikely to cause breakage in practice.
r? @nikomatsakis
Forbid glob-importing from a type alias
This PR forbids glob-importing from a type alias or trait (fixes#30560):
```rust
type Alias = ();
use Alias::*; // This is currently allowed but shouldn't be
```
This is a [breaking-change]. Since the disallowed glob imports don't actually import anything, any breakage can be fixed by removing the offending glob import.
r? @alexcrichton
Fix a regression in import resolution
This fixes#32089 (caused by #31726) by deducing that name resolution has failed (as opposed to being determinate) in more cases.
r? @nikomatsakis
This PR privacy checks paths as they are resolved instead of in `librustc_privacy` (fixes#12334 and fixes#31779). This removes the need for the `LastPrivate` system introduced in PR #9735, the limitations of which cause #31779.
This PR also reports privacy violations in paths to intra- and inter-crate items the same way -- it always reports the first inaccessible segment of the path.
Since it fixes#31779, this is a [breaking-change]. For example, the following code would break:
```rust
mod foo {
pub use foo::bar::S;
mod bar { // `bar` should be private to `foo`
pub struct S;
}
}
impl foo::S {
fn f() {}
}
fn main() {
foo::bar::S::f(); // This is now a privacy error
}
```
r? @alexcrichton
This fixes a bug (#31845) introduced in #31105 in which lexical scopes contain items from all anonymous module ancestors, even if the path to the anonymous module includes a normal module:
```rust
fn f() {
fn g() {}
mod foo {
fn h() {
g(); // This erroneously resolves on nightly
}
}
}
```
This is a [breaking-change] on nightly but not on stable or beta.
r? @nikomatsakis
The standard library doesn't depend on rustc_bitflags, so move it to explicit
dependencies on all other crates. Additionally, the arena/fmt_macros deps could
be dropped from libsyntax.
The standard library doesn't depend on rustc_bitflags, so move it to explicit
dependencies on all other crates. Additionally, the arena/fmt_macros deps could
be dropped from libsyntax.
Now that #31461 is merged, a failing resolution can never become indeterminate or succeed, so we no longer have to keep trying to resolve failing import directives.
r? @nrc
This commit adds functionality that allows the name resolution pass
to search for entities (traits/types/enums/structs) by name, in
order to show recommendations along with the errors.
For now, only E0405 and E0412 have suggestions attached, as per the
request in bug #21221, but it's likely other errors can also benefit
from the ability to generate suggestions.
This commit adds functionality that allows the name resolution pass
to search for entities (traits/types/enums/structs) by name, in
order to show recommendations along with the errors.
For now, only E0405 and E0412 have suggestions attached, as per the
request in bug #21221, but it's likely other errors can also benefit
from the ability to generate suggestions.
