See #14064 for some rationale, but the basic idea is that I suspect that there
is an LLVM codegen bug somewhere, and I'm not entirely sure why it's happening
intermittently rather than deterministically...
cc #14064
Attribute grammar in reference manual allowed `#[foo, bar]`, which does not match parser behavior.
Also rename nonterminals to match parser code.
Fix#13825.
ty::substs struct. This is a holdover from the olden days of yore. This patch
removes the last vestiges of that practice. This is part of the work
I was doing on #5527.
This was intended as part of the I/O timeouts commit, but it was mistakenly
forgotten. The type of the timeout argument is not guaranteed to remain constant
into the future.
Printing <no-bounds> on trait objects comes from a time when trait
objects had a non-empty default bounds set. As they no longer have any
default bounds, printing <no-bounds> is just noise.
With `~[T]` no longer growable, the `FromIterator` impl for `~[T]` doesn't make
much sense. Not only that, but nearly everywhere it is used is to convert from
a `Vec<T>` into a `~[T]`, for the sake of maintaining existing APIs. This turns
out to be a performance loss, as it means every API that returns `~[T]`, even a
supposedly non-copying one, is in fact doing extra allocations and memcpy's.
Even `&[T].to_owned()` is going through `Vec<T>` first.
Remove the `FromIterator` impl for `~[T]`, and adjust all the APIs that relied
on it to start using `Vec<T>` instead. This includes rewriting
`&[T].to_owned()` to be more efficient, among other performance wins.
Also add a new mechanism to go from `Vec<T>` -> `~[T]`, just in case anyone
truly needs that, using the new trait `FromVec`.
[breaking-change]
The code in resolve erroneously assumed that private enums weren't visited, so
the logic was adjusted to check to see if the enum definition itself was public.
Closes#11680
cindent handles the following case incorrectly:
impl X {
b: int,
//
c: int,
}
if you try and insert a new line after the `c` declaration.
To fix this, fix the get_line_trimmed() function to work properly, and
then extend GetRustIndent to keep searching backwards until it finds a
non-blank line after trimming. This lets it handle the trailing comma
case properly, as if the comment were never there.
Fixes#14041.
As part of #5527 I had to make some changes here and I just couldn't take it anymore. Refactor the writeback code. Should be functionally equivalent to the old stuff.
r? @pcwalton
This code does not belong in libstd, and rather belongs in a dedicated crate. In
the future, the syntax::ext::format module should move to the fmt_macros crate
(hence the name of the crate), but for now the fmt_macros crate will only
contain the format string parser.
The entire fmt_macros crate is marked #[experimental] because it is not meant
for general consumption, only the format!() interface is officially supported,
not the internals.
This is a breaking change for anyone using the internals of std::fmt::parse.
Some of the flags have moved to std::fmt::rt, while the actual parsing support
has all moved to the fmt_macros library.
[breaking-change]
There was no reason to remove them from slice. They're testing methods
defined in slice, so that's where they belong.
Leave vec with copies of the partition/partitioned tests because it has
its own implementation of those methods.
Bring back the Decodable impl for ~[T], this time using FromVec. It's
still not recommended that anyone use this, but at least it's available
if necessary.
Add a new trait FromVec with one self-less method from_vec(). This is
kind of like FromIterator, but it consumes a Vec<T>. It's only
implemented for ~[T], but the idea is post-DST it can be implemented for
any Boxed<[T]>.
API Changes:
- from_base64() returns Result<Vec<u8>, FromBase64Error>
- from_hex() returns Result<Vec<u8>, FromHexError>
- json::List is a Vec<Json>
- Decodable is no longer implemented on ~[T] (but Encodable still is)
- DecoderHelpers::read_to_vec() returns a Result<Vec<T>, E>
A few methods in slice that used to return ~[T] now return Vec<T>:
- VectorVector.concat/connect_vec() returns Vec<T>
- slice::unzip() returns (Vec<T>, Vec<U>)
- ImmutableCloneableVector.partitioned() returns (Vec<T>, Vec<T>)
- OwnedVector.partition() returns (Vec<T>, Vec<T>)
This used to create a Vec<T> and then call .move_iter().collect() to
convert to a ~[T]. We can't do that anymore, so construct the ~[T] in
place instead. This has the added benefit of avoiding an unnecessary
memory copy (from the Vec<T> to the ~[T]).
As part of the shift from ~[T] to Vec<T>, recently ~[T] was made
non-growable. However, the FromIterator implementation for ~[T] was left
intact (albeit implemented inefficiently), which basically provided a
loophole to grow a ~[T] despite its non-growable nature. This is a
problem, both for performance reasons and because it encourages APIs to
continue returning ~[T] when they should return Vec<T>. Removing
FromIterator forces these APIs to adopt the correct type.
Furthermore, during today's weekly meeting it was decided that we should
remove all instances of ~[T] from the standard libraries in favor of
Vec<T>. Removing the FromIterator impl makes sense to do as a result.
This commit only includes the removal of the FromIterator impl. The
subsequent commits involve handling all of the breakage that results,
including changing APIs to use Vec<T> instead of ~[T]. The precise API
changes are documented in the subsequent commit messages, but each
commit is not individually marked as a breaking change.
Finally, a new trait FromVec is introduced that provides a mechanism to
convert Vec<T> back into ~[T] if truly necessary. It is a bit awkward to
use by design, and is anticipated that it will be more useful in a
post-DST world to convert to an arbitrary Foo<[T]> smart pointer.
[breaking-change]
