The `_match.rs` takes advantage of passes prior to `trans` and
aggressively prunes the sub-match tree based on exact equality. When it
comes to literal or range, the strategy may lead to wrong result if
there's guard function or multiple patterns inside tuple.
Closes#12582.
Closes#13027.
The `_match.rs` takes advantage of passes prior to `trans` and
aggressively prunes the sub-match tree based on exact equality. When it
comes to literal or range, the strategy may lead to wrong result if
there's guard function or multiple patterns inside tuple.
Closes#12582.
Closes#13027.
The previous syntax was `Foo:Bound<trait-parameters>`, but this is a little
ambiguous because it was being parsed as `Foo: (Bound<trait-parameters)` rather
than `Foo: (Bound) <trait-parameters>`
This commit changes the syntax to `Foo<trait-parameters>: Bound` in order to be
clear where the trait parameters are going.
Closes#9265
This change prepares `rustc` to accept private fields by default. These changes will have to go through a snapshot before the rest of the changes can happen.
The previous syntax was `Foo:Bound<trait-parameters>`, but this is a little
ambiguous because it was being parsed as `Foo: (Bound<trait-parameters)` rather
than `Foo: (Bound) <trait-parameters>`
This commit changes the syntax to `Foo<trait-parameters>: Bound` in order to be
clear where the trait parameters are going.
Closes#9265
Add some docs to ExpnInfo. Add a single overlooked `new_span` call to the folder (I'm pretty sure nothing reads this span, though, so it's probably pointless).
This change is in preparation for #8122. Nothing is currently done with these
visibility qualifiers, they are just parsed and accepted by the compiler.
RFC: 0004-private-fields
The problem was that we need to apply the substitution, so that the
formal lifetime parameters get replaced with (unifiable)
free-lifetimes that can actually be fed into the constraint solver.
Also, refactor code os that substitution for `check_item` and
`check_method`, moving both down the control flow into `check_bare_fn`.
----
Finally, there was another (similar) spot where we needed to
substitute early-bound lifetimes when invoking an object method of a
trait.
This bench is meant to exercise libgreen, not libnative. It recently caused the
auto-linux-32-nopt-t bot to fail as no output was produced for an hour.
This was leaving Decls without the new spans; this is a minor change,
since literally nothing reads in the code base reads the span of a Decl
itself, always just its contents.
Apparently we had forgotten to do this for freebsd, causing possible problems
on FreeBSD 10. The discussion in #12324 has some more details about how it's
missing.
The libuv fs wrappers are very thin wrappers around the syscalls they correspond
to, and a notable worrisome case is the write syscall. This syscall is not
guaranteed to write the entire buffer provided, so we may have to continue
calling uv_fs_write if a short write occurs.
Closes#13130
# Summary
Changed `iter::Extendable` and `iter::FromIterator` to take a `Iterator` by value.
These functions always exhaust the passed `Iterator`, and are often used for transferring the values of a new `Iterator` directly into a data structure, so using them usually require the use of the `&mut` operator:
```
foo.extend(&mut bar.move_iter()); // Transfer content from bar into foo
let mut iter = ...;
foo.extend(&mut iter); // iter is now empty
```
This patch changes both the `FromIterator` and `Extendable` traits to take the iterator by value instead, which makes the common case of using these traits less heavy:
```
foo.extend(bar.move_iter()); // Transfer content from bar into foo
let iter = ...;
foo.extend(iter);
// iter is now inaccessible if it moved
// or unchanged if it was Pod and copied.
```
# Composability
This technically makes the traits less flexible from a type system pov, because they now require ownership.
However, because `Iterator` provides the `ByRef` adapter, there is no loss of functionality:
```
foo.extend(iter.by_ref()); // Same semantic as today, for the few situations where you need it.
```
# Motivation
This change makes it less painful to use iterators for shuffling values around between collections, which makes it more acceptable to always use them for this, enabling more flexibility.
For example, `foo.extend(bar.move_iter())` can generally be the fastest way to append an collections content to another one, without both needing to have the same type. Making this easy to use would allow the removal of special cased methods like `push_all()` on vectors. (See https://github.com/mozilla/rust/issues/12456)
I opened https://github.com/mozilla/rust/issues/13038 as well, to discuss this change in general if people object to it.
# Further work
This didn't change the `collect()` method to take by value `self`, nor any of the other adapters that also exhaust their iterator argument. For consistency this should probably happen in the long term, but for now this is too much trouble, as every use of them would need to be checked for accidentally changed semantic by going `&mut self -> self`. (which allows for the possibility that a `Pod` iterator got copied instead of exhausted without generating a type error by the change)
* Include tip given by Leo Testard in mailing list about labeled `break`
and `continue`:
https://mail.mozilla.org/pipermail/rust-dev/2014-March/009145.html
* cross-reference named lifetimes in tutorial -> lifetimes guide
* Broke named lifetimes section into two sub-sections.
* Added mention of `'static` lifetime.
This is not sufficient for finding the library directory for binary
installs, but it does make the build more complex by requiring
env vars be set to build rustc.
The previous dependency calculation was based on an arbitrary set of asterisks
at an arbitrary depth, but using the recursive version should be much more
robust in figuring out what's dependent.
Closes#13118
Rendered form available at http://docs.octayn.net/doc/
This moves derived impls to the bottom of the list, separate from the rest,
and collapses default methods that aren't overridden into an expandible
accordion.
