Fixes#21833.
[breaking-change]
r? @alexcrichton
The tests in #21912 will also need `#[feature(no_std)]`. If you're okay with both PRs, I can merge and test them.
When self.start > self.end, these iterators simply return None,
so we adjust the size_hint to just return zero in this case.
Certain optimizations can be implemented in and outside libstd if we
know we can trust the size_hint for all inputs to for example
Range<usize>.
This corrects the ExactSizeIterator implementations, which IMO were
unsound and incorrect previously, since they allowed a range like (2..1)
to return a size_hint of -1us in when debug assertions are turned off.
make `for PAT in ITER_EXPR { ... }` a terminating-scope for ITER_EXPR.
In effect, temporary anonymous values created during the evaluation of ITER_EXPR no longer not live for the entirety of the block surrounding the for-loop; instead they only live for the extent of the for-loop itself, and no longer.
----
There is one case I know of that this breaks, demonstrated to me by @nikomatsakis (but it is also a corner-case that is useless in practice). Here is that case:
```
fn main() {
let mut foo: Vec<&i8> = Vec::new();
for i in &[1, 2, 3] { foo.push(i) }
}
```
Note that if you add any code following the for-loop above, or even a semicolon to the end of it, then the code will stop compiling (i.e., it gathers a vector of references but the gathered vector cannot actually be used.)
(The above code, despite being useless, did occur in one run-pass test by accident; that test is updated here to accommodate the new striction.)
----
So, technically this is a:
[breaking-change]
Makes the compilation abort when a parse error is encountered while
trying to parse an item in an included file. The previous behaviour was
to stop processing the file when a token that can't start an item was
encountered, without producing any error. Fixes#21146.
Revised version of PR #21930.
Restrictions on moves into and out-from fixed-length arrays.
(There was only one use of this "feature" in the compiler source.)
Note 1: the change to the error message in tests/compile-fail/borrowck-use-in-index-lvalue.rs, where we now report that *w is uninitialized (rather than w), was unintended fallout from the implementation strategy used here. The change appears harmless to me, but I welcome advice on how to bring back the old message, which was slightly cleaner (i.e. less unintelligible) since that the syntactic form *w does not actually appear in the source text.
Note 2: the move out-from restriction to only apply to expr[i], and not destructuring bind (e.g. f([a, b, c]: Array) { ... }) since the latter is compatible with nonzeroing drop, AFAICT.
[breaking-change]
Note that the change to the error message in
borrowck-use-in-index-lvalue.rs, where we report that `*w` is
uninitialized rather than `w`, was unintended fallout from the
implementation strategy used here.
The change appears harmless to me, but I welcome advice on how to
bring back the old message, which was slightly cleaner (i.e. less
unintelligible).
----
drive-by: revise compile-fail/borrowck-vec-pattern-move-tail to make
it really clear that there is a conflict that must be signaled.
(A hypothetical future version of Rust might be able to accept the
prior version of the code, since the previously updated index was not
actually aliased.)
No longer legal: `fn foo(a: [D; 5]) { drop(a); a[2] = D::new(); }`;
one must first initialize the entirety of `a` before assigning to its
individual elements.
No longer legal: `fn foo(arr: [D; 5]) -> D { arr[2] }`, unless `D`
implements `Copy`. This "move out-from" restriction only affects
`expr[i]`, and not destructuring (e.g. `f([a, b, c]: Array) { ... }`).
uses mem_categorization to distinguish destructuring-bind from array
indexing.
See discussion on RFC PR 533.
[breaking-change]
The compiler would previously fall back to using `-L` and normal lookup paths if
a `--extern` path was specified but it did not match (wrong architecture, for
example). This commit removes this behavior and forces the hand of the crate
loader to *always* use the `--extern` path if specified, no matter whether it is
correct or not.
This fixes a bug today where the compiler's own libraries are favored in cross
compilation by accident. For example when a crate using the crates.io version of
`log` was cross compiled, Cargo would compile `log` for the target architecture.
When loading the macros, however, the compiler currently favors using the *host*
architecture (for plugins), and because the `--extern log=...` pointed at an
rlib for the target architecture, that lookup failed. The crate loader then
fell back on `-L` paths to find the compiler-used `log` crate (the wrong one!)
and then a compile failure happened because the logging macros are slightly
different.
Add special error for this case and help message `please recompile this crate using --crate-type lib`, also list found candidates.
See issue #14416
r? @alexcrichton
closes#21630
Overloaded indexing (`&[mut] foo[bar]`) only works when `<Self as Index>::Output` is the same as `<Self as IndexMut>::Output` (see issue above). To restrict implementations of `IndexMut` that doesn't work, this PR makes `IndexMut` a supertrait over `Index`, i.e. `trait IndexMut<I>: Index<I>`, just like in the `trait DerefMut: Deref` case.
This breaks all downstream implementations of `IndexMut`, in most cases this simply means removing the `type Output = ..` bit, which is now redundant, from `IndexMut` implementations:
``` diff
impl Index<Foo> for Bar {
type Output = Baz;
..
}
impl IndexMut<Foo> for Bar {
- type Output = Baz;
..
}
```
[breaking-change]
---
r? @nikomatsakis
are any where-clauses at all. This seems to be the simplest possible
rule and will (hopefully!) put an end to these annoying "cache leak"
bugs. Fixes#22019.
The compiler would previously fall back to using `-L` and normal lookup paths if
a `--extern` path was specified but it did not match (wrong architecture, for
example). This commit removes this behavior and forces the hand of the crate
loader to *always* use the `--extern` path if specified, no matter whether it is
correct or not.
This fixes a bug today where the compiler's own libraries are favored in cross
compilation by accident. For example when a crate using the crates.io version of
`log` was cross compiled, Cargo would compile `log` for the target architecture.
When loading the macros, however, the compiler currently favors using the *host*
architecture (for plugins), and because the `--extern log=...` pointed at an
rlib for the target architecture, that lookup failed. The crate loader then
fell back on `-L` paths to find the compiler-used `log` crate (the wrong one!)
and then a compile failure happened because the logging macros are slightly
different.
New functions, `slice::from_raw_parts` and `slice::from_raw_parts_mut`,
are added to implement the lifetime convention as agreed in rust-lang/rfcs#556.
The functions `slice::from_raw_buf` and `slice::from_raw_mut_buf` are
left deprecated for the time being.
Holding back on changing the signature of `std::ffi::c_str_to_bytes` as consensus in rust-lang/rfcs#592 is building to replace it with a composition of other functions.
Contribution to #21923.
If you were still using `MaybeOwnedVector`, update your code to use `CowVec`.
[breaking-change]
---
We already removed `MaybeOwned` (the string equivalent) long time ago and with a much shorter deprecation period. It's time to let go.
The word is repeated twice in the message like:
error: obsolete syntax: `:`, `&mut:`, or `&:` syntax
This removes the word syntax that appears in messages after the second colon (:).
