| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
ExpnInfo/MacroBacktrace/DiagnosticSpanMacroExpansion
We have to deal with dummy spans anyway
Remove def-site span from expander interfaces.
It's not used by the expansion infra, only by specific expanders, which can keep it themselves if they want it.
|
|
|
|
|
|
|
|
|
|
|
|
It's a less powerful duplicate of `SyntaxExtension::NormalTT`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Combine all builtin early lints
This also adds a -Z no-interleave-lints option to allow benchmarking lints.
r? @estebank
|
|
|
|
|
|
|
|
Use a function to access the Hir map to be able to turn it into a query later
r? @eddyb
|
|
attributes
|
|
|
|
|
|
|
|
|
|
test/linkage-visibility: Ignore on musl targets
DynamicLibrary uses libc's dlsym() function internally to find symbols.
Some implementations of dlsym(), like musl's, only look at dynamically-
exported symbols, as found in shared libraries. To also export symbols
from the main executable, pass --export-dynamic to the linker.
(Plus see [here](https://stackoverflow.com/questions/4184017) and [here](https://stackoverflow.com/questions/6121838) for examples of where this is necessary on glibc as well.)
|
|
DynamicLibrary uses libc's dlsym() function internally to find symbols.
Some implementations of dlsym(), like musl's, only look at dynamically-
exported symbols, as found in shared libraries. To also export symbols
from the main executable, we would need to pass --export-dynamic to the
linker. Since this flag isn't available everywhere, ignore the test for
now.
|
|
|
|
|
|
rustc: Allow `#[no_mangle]` anywhere in a crate
This commit updates the compiler to allow the `#[no_mangle]` (and
`#[export_name]` attributes) to be located anywhere within a crate.
These attributes are unconditionally processed, causing the compiler to
always generate an exported symbol with the appropriate name.
After some discussion on #54135 it was found that not a great reason
this hasn't been allowed already, and it seems to match the behavior
that many expect! Previously the compiler would only export a
`#[no_mangle]` symbol if it were *publicly reachable*, meaning that it
itself is `pub` and it's otherwise publicly reachable from the root of
the crate. This new definition is that `#[no_mangle]` *is always
reachable*, no matter where it is in a crate or whether it has `pub` or
not.
This should make it much easier to declare an exported symbol with a
known and unique name, even when it's an internal implementation detail
of the crate itself. Note that these symbols will persist beyond LTO as
well, always making their way to the linker.
Along the way this commit removes the `private_no_mangle_functions` lint
(also for statics) as there's no longer any need to lint these
situations. Furthermore a good number of tests were updated now that
symbol visibility has been changed.
Closes #54135
|
|
This commit updates the compiler to allow the `#[no_mangle]` (and
`#[export_name]` attributes) to be located anywhere within a crate.
These attributes are unconditionally processed, causing the compiler to
always generate an exported symbol with the appropriate name.
After some discussion on #54135 it was found that not a great reason
this hasn't been allowed already, and it seems to match the behavior
that many expect! Previously the compiler would only export a
`#[no_mangle]` symbol if it were *publicly reachable*, meaning that it
itself is `pub` and it's otherwise publicly reachable from the root of
the crate. This new definition is that `#[no_mangle]` *is always
reachable*, no matter where it is in a crate or whether it has `pub` or
not.
This should make it much easier to declare an exported symbol with a
known and unique name, even when it's an internal implementation detail
of the crate itself. Note that these symbols will persist beyond LTO as
well, always making their way to the linker.
Along the way this commit removes the `private_no_mangle_functions` lint
(also for statics) as there's no longer any need to lint these
situations. Furthermore a good number of tests were updated now that
symbol visibility has been changed.
Closes #54135
|
|
`proc_macro_hygiene` gate.
|
|
|
|
|
|
|
|
Prefer `.nth(n)` over `.skip(n).next()`.
Found by clippy.
|
|
Found by clippy.
|
|
|
|
Stabilize macro_vis_matcher
This PR should stabilize [macro_vis_matcher](https://github.com/rust-lang/rust/issues/41022) feature.
- [ ] "reference" book changes: https://github.com/rust-lang-nursery/reference/pull/400
- [ ] "Rust by example" book changes: https://github.com/rust-lang/rust-by-example/pull/1096
- [ ] "clippy" changes: https://github.com/rust-lang-nursery/rust-clippy/pull/3055
r? @cramertj
|
|
|
|
|
|
|
|
is enabled
Do not mark all builtin attributes as used when macro modularization is enabled
|
|
|
|
|
|
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
|
|
|
|
|
