rustc: Use link_section, not wasm_custom_section
This commit transitions definitions of custom sections on the wasm target from
the unstable `#[wasm_custom_section]` attribute to the
already-stable-for-other-targets `#[link_section]` attribute. Mostly the same
restrictions apply as before, except that this now applies only to statics.
Closes#51088
Fix macro parser quadratic complexity in small repeating groups
Observed in #51754, and more easily demonstrated with the following:
```rust
macro_rules! stress {
($($t:tt)+) => { };
}
fn main() {
stress!{
a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a
a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a
a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a
a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a
// ... 65536 copies of "a" total ...
a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a
a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a
a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a
a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a
}
}
```
which takes 50 seconds to compile prior to the fix and <1s after.
I hope this has a visible impact on the compile times for real code. (I think it is most likely to affect incremental TT munchers that deal with large inputs, though it depends on how they are written)
For a fuller description of the performance issue: https://github.com/rust-lang/rust/issues/51754#issuecomment-403242159
---
There is no test (yet) because I'm not sure how easily to measure this for regressions.
This commit transitions definitions of custom sections on the wasm target from
the unstable `#[wasm_custom_section]` attribute to the
already-stable-for-other-targets `#[link_section]` attribute. Mostly the same
restrictions apply as before, except that this now applies only to statics.
Closes#51088
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
resolve: Functions introducing procedural macros reserve a slot in the macro namespace as well
Similarly to https://github.com/rust-lang/rust/pull/52234, this gives us symmetry between internal and external views of a crate, but in this case it's always an error to call a procedural macro in the same crate in which it's defined.
Closes https://github.com/rust-lang/rust/issues/52225
Technically, there are requirements imposed by the LLVM
`AMDGPUTargetMachine` on functions with this ABI (eg, the return type
must be void), but I'm unsure exactly where this should be enforced.
hygiene: Decouple transparencies from expansion IDs
And remove fallback to parent modules during resolution of names in scope.
This is a breaking change for users of unstable macros 2.0 (both procedural and declarative), code like this:
```rust
#![feature(decl_macro)]
macro m($S: ident) {
struct $S;
mod m {
type A = $S;
}
}
fn main() {
m!(S);
}
```
or equivalent
```rust
#![feature(decl_macro)]
macro m($S: ident) {
mod m {
type A = $S;
}
}
fn main() {
struct S;
m!(S);
}
```
stops working due to module boundaries being properly enforced.
For proc macro derives this is still reported as a compatibility warning to give `actix_derive`, `diesel_derives` and `palette_derive` time to fix their issues.
Fixes https://github.com/rust-lang/rust/issues/50504 in accordance with [this comment](https://github.com/rust-lang/rust/issues/50504#issuecomment-399764767).
Implement #[alloc_error_handler]
This to-be-stable attribute is equivalent to `#[lang = "oom"]`. It is required when using the `alloc` crate without the `std` crate. It is called by `handle_alloc_error`, which is in turned called by "infallible" allocations APIs such as `Vec::push`.
find and highlight the `&` or `'_` in `region_name`
Before:
```
--> $DIR/dyn-trait-underscore.rs:18:5
|
LL | fn a<T>(items: &[T]) -> Box<dyn Iterator<Item=&T>> {
- | ----- lifetime `'1` appears in this argument
LL | Box::new(items.iter()) //~ ERROR cannot infer an appropriate lifetime
| ^^^^^^^^^^^^^^^^^^^^^^ cast requires that `'1` must outlive `'static`
```
After:
```
--> $DIR/dyn-trait-underscore.rs:18:5
|
LL | fn a<T>(items: &[T]) -> Box<dyn Iterator<Item=&T>> {
+ | - let's call the lifetime of this reference `'1`
LL | Box::new(items.iter()) //~ ERROR cannot infer an appropriate lifetime
| ^^^^^^^^^^^^^^^^^^^^^^ cast requires that `'1` must outlive `'static`
```
Not intended as the final end point necessarily in any sense. I intentionally left some to-do points to fill in later:
- Does not apply to upvars in closures yet (should be relatively easy)
- Does not handle the case where we can't find a precise match very well
- And of course we can still tweak wording
but shows the basic idea of how to make the `Ty` and `hir::Ty` to find a good spot to highlight.
r? @estebank
cc @davidtwco
This to-be-stable attribute is equivalent to `#[lang = "oom"]`.
It is required when using the alloc crate without the std crate.
It is called by `handle_alloc_error`, which is in turned called
by "infallible" allocations APIs such as `Vec::push`.
clarify why we're suggesting removing semicolon after braced items
Previously (issue #46186, pull-request #46258), a suggestion was added
to remove the semicolon after we fail to parse an item, but issue #51603
complains that it's still insufficiently obvious why. Let's add a note.
Resolves#51603.
Show known meta items in unknown meta items error
This PR adds a label to E0541. It also factors built-in attribute parsing into a submodule of `attr` for ease of future refactoring.
Fixes#51469.
add modifier keyword spans to hir::Visibility; improve unreachable-pub, private-no-mangle lint suggestions
#50455 pointed out that the unreachable-pub suggestion for brace-grouped `use`s was bogus; #50476 partially ameliorated this by marking the suggestion as `Applicability::MaybeIncorrect`, but this is the actual fix.
Meanwhile, another application of having spans available in `hir::Visibility` is found in the private-no-mangle lints, where we can now issue a suggestion to use `pub` if the item has a more restricted visibility marker (this seems much less likely to come up in practice than not having any visibility keyword at all, but thoroughness is a virtue). While we're there, we can also add a helpful note if the item does have a `pub` (but triggered the lint presumably because enclosing modules were private).
r? @nrc
cc @Manishearth
Suggest correct comparison against negative literal
When parsing as emplacement syntax (`x<-1`), suggest the correct syntax
for comparison against a negative value (`x< -1`).
Fix#45651.
Visibility spans were added to the AST in #47799 (d6bdf296) as a
`Spanned<_>`—which means that we need to choose a span even in the case
of inherited visibility (what you get when there's no `pub` &c. keyword
at all). That initial implementation's choice is pretty
counterintuitive, which could matter if we want to use it as a site to
suggest inserting a visibility modifier, &c.
(The phrase "Schelling span" in the comment is meant in analogy to the
game-theoretic concept of a "Schelling point", a value that is chosen
simply because it's what one can expect to agree upon with other agents
in the absence of explicit coördination.)
Previously (issue #46186, pull-request #46258), a suggestion was added
to remove the semicolon after we fail to parse an item, but issue #51603
complains that it's still insufficiently obvious why. Let's add a note.
Resolves#51603.
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
The method relied on the FileMap still being under construction in
order for it to do what the name promises. It's now independent of
the current state.
Namely: labels, type parameters, bindings in patterns, parameter names in functions without body.
All of these do not need hygiene after lowering to HIR, only span locations.
