summary refs log tree commit diff
path: root/src/libsyntax_ext/deriving/encodable.rs
AgeCommit message (Collapse)AuthorLines
2016-05-12Improve derived implementations for enums with lots of fieldless variantsBjörn Steinbrink-0/+1
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.
2016-04-26Auto merge of #31414 - durka:clone-copy, r=alexcrichtonbors-1/+1
special-case #[derive(Copy, Clone)] with a shallow clone If a type is Copy then its Clone implementation can be a no-op. Currently `#[derive(Clone)]` generates a deep clone anyway. This can lead to lots of code bloat. This PR detects the case where Copy and Clone are both being derived (the general case of "is this type Copy" can't be determined by a syntax extension) and generates the shallow Clone impl. Right now this can only be done if there are no type parameters (see https://github.com/rust-lang/rust/issues/31085#issuecomment-178988663), but this restriction can be removed after specialization. Fixes #31085.
2016-04-26shallow Clone for #[derive(Copy,Clone)]Alex Burka-1/+1
Changes #[derive(Copy, Clone)] to use a faster impl of Clone when both derives are present, and there are no generics in the type. The faster impl is simply returning *self (which works because the type is also Copy). See the comments in libsyntax_ext/deriving/clone.rs for more details. There are a few types which are Copy but not Clone, in violation of the definition of Copy. These include large arrays and tuples. The very existence of these types is arguably a bug, but in order for this optimization not to change the applicability of #[derive(Copy, Clone)], the faster Clone impl also injects calls to a new function, core::clone::assert_receiver_is_clone, to verify that all members are actually Clone. This is not a breaking change, because pursuant to RFC 1521, any type that implements Copy should not do any observable work in its Clone impl.
2016-04-12prevent other `encode` methods from breaking `derive(RustcEncodable)`Oliver Schneider-7/+10
2016-03-14derive: improve hygiene for type parameters (see #2810)Alex Burka-5/+7
When deriving Hash, RustcEncodable and RustcDecodable, the syntax extension needs a type parameter to use in the inner method. They used to use __H, __S and __D respectively. If this conflicts with a type parameter already declared for the item, bad times result (see the test). There is no hygiene for type parameters, but this commit introduces a better heuristic by concatenating the names of all extant type parameters (and prepending __H).
2016-02-22Fix #[derive] for empty structs with bracesVadim Petrochenkov-1/+1
2016-02-11[breaking-change] don't glob export ast::Mutablity variantsOliver 'ker' Schneider-2/+2
2016-02-11[breaking-change] don't glob export ast::Expr_ variantsOliver Schneider-9/+7
2015-12-15Move built-in syntax extensions to a separate crateSeo Sanghyeon-0/+289