| Age | Commit message (Collapse) | Author | Lines |
|---|
|
`syntax_expand` -> `rustc_expand`
`syntax_pos` -> `rustc_span`
`syntax_ext` -> `rustc_builtin_macros`
|
|
|
|
|
|
This is done by moving some data definitions to syntax::expand.
|
|
(Or more precisely, a pair of such traits: one for `derive(PartialEq)` and one
for `derive(Eq)`.)
((The addition of the second marker trait, `StructuralEq`, is largely a hack to
work-around `fn (&T)` not implementing `PartialEq` and `Eq`; see also issue
rust-lang/rust#46989; otherwise I would just check if `Eq` is implemented.))
Note: this does not use trait fulfillment error-reporting machinery; it just
uses the trait system to determine if the ADT was tagged or not. (Nonetheless, I
have kept an `on_unimplemented` message on the new trait for structural_match
check, even though it is currently not used.)
Note also: this does *not* resolve the ICE from rust-lang/rust#65466, as noted
in a comment added in this commit. Further work is necessary to resolve that and
other problems with the structural match checking, especially to do so without
breaking stable code (adapted from test fn-ptr-is-structurally-matchable.rs):
```rust
fn r_sm_to(_: &SM) {}
fn main() {
const CFN6: Wrap<fn(&SM)> = Wrap(r_sm_to);
let input: Wrap<fn(&SM)> = Wrap(r_sm_to);
match Wrap(input) {
Wrap(CFN6) => {}
Wrap(_) => {}
};
}
```
where we would hit a problem with the strategy of unconditionally checking for
`PartialEq` because the type `for <'a> fn(&'a SM)` does not currently even
*implement* `PartialEq`.
----
added review feedback:
* use an or-pattern
* eschew `return` when tail position will do.
* don't need fresh_expansion; just add `structural_match` to appropriate `allow_internal_unstable` attributes.
also fixed example in doc comment so that it actually compiles.
|
|
|
|
For naming consistency with everything else in this area
|
|
|
|
infrastructure to elsewhere
|
|
|
|
MetaItem.span was always equivalent
|
|
|
|
Most involving `Symbol::intern` on string literals.
|
|
|
|
|
|
|
|
Provide better names for builtin deriving-generated attributes
First attempt at fixing #49967
Not in love with any choices here, don't be shy if you aren't happy with anything :)
I've tested that this produces nicer names in documentation, and that it no longer has issues conflicting with constants with the same name. (I guess we _could_ make a test for that... unsure if that would be valuable)
In all cases I took the names from the methods as declared in the relevant trait.
In some cases I had to prepend the names with _ otherwise there were errors about un-used variables. I'm uneasy with the inconsistency... do they all need to be like that? Is there a way to generate an alternate impl or use a different name (`_`?) in the cases where the arguments are not used?
Lastly the gensym addition to Ident I implemented largely as suggested, but I want to point out it's a little circuitous (at least, as far as I understand it). `cx.ident_of(name)` is just `Ident::from_str`, so we create an Ident then another Ident from it. `Ident::with_empty_ctxt(Symbol::gensym(string))` may or may not be equivalent, I don't know if it's important to intern it _then_ gensym it. It seems like either we could use that, or if we do want a new method to make this convenient, it could be on Ident instead (`from_str_gensymed`?)
|
|
|
|
|
|
|
|
|
|
|
|
Like #43008 (f668999), but _much more aggressive_.
|
|
|
|
|
|
Most of the Rust community agrees that the vec! macro is clearer when
called using square brackets [] instead of regular brackets (). Most of
these ocurrences are from before macros allowed using different types of
brackets.
There is one left unchanged in a pretty-print test, as the pretty
printer still wants it to have regular brackets.
|
|
|
|
|
|
|
|
A number of trait methods like PartialEq::eq or Hash::hash don't
actually need a distinct arm for each variant, because the code within
the arm only depends on the number and types of the fields in the
variants. We can easily exploit this fact to create less and better
code for enums with multiple variants that have no fields at all, the
extreme case being C-like enums.
For nickel.rs and its by now infamous 800 variant enum, this reduces
optimized compile times by 25% and non-optimized compile times by 40%.
Also peak memory usage is down by almost 40% (310MB down to 190MB).
To be fair, most other crates don't benefit nearly as much, because
they don't have as huge enums. The crates in the Rust distribution that
I measured saw basically no change in compile times (I only tried
optimized builds) and only 1-2% reduction in peak memory usage.
|
|
Using the same logic as for `PartialEq`, when possible define only
`partial_cmp` and leave `lt, le, gt, ge` to their default
implementations. This works well for c-like enums.
|
|
Also detect unit structs and enums with zero field struct variants.
|
|
`ne` is completely symmetrical with the method `eq`, and we can save
rust code size and compilation time here if we only emit one of them
when possible.
One case where it's easy to recognize is when it's a C-like enum. Most
other cases can not omit ne, because any value field may have a custom
PartialEq implementation.
|
|
|
|
|
