| Age | Commit message (Collapse) | Author | Lines |
|---|
|
... and also proc macro attributes used together with test/bench.
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
`tool_attributes`, `proc_macro_path_invoc`, partially `proc_macro_gen`
|
|
resolve: Some macro resolution refactoring
Work towards completing https://github.com/rust-lang/rust/pull/50911#issuecomment-411605393
The last commit also fixes https://github.com/rust-lang/rust/issues/53269 by not using `def_id()` on `Def::Err` and also fixes https://github.com/rust-lang/rust/issues/53512.
|
|
Fix typos found by codespell.
|
|
resolve_macro_to_def`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Adjust a few fulldeps and pretty-printing tests
Fix rebase
|
|
|
|
|
|
resolve: Implement prelude search for macro paths, implement tool attributes
When identifier is macro path is resolved in scopes (i.e. the first path segment - `foo` in `foo::mac!()` or `foo!()`), scopes are searched in the same order as for non-macro paths - items in modules, extern prelude, tool prelude (see later), standard library prelude, language prelude, but with some extra shadowing restrictions (names from globs and macro expansions cannot shadow names from outer scopes). See the comment in `fn resolve_lexical_macro_path_segment` for more details.
"Tool prelude" currently contains two "tool modules" `rustfmt` and `clippy`, and is searched immediately after extern prelude.
This makes the [possible long-term solution](https://github.com/rust-lang/rfcs/blob/master/text/2103-tool-attributes.md#long-term-solution) for tool attributes exactly equivalent to the existing extern prelude scheme, except that `--extern=my_crate` making crate names available in scope is replaced with something like `--tool=my_tool` making tool names available in scope.
The `tool_attributes` feature is still unstable and `#![feature(tool_attributes)]` now implicitly enables `#![feature(use_extern_macros)]`. `use_extern_macros` is a prerequisite for `tool_attributes`, so their stabilization will happen in the same order.
If `use_extern_macros` is not enabled, then tool attributes are treated as custom attributes (this is temporary, anyway).
Fixes https://github.com/rust-lang/rust/issues/52576
Fixes https://github.com/rust-lang/rust/issues/52512
Fixes https://github.com/rust-lang/rust/issues/51277
cc https://github.com/rust-lang/rust/issues/52269
|
|
Reexport tests without polluting namespaces
This should fix issue #52557.
Basically now we gensym a new name for the test function and reexport that.
That way the test function's reexport name can't conflict because it was impossible for the test author to write it down.
We then use a `use` statement to expose the original name using the original visibility.
|
|
|
|
|
|
resolve/expansion: Implement tool attributes
|
|
|
|
|
|
|
|
|
|
|
|
Improve suggestion for missing fmt str in println
Avoid using `concat!(fmt, "\n")` to improve the diagnostics being
emitted when the first `println!()` argument isn't a formatting string
literal.
Fix #52347.
|
|
|
|
This commit fixes an issue where multiple custom attributes could not be fed
into a custom derive in some situations with the `use_extern_macros` feature
enabled. The problem was that the macro expander didn't consider that it was
making progress when we were deducing that attributes should be lumped in with
custom derive invocations.
The fix applied here was to track in the expander if our attribute is changing
(getting stashed away elsewhere and replaced with a new invocation). If it is
swapped then it's considered progress, otherwise behavior should remain the
same.
Closes #52525
|
|
This commit stabilizes some of the `proc_macro` language feature as well as a
number of APIs in the `proc_macro` crate as [previously discussed][1]. This
means that on stable Rust you can now define custom procedural macros which
operate as attributes attached to items or `macro_rules!`-like bang-style
invocations. This extends the suite of currently stable procedural macros,
custom derives, with custom attributes and custom bang macros.
Note though that despite the stabilization in this commit procedural macros are
still not usable on stable Rust. To stabilize that we'll need to stabilize at
least part of the `use_extern_macros` feature. Currently you can define a
procedural macro attribute but you can't import it to call it!
A summary of the changes made in this PR (as well as the various consequences)
is:
* The `proc_macro` language and library features are now stable.
* Other APIs not stabilized in the `proc_macro` crate are now named under a
different feature, such as `proc_macro_diagnostic` or `proc_macro_span`.
* A few checks in resolution for `proc_macro` being enabled have switched over
to `use_extern_macros` being enabled. This means that code using
`#![feature(proc_macro)]` today will likely need to move to
`#![feature(use_extern_macros)]`.
It's intended that this PR, once landed, will be followed up with an attempt to
stabilize a small slice of `use_extern_macros` just for procedural macros to
make this feature 100% usable on stable.
[1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252
|
|
namespace as well
|
|
|
|
|
|
|
|
|
|
Make FileMap::{lines, multibyte_chars, non_narrow_chars} non-mutable.
This PR removes most of the interior mutability from `FileMap`, which should be beneficial, especially in a multithreaded setting. This is achieved by initializing the state in question when the filemap is constructed instead of during lexing. Hopefully this doesn't degrade performance.
cc @wesleywiser
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
