| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This avoids some allocations.
|
|
`create_matches` creates a `Vec<Rc<Vec<NamedMatch>>>`. Even though all the
inner `Vec`s are empty, each one is created separately.
This commit changes `create_matches` so it instead creates one empty inner
`Vec`, and shares it.
The commit also changes `MatcherPos::matches` to a boxed slice, because its
length doesn't change.
|
|
|
|
|
|
|
|
Suggest to remove prefix `b` in cfg attribute lint string
Closes #54926
r? @estebank
|
|
Remove redundant clone (2)
|
|
List allowed tokens after macro fragments
Fix #34069.
|
|
Point at macro definition when no rules expect token
Fix #35150.
|
|
Macro diagnostics tweaks
Fix #30128, fix #10951 by adding an appropriate span to the diagnostic.
Fix #26288 by suggesting adding semicolon to macro call.
|
|
|
|
|
|
|
|
Accept `Option<Box<$t:ty>>` in macro argument
Given the following code, compile successfuly:
```
macro_rules! test {
(
fn fun() -> Option<Box<$t:ty>>;
) => {
fn fun(x: $t) -> Option<Box<$t>>
{ Some(Box::new(x)) }
}
}
test! {
fn fun() -> Option<Box<i32>>;
}
```
Fix #25274.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
A very minor issue, `lifetime` was missing from the error list.
I left `literal` in the list, even though it is unstable. It looks like it may stabilize soon anyways.
|
|
Given the following code, compile successfuly:
```
macro_rules! test {
(
fn fun() -> Option<Box<$t:ty>>;
) => {
fn fun(x: $t) -> Option<Box<$t>>
{ Some(Box::new(x)) }
}
}
test! {
fn fun() -> Option<Box<i32>>;
}
```
|
|
make `Parser::parse_foreign_item()` return a foreign item or error
Fixes `Parser::parse_foreign_item()` to follow the convention of `parse_trait_item()` and `parse_impl_item()` in that it *must* parse an item or return an error, and then the caller is responsible for detecting the closing delimiter.
This prevents it from looping endlessly on an unexpected token in `ext/expand.rs` where it was also leaking memory by continually pushing to `Parser::expected_tokens` via `Parser::check_keyword()`.
closes #54441
r? @petrochenkov
cc @dtolnay
|
|
resolve: Some refactorings in preparation for uniform paths 2.0
The main result is that in-scope resolution performed during macro expansion / import resolution is now consolidated in a single function (`fn early_resolve_ident_in_lexical_scope`), which can now be used for resolving first import segments as well when uniform paths are enabled.
r? @ghost
|
|
closes #54441
|
|
The restrictions were introduced in https://github.com/rust-lang/rust/pull/54277 and no longer necessary now because legacy plugins are now expanded in usual left-to-right order
|
|
`proc_macro_hygiene` gate.
|
|
Track whether module declarations are inline (fixes #12590)
To track whether module declarations are inline I added a field `inline: bool` to `ast::Mod`. The main use case is for pretty to know whether it should render the items associated with the module, but perhaps there are use cases for this information to not be forgotten in the AST.
|
|
|
|
Remove usages of span_suggestion without Applicability
Use `Applicability::Unspecified` for all of them instead.
Shall deprecations for the non-`_with_applicability` functions be added?
Shall clippy be addressed somehow?
r? @estebank
|
|
|
|
Also fix some formatting along the way.
|
|
Use Applicability::Unspecified for all of them instead.
|
|
... and also proc macro attributes used together with test/bench.
|
|
|
|
Invocation/expansion ID (aka `Mark`) is not really necessary for resolving a macro path.
What is really necessary is its parent module, parent expansion and parent legacy scope.
This is required for validation resolutions of built-in attributes, which don't get their own `Mark`s
|
|
Feature gate non-builtin attributes in inner attribute position
Closes item 3 from https://github.com/rust-lang/rust/pull/50911#issuecomment-411605393
|
|
|
|
|
|
|
|
proc_macro::Group::span_open and span_close
Before this addition, every delimited group like `(`...`)` `[`...`]` `{`...`}` has only a single Span that covers the full source location from opening delimiter to closing delimiter. This makes it impossible for a procedural macro to trigger an error pointing to just the opening or closing delimiter. The Rust compiler does not seem to have the same limitation:
```rust
mod m {
type T =
}
```
```console
error: expected type, found `}`
--> src/main.rs:3:1
|
3 | }
| ^
```
On that same input, a procedural macro would be forced to trigger the error on the last token inside the block, on the entire block, or on the next token after the block, none of which is really what you want for an error like above.
This commit adds `group.span_open()` and `group.span_close()` which access the Span associated with just the opening delimiter and just the closing delimiter of the group. Relevant to Syn as we implement real error messages for when parsing fails in a procedural macro: https://github.com/dtolnay/syn/issues/476.
```diff
impl Group {
fn span(&self) -> Span;
+ fn span_open(&self) -> Span;
+ fn span_close(&self) -> Span;
}
```
Fixes #48187
r? @alexcrichton
|
|
|
|
|
|
|
|
|
|
|
|
|
|
use String::new() instead of String::from(""), "".to_string(), "".to_owned() or "".into()
|
|
Use optimized SmallVec implementation
This PR replaces current SmallVec implementation with the one from the Servo project.
Closes https://github.com/rust-lang/rust/issues/51640
r? @Mark-Simulacrum
|
|
or "".into()
|
