Assign node ids during macro expansion
After this PR,
- The `ExtCtxt` can access `resolve`'s `Resolver` through the trait object `ext::base::Resolver`.
- The `Resolver` trait object can load macros and replaces today's `MacroLoader` trait object.
- The macro expander uses the `Resolver` trait object to resolve macro invocations.
- The macro expander assigns node ids and builds the `Resolver`'s `macros_at_scope` map.
- This is groundwork for merging import resolution and expansion.
- Performance of expansion together with node id assignment improves by ~5%.
**EDIT:** Since Github is reordering the commits, here is `git log`:
- b54e1e399741579612f13e2df98a25ea9447989d: Differentiate between monotonic and non-monotonic expansion and only assign node ids during monotonic expansion.
- 78c00398780db6f59ebf43e765fa9368dad436d2: Expand generated test harnesses and macro registries.
- f3c2dca3539e6edc745f9c91898cb97d281865c1: Remove scope placeholders from the crate root.
- c86c8d41a26b2037e80c9fd028a59313a78b3a66: Perform node id assignment and `macros_at_scope` construction during the `InvocationCollector` and `PlaceholderExpander` folds.
- 72a636975fc5d0bb4af45af7bdd97987cc722a6a: Move macro resolution into `librustc_resolve`.
- 20b43b23230ce063ccf99a4841d85790ad311bdf: Rewrite the unit tests in `ext/expand.rs` as a `compile-fail` test.
- a9821e1658240bb2c056f260a4b6bc9789301fae: Refactor `ExtCtxt` to use a `Resolver` instead of a `MacroLoader`.
- 60440b226d2f70bdae803443ff7ad2e2af2c9b10: Refactor `noop_fold_stmt_kind` out of `noop_fold_stmt`.
- 50f94f6c95c944f08c4af264f48260e42efefd47: Avoid needless reexpansions.
r? @nrc
Fix indeterminism in ty::TraitObject representation.
Make sure that projection bounds in `ty::TraitObject` are sorted in a way that is stable across compilation sessions and crate boundaries.
This PR
+ moves `DefPathHashes` up into `librustc` so it can be used there to create a stable sort key for `DefId`s,
+ changes `PolyExistentialProjection::sort_key()` to take advantage of the above,
+ and removes the unused `PolyProjectionPredicate::sort_key()` and `ProjectionTy::sort_key()` methods.
Fixes#36155
libcompiler-rt.a is dead, long live libcompiler-builtins.rlib
This commit moves the logic that used to build libcompiler-rt.a into a
compiler-builtins crate on top of the core crate and below the std crate.
This new crate still compiles the compiler-rt instrinsics using gcc-rs
but produces an .rlib instead of a static library.
Also, with this commit rustc no longer passes -lcompiler-rt to the
linker. This effectively makes the "no-compiler-rt" field of target
specifications a no-op. Users of `no_std` will have to explicitly add
the compiler-builtins crate to their crate dependency graph *if* they
need the compiler-rt intrinsics. Users of the `std` have to do nothing
extra as the std crate depends on compiler-builtins.
Finally, this a step towards lazy compilation of std with Cargo as the
compiler-rt intrinsics can now be built by Cargo instead of having to
be supplied by the user by some other method.
closes#34400
fix a few errant `Krate` edges
Exploring the effect of small changes on `syntex` reuse, I discovered the following sources of unnecessary edges from `Krate`
r? @michaelwoerister
Across crates only, converting a def-id into its def-key or def-path was
considered a read. This caused spurious reads when computing the symbol
name for some item.
Replace `_, _` with `..` in patterns
This is how https://github.com/rust-lang/rust/issues/33627 looks in action.
Looks especially nice in leftmost/rightmost positions `(first, ..)`/`(.., last)`.
I haven't touched libsyntax intentionally because the feature is still unstable.
This commit is an implementation of [RFC 1681] which adds support to the
compiler for first-class user-define custom `#[derive]` modes with a far more
stable API than plugins have today.
[RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md
The main features added by this commit are:
* A new `rustc-macro` crate-type. This crate type represents one which will
provide custom `derive` implementations and perhaps eventually flower into the
implementation of macros 2.0 as well.
* A new `rustc_macro` crate in the standard distribution. This crate will
provide the runtime interface between macro crates and the compiler. The API
here is particularly conservative right now but has quite a bit of room to
expand into any manner of APIs required by macro authors.
* The ability to load new derive modes through the `#[macro_use]` annotations on
other crates.
All support added here is gated behind the `rustc_macro` feature gate, both for
the library support (the `rustc_macro` crate) as well as the language features.
There are a few minor differences from the implementation outlined in the RFC,
such as the `rustc_macro` crate being available as a dylib and all symbols are
`dlsym`'d directly instead of having a shim compiled. These should only affect
the implementation, however, not the public interface.
This commit also ended up touching a lot of code related to `#[derive]`, making
a few notable changes:
* Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't
sure how to keep this behavior and *not* expose it to custom derive.
* Derive attributes no longer have access to unstable features by default, they
have to opt in on a granular level.
* The `derive(Copy,Clone)` optimization is now done through another "obscure
attribute" which is just intended to ferry along in the compiler that such an
optimization is possible. The `derive(PartialEq,Eq)` optimization was also
updated to do something similar.
---
One part of this PR which needs to be improved before stabilizing are the errors
and exact interfaces here. The error messages are relatively poor quality and
there are surprising spects of this such as `#[derive(PartialEq, Eq, MyTrait)]`
not working by default. The custom attributes added by the compiler end up
becoming unstable again when going through a custom impl.
Hopefully though this is enough to start allowing experimentation on crates.io!
syntax-[breaking-change]
Batch up libsyntax breaking changes
Batch of the following syntax-[breaking-change] changes:
- #35591: Add a field `span: Span` to `ast::Generics`.
- #35618: Remove variant `Mod` of `ast::PathListItemKind` and refactor the remaining variant `ast::PathListKind::Ident` to a struct `ast::PathListKind_`.
- #35480: Change uses of `Constness` in the AST to `Spanned<Constness>`.
- c.f. `MethodSig`, `ItemKind`
- #35728: Refactor `cx.pat_enum()` into `cx.pat_tuple_struct()` and `cx.pat_path()`.
- #35850: Generalize the elements of lists in attributes from `MetaItem` to a new type `NestedMetaItem` that can represent a `MetaItem` or a literal.
- #35917: Remove traits `AttrMetaMethods`, `AttributeMethods`, and `AttrNestedMetaItemMethods`.
- Besides removing imports of these traits, this won't cause fallout.
- Add a variant `Union` to `ItemKind` to future proof for `union` (c.f. #36016).
- Remove inherent methods `attrs` and `fold_attrs` of `Annotatable`.
- Use methods `attrs` and `map_attrs` of `HasAttrs` instead.
r? @Manishearth
