| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
This reverts commit 9edaa76adce4de737db54194eb13d6c298827b37.
|
|
|
|
|
|
|
|
|
|
TaKO8Ki:use-create-snapshot-for-diagnostic-in-rustc-expand, r=Dylan-DPC
Use `create_snapshot_for_diagnostic` instead of `clone` for `Parser`
Use [`create_snapshot_for_diagnostic`](https://github.com/rust-lang/rust/blob/cd119057160cedea245aa2679add56723f3dc784/compiler/rustc_parse/src/parser/diagnostics.rs#L214-L223) I implemented in https://github.com/rust-lang/rust/pull/94731 instead of `clone` to avoid duplicate unclosed delims errors being emitted when the `Parser` is dropped. I missed this one in #95068.
|
|
|
|
Never regard macro rules with compile_error! invocations as unused
The very point of compile_error! is to never be reached, and one of
the use cases of the macro, currently also listed as examples in the
documentation of compile_error, is to create nicer errors for wrong
macro invocations. Thus, we should never warn about unused macro arms
that contain invocations of compile_error.
See also https://github.com/rust-lang/rust/pull/96150#issuecomment-1126599107 and the discussion after that.
Furthermore, the PR also contains two commits to silence `unused_macro_rules` when a macro has an invalid rule, and to add a test that `unused_macros` does not behave badly in the same situation.
r? `@petrochenkov` as I've talked to them about this
|
|
Prior to this commit, if a macro had any malformed rules, all rules would
be reported as unused, regardless of whether they were used or not.
So we just turn off unused rule checking completely for macros with
malformed rules.
|
|
The very point of compile_error! is to never be reached, and one of
the use cases of the macro, currently also listed as examples in the
documentation of compile_error, is to create nicer errors for wrong
macro invocations. Thus, we shuuld never warn about unused macro arms
that contain invocations of compile_error.
|
|
Stabilize `$$` in Rust 1.63.0
# Stabilization proposal
This PR proposes the stabilization of a subset of `#![feature(macro_metavar_expr)]` or more specifically, the stabilization of dollar-dollar (`$$`).
Tracking issue: #83527
Version: 1.63 (2022-06-28 => beta, 2022-08-11 => stable).
## What is stabilized
```rust
macro_rules! foo {
() => {
macro_rules! bar {
( $$( $$any:tt )* ) => { $$( $$any )* };
}
};
}
fn main() {
foo!();
}
```
## Motivation
For more examples, see the [RFC](https://github.com/markbt/rfcs/blob/macro_metavar_expr/text/0000-macro-metavar-expr.md).
Users must currently resort to a tricky and not so well-known hack to declare nested macros with repetitions.
```rust
macro_rules! foo {
($dollar:tt) => {
macro_rules! bar {
( $dollar ( $any:tt )* ) => { $dollar ( $any )* };
}
};
}
fn main() {
foo!($);
}
```
As seen above, such hack is fragile and makes work with declarative macros much more unpleasant. Dollar-dollar (`$$`), on the other hand, makes nested macros more intuitive.
## What isn't stabilized
`count`, `ignore`, `index` and `length` are not being stabilized due to the lack of consensus.
## History
* 2021-02-22, [RFC: Declarative macro metavariable expressions](https://github.com/rust-lang/rfcs/pull/3086)
* 2021-03-26, [Tracking Issue for RFC 3086: macro metavariable expressions](https://github.com/rust-lang/rust/issues/83527)
* 2022-02-01, [Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/93545)
* 2022-02-25, [[1/2] Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/94368)
* 2022-03-11, [[2/2] Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/94833)
* 2022-03-12, [Fix remaining meta-variable expression TODOs](https://github.com/rust-lang/rust/pull/94884)
* 2019-03-21, [[macro-metavar-expr] Fix generated tokens hygiene](https://github.com/rust-lang/rust/pull/95188)
* 2022-04-07, [Kickstart the inner usage of macro_metavar_expr](https://github.com/rust-lang/rust/pull/95761)
* 2022-04-07, [[macro_metavar_expr] Add tests to ensure the feature requirement](https://github.com/rust-lang/rust/pull/95764)
## Non-stabilized expressions
https://github.com/rust-lang/rust/issues/83527 lists several concerns about some characteristics of `count`, `index` and `length` that effectively make their stabilization unfeasible. `$$` and `ignore`, however, are not part of any discussion and thus are suitable for stabilization.
It is not in the scope of this PR to detail each concern or suggest any possible converging solution. Such thing should be restrained in this tracking issue.
## Tests
This list is a subset of https://github.com/rust-lang/rust/tree/master/src/test/ui/macros/rfc-3086-metavar-expr
* [Ensures that nested macros have correct behavior](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/dollar-dollar-has-correct-behavior.rs)
* [Compares produced tokens to assert expected outputs](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/feature-gate-macro_metavar_expr.rs)
* [Checks the declarations of the feature](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/required-feature.rs)
* [Verifies all possible errors that can occur due to incorrect user input](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/syntax-errors.rs)
## Possible future work
Once consensus is achieved, other nightly expressions can be stabilized.
Thanks ``@markbt`` for creating the RFC and thanks to ``@petrochenkov`` and ``@mark-i-m`` for reviewing the implementations.
|
|
|
|
|
|
The function doesn't need the lifetimes
of the two arguments be bound together.
|
|
|
|
|
|
|
|
This function doesn't *create* a (rules based) macro, it *expands* it.
Thus, the documentation was wrong.
|
|
Implement a lint to warn about unused macro rules
This implements a new lint to warn about unused macro rules (arms/matchers), similar to the `unused_macros` lint added by #41907 that warns about entire macros.
```rust
macro_rules! unused_empty {
(hello) => { println!("Hello, world!") };
() => { println!("empty") }; //~ ERROR: 1st rule of macro `unused_empty` is never used
}
fn main() {
unused_empty!(hello);
}
```
Builds upon #96149 and #96156.
Fixes #73576
|
|
Begin fixing all the broken doctests in `compiler/`
Begins to fix #95994.
All of them pass now but 24 of them I've marked with `ignore HELP (<explanation>)` (asking for help) as I'm unsure how to get them to work / if we should leave them as they are.
There are also a few that I marked `ignore` that could maybe be made to work but seem less important.
Each `ignore` has a rough "reason" for ignoring after it parentheses, with
- `(pseudo-rust)` meaning "mostly rust-like but contains foreign syntax"
- `(illustrative)` a somewhat catchall for either a fragment of rust that doesn't stand on its own (like a lone type), or abbreviated rust with ellipses and undeclared types that would get too cluttered if made compile-worthy.
- `(not-rust)` stuff that isn't rust but benefits from the syntax highlighting, like MIR.
- `(internal)` uses `rustc_*` code which would be difficult to make work with the testing setup.
Those reason notes are a bit inconsistently applied and messy though. If that's important I can go through them again and try a more principled approach. When I run `rg '```ignore \(' .` on the repo, there look to be lots of different conventions other people have used for this sort of thing. I could try unifying them all if that would be helpful.
I'm not sure if there was a better existing way to do this but I wrote my own script to help me run all the doctests and wade through the output. If that would be useful to anyone else, I put it here: https://github.com/Elliot-Roberts/rust_doctest_fixing_tool
|
|
|
|
|
|
|
|
|
|
The code currently ignores the actual delimiter on the RHS and fakes up
a `NoDelim`/`DelimSpan::dummy()` one. This commit changes it to use the
actual delimiter.
The commit also reorders the fields for the `Delimited` variant to match
the `Sequence` variant.
|
|
couple of clippy::perf fixes
|
|
remove function parameters only used in recursion
|
|
couple of clippy::complexity fixes
|
|
Create (unstable) 2024 edition
[On Zulip](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Deprecating.20macro.20scoping.20shenanigans/near/272860652), there was a small aside regarding creating the 2024 edition now as opposed to later. There was a reasonable amount of support and no stated opposition.
This change creates the 2024 edition in the compiler and creates a prelude for the 2024 edition. There is no current difference between the 2021 and 2024 editions. Cargo and other tools will need to be updated separately, as it's not in the same repository. This change permits the vast majority of work towards the next edition to proceed _now_ instead of waiting until 2024.
For sanity purposes, I've merged the "hello" UI tests into a single file with multiple revisions. Otherwise we'd end up with a file per edition, despite them being essentially identical.
````@rustbot```` label +T-lang +S-waiting-on-review
Not sure on the relevant team, to be honest.
|
|
|
|
|
|
|
|
This removes the last use of `<mbe::TokenTree as Clone>`. It also
removes two trivial methods on `Delimited`.
|
|
|
|
|
|
It avoids some unnecessary allocations.
|
|
This is a nice performance win on some crates.
|
|
|
|
The `Lrc` isn't necessary, neither is the `SmallVec`. Performance is
changed negligibly, but the new code is simpler.
|
|
When a `macro_rules! foo { ... }` invocation is compiled the name used
is `foo`, not `macro_rules!`. This is different to all other macro
invocations, and confused me when I was inserted debugging println
statements for macro evaluation.
This commit changes it to `macro_rules` (or just `macro`), which is what
I expected. There are no externally visible changes.
|
|
It was used for deduplicating some errors for legacy code which are mostly deduplicated even without that, but at cost of global mutable state, which is not a good tradeoff.
|
|
Remove explicit delimiter token trees from `Delimited`.
They were introduced by the final commit in #95159 and gave a
performance win. But since the introduction of `MatcherLoc` they are no
longer needed. This commit reverts that change, making the code a bit
simpler.
r? `@petrochenkov`
|
|
They were introduced by the final commit in #95159 and gave a
performance win. But since the introduction of `MatcherLoc` they are no
longer needed. This commit reverts that change, making the code a bit
simpler.
|
|
|
|
r=petrochenkov
Call `compute_locs` once per rule
This fixes the small regressions on `wg-grammar` and `hyper-0.14.18` seen in #95555.
r? `@petrochenkov`
|
|
Currently it's called in `parse_tt` every time a match rule is invoked.
This commit moves it so it's called instead once per match rule, in
`compile_declarative_macro. This is a performance win.
The commit also moves `compute_locs` out of `TtParser`, because there's
no longer any reason for it to be in there.
|
|
In #95555 this was moved out of `parse_tt_inner` and `nameize` into
`compute_locs`. But the next commit will be moving `compute_locs`
outwards to a place that isn't suitable for the missing fragment
identifier checking. So this reinstates the old checking.
|
|
It's a slight performance loss for now, but that will be recouped by the
next commit.
|
|
This commit updates the signatures of all diagnostic functions to accept
types that can be converted into a `DiagnosticMessage`. This enables
existing diagnostic calls to continue to work as before and Fluent
identifiers to be provided. The `SessionDiagnostic` derive just
generates normal diagnostic calls, so these APIs had to be modified to
accept Fluent identifiers.
In addition, loading of the "fallback" Fluent bundle, which contains the
built-in English messages, has been implemented.
Each diagnostic now has "arguments" which correspond to variables in the
Fluent messages (necessary to render a Fluent message) but no API for
adding arguments has been added yet. Therefore, diagnostics (that do not
require interpolation) can be converted to use Fluent identifiers and
will be output as before.
|
