| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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
|
|
zackmdavis:stable_features_warning_notes_version_stabilized, r=brson
stable features lint warning mentions version stabilized
To accomplish this, we alter the checks in `rustc::middle::stability` to
use the `StabilityLevel` defined in `syntax::attr` (which includes the
version in which the feature was stabilized) rather than the local
`StabilityLevel` in the same module, and make the
`declared_stable_lang_features` field of
`syntax::feature_gate::Features` hold a Vec of feature-name, span
tuples (in analogy to the `declared_lib_features` field) rather than
just spans.
Fixes #33394.
r? @brson (tagging Brian because he [wrote](https://github.com/rust-lang/rust/pull/21958) the lint)
|
|
Reject a LHS formed of a single sequence TT during `macro_rules!` checking.
This was already rejected during expansion. Encountering malformed LHS or RHS during expansion is now considered a bug.
Follow up to #33689.
r? @pnkfelix
Note: this can break code that defines such macros but does not use them.
|
|
To accomplish this, we alter the checks in `rustc::middle::stability` to
use the `StabilityLevel` defined in `syntax::attr` (which includes the
version in which the feature was stabilized) rather than the local
`StabilityLevel` in the same module, and make the
`declared_stable_lang_features` field of
`syntax::feature_gate::Features` hold a Vec of feature-name, span
tuples (in analogy to the `declared_lib_features` field) rather than
just spans.
This is in the matter of issue #33394.
|
|
Separate bindings from other patterns in HIR
Now when name resolution is done on AST, we can avoid dumping everything that looks like an identifier into `PatKind::Ident` in HIR.
`hir::PatKind::Ident` is removed, fresh bindings are now called `hir::PatKind::Binding`, everything else goes to `hir::PatKind::Path`.
I intend to do something with `PatKind::Path`/`PatKind::QPath` as well using resolution results, but it requires some audit and maybe some deeper refactoring of relevant resolution/type checking code to do it properly.
I'm submitting this part of the patch earlier to notify interested parties that I'm working on this.
cc @jseyfried
r? @eddyb
|
|
Prevent overflows by increasing ring buffer size
Please note that this change is just done to prevent
issues as currently seen by syntex_syntax in future.
See https://github.com/serde-rs/syntex/pull/47 for details.
As shown in https://github.com/serde-rs/syntex/issues/33,
complex code can easily overflow the ring-buffer and
cause an assertion error.
|
|
Please note that this change is just done to prevent
issues as currently seen by syntex_syntax in future.
See https://github.com/serde-rs/syntex/pull/47 for details.
As shown in https://github.com/serde-rs/syntex/issues/33,
complex code can easily overflow the ring-buffer and
cause an assertion error.
|
|
|
|
Do not inject test harness for --cfg test
Fix #33670.
|
|
|
|
|
|
Apply visit_path to import prefixes by default
Overriding `visit_path` is not enough to visit all paths, some import prefixes are not visited and `visit_path_list_item` need to be overridden as well. This PR removes this catch, it should be less error prone this way. Also, the prefix is visited once now, not repeatedly for each path list item.
r? @eddyb
|
|
r=nikomatsakis
Increase spacing in error format for readability.
Two small tweaks that seem to help readability quite a bit:
* Add spacing header<->snippet, but use the |> on the side for visual consistency
* Fix #33819
* Fix #33763
* Move format-sensitive test (issue-26480 in cfail) to ui test
r? @nikomatsakis
|
|
Perform `cfg` attribute processing during macro expansion and fix bugs
This PR refactors `cfg` attribute processing and fixes bugs. More specifically:
- It merges gated feature checking for stmt/expr attributes, `cfg_attr` processing, and `cfg` processing into a single fold.
- This allows feature gated `cfg` variables to be used in `cfg_attr` on unconfigured items. All other feature gated attributes can already be used on unconfigured items.
- It performs `cfg` attribute processing during macro expansion instead of after expansion so that macro-expanded items are configured the same as ordinary items. In particular, to match their non-expanded counterparts,
- macro-expanded unconfigured macro invocations are no longer expanded,
- macro-expanded unconfigured macro definitions are no longer usable, and
- feature gated `cfg` variables on macro-expanded macro definitions/invocations are now errors.
This is a [breaking-change]. For example, the following would break:
```rust
macro_rules! m {
() => {
#[cfg(attr)]
macro_rules! foo { () => {} }
foo!(); // This will be an error
macro_rules! bar { () => { fn f() {} } }
#[cfg(attr)] bar!(); // This will no longer be expanded ...
fn g() { f(); } // ... so that `f` will be unresolved.
#[cfg(target_thread_local)] // This will be a gated feature error
macro_rules! baz { () => {} }
}
}
m!();
```
r? @nrc
|
|
|
|
Rollup of 10 pull requests
- Successful merges: #33753, #33815, #33829, #33858, #33865, #33866, #33870, #33874, #33891, #33898
- Failed merges:
|
|
Fix ICE on parsing a bad metavariable in a macro definition
Fixes #33569, fixes #33728.
r? @pnkfelix
|
|
This is more idiomatic, putting the caller in charge of whether or not
to panic.
|
|
The AST part of https://github.com/rust-lang/rust/pull/33505.
https://github.com/rust-lang/rust/pull/33505 isn't landed yet, so this PR is based on top of it.
r? @nrc
plugin-[breaking-change] cc #31645 @Manishearth
|
|
cc https://github.com/rust-lang/rust/issues/33627
r? @nikomatsakis
plugin-[breaking-change] cc https://github.com/rust-lang/rust/issues/31645 @Manishearth
|
|
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).
|
|
|
|
|
|
|
|
|
|
`StripUnconfigured`
|
|
|
|
|
|
|
|
|
|
|
|
This was already rejected during expansion. Encountering malformed LHS or RHS during expansion is now considered a bug.
|
|
Cleanup macro expansion and improve diagnostics
Cleanup macro expansion and improve diagnostics. Fixes #33709.
r? @nrc
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Make sure that macros that didn't pass LHS checking are not expanded.
This avoid duplicate errors for things like invalid fragment specifiers, or
parsing errors for ambiguous macros.
|
|
|
|
|
|
This is more idiomatic, putting the caller in charge of whether or not
to panic.
|
|
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 avoids duplicate errors for things like invalid fragment specifiers, or
parsing errors for ambiguous macros. Fixes #29231.
|
|
|
|
another line between errors
|
|
|
