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
Right now it is not possible to write a `for` loop without opting-in to the
`core` feature due to the way they're expanding (calling
`::std::iter::IntoIterator::into_iter`). There are some planned tweaks to the
`IntoIterator` trait (adding an `Item` associated type) which will cause
implementations of `IntoIterator` to break, but the *usage* of the trait is
currently stable.
This commit marks the method `into_iter` as stable as the name will not be
changing, nor the fact that it takes no arguments and returns one type (which is
determiend by the `Self` type). This means that usage of `for` loops is now
stable but manual implementations of the `IntoIterator` trait will continue to
be unstable.
This is in preparation for stabilization of the `IntoIterator` trait. All
implementations and references to `Iter` need to be renamed to `IntoIter`.
[breaking-change]
#[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]
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.
