As per [RFC 52](https://github.com/rust-lang/rfcs/blob/master/active/0052-ownership-variants.md), use `_mut` suffixes to mark mutable variants, and `into_iter` for moving iterators. Additional details and motivation in the RFC.
Note that the iterator *type* names are not changed by this RFC; those are awaiting a separate RFC for standardization.
Closes#13660Closes#16810
[breaking-change]
lifetime bounds. This doesn't really cause any difficulties, because
we already had to accommodate the fact that multiple implicit bounds
could accumulate. Object types still require precisely one lifetime
bound. This is a pre-step towards generalized where clauses (once you
have lifetime bounds in where clauses, it is harder to restrict them
to exactly one).
This patch does not make many functional changes, but does a lot of restructuring towards the goals of #5527. This is the biggest patch, basically, that should enable most of the other patches in a relatively straightforward way.
Major changes:
- Do not track impls through trans, instead recompute as needed.
- Isolate trait matching code into its own module, carefully structure to distinguish various phases (selection vs confirmation vs fulfillment)
- Consider where clauses in their more general form
- Integrate checking of builtin bounds into the trait matching process, rather than doing it separately in kind.rs (important for opt-in builtin bounds)
What is not included:
- Where clauses are still not generalized. This should be a straightforward follow-up patch.
- Caching. I did not include much caching. I have plans for various kinds of caching we can do. Should be straightforward. Preliminary perf measurements suggested that this branch keeps compilation times roughly what they are.
- Method resolution. The initial algorithm I proposed for #5527 does not work as well as I hoped. I have a revised plan which is much more similar to what we do today.
- Deref vs deref-mut. The initial fix I had worked great for autoderef, but not for explicit deref.
- Permitting blanket impls to overlap with specific impls. Initial plan to consider all nested obligations before considering an impl to match caused many compilation errors. We have a revised plan but it is not implemented here, should be a relatively straightforward extension.
- Unify the "well-formedness" checking that typeck was already doing with what
was taking place in kind.
- Move requirements that things be sized into typeck.
- I left the checking on upvars in kind, though I think it should eventually be
refactored into regionck (which would perhaps be renamed).
This reflects a general plan to convert typeck so that it registers
obligations or other pending things for conditions it cannot check
eventually. This makes it easier to identify all the conditions that
apply to an AST expression, but can also influence inference in somec
cases (e.g., `Send` implies `'static`, so I already had to promote a lot
of the checking that `kind.rs` was doing into typeck, this branch just
continues the process).
I would like to map this information back to AST nodes, so that we can print remarks with spans, and so that remarks can be enabled on a per-function basis. Unfortunately, doing this would require a lot more code restructuring — for example, we currently throw away the AST map and lots of other information before LLVM optimizations run. So for the time being, we print the remarks with debug location strings from LLVM. There's a warning if you use `-C remark` without `--debuginfo`.
Fixes#17116.
`Box<[T]>` is created by allocating `Box<[T, ..n]>` and coercing it so
this code path is never used. It's also broken because it clamps the
capacity of the memory allocations to 4 elements and that's incompatible
with sized deallocation. This dates back to when `~[T]` was a growable
vector type implemented as:
*{ { tydesc, ref_count, prev, next }, { length, capacity, data[] } }
Since even empty vectors had to allocate, it started off the capacity of
all vectors at 4 as a heuristic. It's not possible to grow `Box<[T]>`
and there is no need for a memory allocation when it's empty, so it
would be a terrible heuristic today even if it worked.
type they provide an implementation for.
This breaks code like:
mod foo {
struct Foo { ... }
}
impl foo::Foo {
...
}
Change this code to:
mod foo {
struct Foo { ... }
impl Foo {
...
}
}
Additionally, if you used the I/O path extension methods `stat`,
`lstat`, `exists`, `is_file`, or `is_dir`, note that these methods have
been moved to the the `std::io::fs::PathExtensions` trait. This breaks
code like:
fn is_it_there() -> bool {
Path::new("/foo/bar/baz").exists()
}
Change this code to:
use std::io::fs::PathExtensions;
fn is_it_there() -> bool {
Path::new("/foo/bar/baz").exists()
}
Closes#17059.
RFC #155.
[breaking-change]
This PR creates a new lint : ``unused_extern_crate``, which do pretty much the same thing as ``unused_import``, but for ``extern crate`` statements. It is related to feature request #10385.
I adapted the code tracking used imports so that it tracks extern crates usage as well. This was mainly trial and error and while I believe all cases are covered, there might be some code I added that is useless (long compile times didn't give me the opportunity to check this in detail).
Also, I removed some unused ``extern crate`` statements from the libs, that where spotted by this new lint.
`Box<[T]>` is created by allocating `Box<[T, ..n]>` and coercing it so
this code path is never used. It's also broken because it clamps the
capacity of the memory allocations to 4 elements and that's incompatible
with sized deallocation. This dates back to when `~[T]` was a growable
vector type implemented as:
*{ { tydesc, ref_count, prev, next }, { length, capacity, data[] } }
Since even empty vectors had to allocate, it started off the capacity of
all vectors at 4 as a heuristic. It's not possible to grow `Box<[T]>`
and there is no need for a memory allocation when it's empty, so it
would be a terrible heuristic today even if it worked.
Avoid ever constructing cyclic types in the first place, rather than detecting them in resolve. This simplifies logic elsewhere in the compiler, in particular on the trait reform branch.
r? @pnkfelix or @pcwalton
cc #5527
The pointer in the slice must not be null, because enum representations
make that assumption. The `exchange_malloc` function returns a non-null
sentinel for the zero size case, and it must not be passed to the
`exchange_free` lang item.
Since the length is always equal to the true capacity, a branch on the
length is enough for most types. Slices of zero size types are
statically special cased to never attempt deallocation. This is the same
implementation as `Vec<T>`.
Closes#14395
This allows code to access the fields of tuples and tuple structs:
let x = (1i, 2i);
assert_eq!(x.1, 2);
struct Point(int, int);
let origin = Point(0, 0);
assert_eq!(origin.0, 0);
assert_eq!(origin.1, 0);
The pointer in the slice must not be null, because enum representations
make that assumption. The `exchange_malloc` function returns a non-null
sentinel for the zero size case, and it must not be passed to the
`exchange_free` lang item.
Since the length is always equal to the true capacity, a branch on the
length is enough for most types. Slices of zero size types are
statically special cased to never attempt deallocation. This is the same
implementation as `Vec<T>`.
Closes#14395
