The only thing we really lose is that C-like enums with one variant and a
non-zero discriminant now take up space, but I do not think this is a
common usage. As previously noted, that was mostly there for
transitional compatibility with the pre-adt.rs codebase.
Out goes the extra layer of struct wrapping; the destructedness flag is
added to the end of the struct. This means that, if the struct
previously had alignment padding at the end, the flag will live there
instead of increasing the struct size.
There were three issues effecting the example in the getopts rustdoc:
1. The blockquote was incorrectly formatted. Fixed by switching to using
an explicit markdown code section with ```.
2. The `fail fail_str(f)` would not compile. Fixed by using `fail!()` instead
of `fail`.
3. The line `matches.free[0]` produced a compile error about moving from
an immutable vector. Fix by using `copy`.
Previous year range of 2011-2013 was based on file creation date. The
check_license python script, however, only accepts copyrights starting
in 2012 or later.
There were three issues effecting the example in the getopts rustdoc:
1. The blockquote was incorrectly formatted. Fixed by switching to using
an explicit markdown code section with ```.
2. The `fail fail_str(f)` would not compile. Fixed by using `fail!()` instead
of `fail`.
3. The line `matches.free[0]` produced a compile error about moving from
an immutable vector. Fix by using `copy`.
Without this change, rust-mode doesn't work if 'cl hasn't been required
by something else, apparently. I'm not entirely sure what changed such
that I started seeing this problem instead of not, but maybe the emacs
world has been making progress towards not loading 'cl at runtime if
it's only needed at compile time.
(This change was previously submitted as e93a58d52 and accidentally reverted by ad8b437ad.)
Changes the ad-hoc closure adjustment into using adjustment info instead
of being separately driven from types, and likewise for autoderef.
Also takes care of autoref (the cases we should be seeing in consts,
at least, since we can't be doing method calls which would need the
ref-to-vec mode), which didn't quite work right previously.
However, "dereference" of a newtype isn't handled yet....
Without this change, rust-mode doesn't work if 'cl hasn't been required
by something else, apparently. I'm not entirely sure what changed such
that I started seeing this problem instead of not, but maybe the emacs
world has been making progress towards not loading 'cl at runtime if
it's only needed at compile time.
r?
`log` can polymorphically log anything, but debug!, etc. requires a format string. With this patch you can equivalently write `debug!(foo)` or `debug!("%?", foo)`.
I'm doing this because I was trying to remove `log` (replacing it with nothing, at least temporarily), but there are a number of logging statements that just want to print an arbitrary value and don't care about the format string.
I'm not entirely convinced this is a good change, since it overloads the implementation of these macros and makes their usage slightly more nuanced.
The one thing `log` can still do is polymorphically log anything,
but debug!, etc. require a format string. With this patch
you can equivalently write `debug!(foo)` or `debug!("%?", foo)`
This series of changes moves the representation details of algebraic datatypes (enums, and special cases like structs and tuples and (until they're fully removed) records) from various places around rustc::middle::trans into a single module, to enable future improvements in this area.
r?(@nikomatsakis), and the core developers in general; this seems like a “super-review” kind of change.
Also converts const cast-from-enum, because it used the same routine to
get the discriminant as what's renovated to construct the enums.
Also fixes ICE on struct-like variants as consts, and provides a slightly
less bad ICE for functional-update-like struct expressions in consts.
Note that in the ByValue case (which can't happen? yet?) we're still
effectively bitcasting, I think. So this change adds a way to assert
that that's safe.
Note also, for future reference, that LLVM's instcombine pass will turn
a bitcast into a GEP(0, 0, ...) if possible.
The first is reduced from a case in rustdoc (originally involving an
ARC); the other is related. No committed version has gotten these
wrong, but when I broke them it showed up only in rustdoc; there was
nothing in the test suite (or the compiler!) that failed.
The general issue is that the statics and trans have to agree on order
of evaluation, or else you get use-after-move-out-of errors at runtime.
This change remains separate from the addition of adt.rs, even though
it's necessary for compatibility with pre-trans::adt representation,
to serve as an example of a change to the representation logic.
Later changes on this branch adapt the rest of rustc::middle::trans
to use this module instead of scattered hard-coded knowledge of
representations; a few of them also have improvements or cleanup for
adt.rs (and many added comments) that weren't drastic enough to justify
changing history to move them into this commit.
After the removal of the "restricted keyword" feature in 0c82c00dc4 , there's no longer any difference between parse_ident() and parse_value_ident(), and therefore no difference between parse parse_path_without_tps() and parse_value_path(). I've collapsed all of these, removing the redundant functions and eliminating the need for two higher-order arguments.
Work towards #4846.
- Institute new region defaults where all omitted regions get a fresh lifetime.
- Require explicit region names except in functions.
- Fix a bug in region parameterization inference. I've been putting this off because it will not be important when we remove RP inference in favor of explicit declarations, but then it was blocking this patch.
r? @pcwalton
Two changes:
- The first fixes an inconsistency in coherence whereby extension methods were added to the inherent methods table, but only in cross-crate scenarios. This causes some minor fallout in tests and so forth. In one case (comm) I added inherent and trait methods so as to avoid the need to import traits like `GenericPort` just to use a port.
- The second makes objects not implement the associated trait, as discussed in #5087.
r? @pcwalton
When parsing bytes from a wire, there is a need to parse floating-point bytes to float values ([u8*4] to f32, [u8*8] to f64). This can be done via cast::transmute, but there is no way to do it safely.
It's quite common, so I think I't better to support it in core library.
7.3x speedup in string map search speed on a microbenchmark of pure hashmap
searching against a constant string, due to the lack of allocations.
I ran into a few snags.
1. The way the coherence check is set up, I can't implement `Equiv<@str>` and
`Equiv<~str>` for `&str` simultaneously.
2. I wanted to implement `Equiv<T>` for all `T:Eq` (i.e. every type can be
compared to itself if it implements `Eq`), but the coherence check didn't
like that either.
3. I couldn't add this to the `Map` trait because `LinearMap` needs special
handling for its `Q` type parameter: it must not only implement `Equiv<T>`
but also `Hash` and `Eq`.
4. `find_equiv(&&"foo")` doesn't parse, because of the double ampersand. It has
to be written `find_equiv(& &"foo")`. We can probably just fix this.
Nevertheless, this is a huge win; it should address a major source of
performance problems, including the one here:
http://maniagnosis.crsr.net/2013/02/creating-letterpress-cheating-program.html
Macro invocations with path separators (e.g. foo::bar!()) now produce a sensible error message, rather than an assertion failure. Also added compile-fail test case.
Fixes#5218 ?
I've found that unused imports can often start cluttering a project after a long time, and it's very useful to keep them under control. I don't like how Go forces a compiler error by default and it can't be changed, but I certainly want to know about them so I think that a warn is a good default.
Now that the `unused_imports` lint option is a bit smarter, I think it's possible to change the default level to warn. This commit also removes all unused imports throughout the compiler and libraries (500+).
The only odd things that I ran into were that some `use` statements had to have `#[cfg(notest)]` or `#[cfg(test)]` based on where they were. The ones with `notest` were mostly in core for modules like `cmp` whereas `cfg(test)` was for tests that weren't part of a normal `mod test` module.
These commits remove some obsolete language features, make some highlighting more correct with respect to the language spec, and introduce highlighting for macros, attributes, core traits, and the new region syntax.
This is an implementation of a map and set for integer keys. It's an ordered container (by byte order, which is sorted order for integers and byte strings when done in the right direction) with O(1) worst-case lookup, removal and insertion. There's no rebalancing or rehashing so it's actually O(1) without amortizing any costs.
The fanout can be adjusted in multiples of 2 from 2-ary through 256-ary, but it's hardcoded at 16-ary because there isn't a way to expose that in the type system yet. To keep things simple, it also only allows `uint` keys, but later I'll expand it to all the built-in integer types and byte arrays.
There's quite a bit of room for performance improvement, along with the boost that will come with dropping the headers on `Owned` `~` and getting rid of the overhead from the stack switches to the allocator. It currently does suffix compression for a single node and then splits into two n-ary trie nodes, which could be replaced with an array for at least 4-8 suffixes before splitting it. There's also the option of doing path compression, which may be a good or a bad idea and depends a lot on the data stored.
I want to share the test suite with the other maps so that's why I haven't duplicated all of the existing integer key tests in this file. I'll send in another pull request to deal with that.
Current benchmark numbers against the other map types:
TreeMap:
Sequential integers:
insert: 0.798295
search: 0.188931
remove: 0.435923
Random integers:
insert: 1.557661
search: 0.758325
remove: 1.720527
LinearMap:
Sequential integers:
insert: 0.272338
search: 0.141179
remove: 0.190273
Random integers:
insert: 0.293588
search: 0.162677
remove: 0.206142
TrieMap:
Sequential integers:
insert: 0.0901
search: 0.012223
remove: 0.084139
Random integers:
insert: 0.392719
search: 0.261632
remove: 0.470401
@graydon is using an earlier version of this for the garbage collection implementation, so that's why I added this to libcore. I left out the `next` and `prev` methods *for now* because I just wanted the essentials first.
My merges for #5143 missed a couple other copies. This patch corrects this, and gets stage0 to compile libsyntax with `#[deny(vecs_implicitly_copyable)]`. stage1 still fails though.
