```rust
#[plugin] #[no_link] extern crate bleh;
```
becomes a crate attribute
```rust
#![plugin(bleh)]
```
The feature gate is still required.
It's almost never correct to link a plugin into the resulting library / executable, because it will bring all of libsyntax and librustc with it. However if you really want this behavior, you can get it with a separate `extern crate` item in addition to the `plugin` attribute.
Fixes#21043.
Fixes#20769.
[breaking-change]
This commit is an implementation of [RFC 739][rfc] which adds a new `std::fs`
module to the standard library. This module provides much of the same
functionality as `std::old_io::fs` but it has many tweaked APIs as well as uses
the new `std::path` module.
[rfc]: https://github.com/rust-lang/rfcs/pull/739
This commit is an implementation of [RFC 739][rfc] which adds a new `std::fs`
module to the standard library. This module provides much of the same
functionality as `std::old_io::fs` but it has many tweaked APIs as well as uses
the new `std::path` module.
[rfc]: https://github.com/rust-lang/rfcs/pull/739
#[plugin] #[no_link] extern crate bleh;
becomes a crate attribute
#![plugin(bleh)]
The feature gate is still required.
It's almost never correct to link a plugin into the resulting library /
executable, because it will bring all of libsyntax and librustc with it.
However if you really want this behavior, you can get it with a separate
`extern crate` item in addition to the `plugin` attribute.
Fixes#21043.
Fixes#20769.
[breaking-change]
This allows people to write tools which are drop-in replacements for rustc by implementing `CompilerCalls` and three lines of code, rather than having to copy+paste a bunch of args parsing code.
r? @alexcrichton
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.
This PR moves all `compile-fail` tests that fail at the parsing stage to a `parse-fail` directory, in order to use the tests in the `parse-fail` directory to test if the new LALR parser rejects the same files as the Rust parser. I also adjusted the `testparser.py` script to handle the tests in `parse-fail` differently.
However during working on this, I discovered, that Rust's parser sometimes fails during parsing, but does not return a nonzero return code, e.g. compiling `/test/compile-fail/doc-before-semi.rs` with `-Z parse-only` prints an error message, but returns status code 0. Compiling the same file without `-Z parse-only`, the same error message is displayed, but error code 101 returned. I'll look into that over the next week.
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.
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
