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
Crate types from multiple sources appear to be deduplicated properly, but not
deduplicated if they come from the command line arguments. At worst, this used
to cause compiler failures when `--crate-type=lib,rlib` (the same as
`--crate-type=rlib,rlib`, at least at the time of this commit) is provided and
generate the output multiple times otherwise.
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.
- c-link-to-rust-staticlib: use EXTRACFLAGS defined by tools.mk for
choose the good libraries to link to.
- no-stack-check: disabled for openbsd (no segmented stacks here)
- symbols-are-reasonable: use portable grep pattern
- target-specs: use POSIX form for options when invoking grep
- use-extern-for-plugins: disable as OpenBSD only support x86_64 for now
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.
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]
