This commit deprecates the majority of std::old_io::fs in favor of std::fs and
its new functionality. Some functions remain non-deprecated but are now behind a
feature gate called `old_fs`. These functions will be deprecated once
suitable replacements have been implemented.
The compiler has been migrated to new `std::fs` and `std::path` APIs where
appropriate as part of this change.
This allows to create proper debuginfo line information for items inlined from other crates (e.g. instantiations of generics).
Only the codemap's 'metadata' is stored in a crate's metadata. That is, just filename, line-beginnings, etc. but not the actual source code itself. We are thus missing the opportunity of making Rust the first "open-source-only" programming language out there. Pity.
Many of the modifications putting in `Box::new` calls also include a
pointer to Issue 22405, which tracks going back to `box <expr>` if
possible in the future.
(Still tried to use `Box<_>` where it sufficed; thus some tests still
have `box_syntax` enabled, as they use a mix of `box` and `Box::new`.)
Precursor for overloaded-`box` and placement-`in`; see Issue 22181.
This is the kind of change that one is expected to need to make to
accommodate overloaded-`box`.
----
Note that this is not *all* of the changes necessary to accommodate
Issue 22181. It is merely the subset of those cases where there was
already a let-binding in place that made it easy to add the necesasry
type ascription.
(For unnamed intermediate `Box` values, one must go down a different
route; `Box::new` is the option that maximizes portability, but has
potential inefficiency depending on whether the call is inlined.)
----
There is one place worth note, `run-pass/coerce-match.rs`, where I
used an ugly form of `Box<_>` type ascription where I would have
preferred to use `Box::new` to accommodate overloaded-`box`. I
deliberately did not use `Box::new` here, because that is already done
in coerce-match-calls.rs.
----
Precursor for overloaded-`box` and placement-`in`; see Issue 22181.
Rebase and follow-through on work done by @cmr and @aatch.
Implements most of rust-lang/rfcs#560. Errors encountered from the checks during building were fixed.
The checks for division, remainder and bit-shifting have not been implemented yet.
See also PR #20795
cc @Aatch ; cc @nikomatsakis
Make `test/run-pass/backtrace.rs` more robust about own host environment
Namely, I have been annoyed in the past when I have done `RUST_BACKTRACE=1 make check` only to discover (again) that such a trick causes this test to fail, because it assumes that the `RUST_BACKTRACE` environment variable is not set.
Fix#22870
Associated types are now treated as part of the public API by the privacy checker.
If you were exposing a private type in your public API via an associated type, make that type public:
``` diff
pub struct PublicType { .. }
- struct Struct { .. }
+ pub struct Struct { .. }
pub trait PublicTrait {
type Output;
fn foo(&self) -> Self::Output;
}
impl PublicTrait for PublicType {
type Output = Struct;
fn foo(&self) -> Struct { // `Struct` is part of the public API, it must be marked as `pub`lic
..
}
}
```
[breaking-change]
---
r? @nikomatsakis
closes#22912
The API this exposes is a little strange (being attached to `static`s),
so it makes sense to conservatively feature gate it. If it is highly
popular, it is possible to reverse this gating.
* The lint visitor's visit_ty method did not recurse, and had a
reference to the now closed#10894
* The newly enabled recursion has only affected the `deprectated` lint
which now detects uses of deprecated items in trait impls and
function return types
* Renamed some references to `CowString` and `CowVec` to `Cow<str>` and
`Cow<[T]>`, respectively, which appear outside of the crate which
defines them
* Replaced a few instances of `InvariantType<T>` with
`PhantomData<Cell<T>>`
* Disabled the `deprecated` lint in several places that
reference/implement traits on deprecated items which will get cleaned
up in the future
* Unfortunately, this means that if a library declares
`#![deny(deprecated)]` and marks anything as deprecated, it will have
to disable the lint for any uses of said item, e.g. any impl the now
deprecated item
For any library that denies deprecated items but has deprecated items
of its own, this is a [breaking-change]
I had originally intended for the lint to ignore uses of deprecated items that are declared in the same crate, but this goes against some previous test cases that expect the lint to capture *all* uses of deprecated items, so I maintained the previous approach to avoid changing the expected behavior of the lint.
Tested locally on OS X, so hopefully there aren't any deprecated item uses behind a `cfg` that I may have missed.
1. Detect and report arithmetic overflow during const-expr eval.
2. Instead `eval_const_expr_partial` returning `Err(String)`, it now
has a dedicated enum of different cases. The main benefit of this
is the ability to pass along an interpretable payload, namely the
two inputs that caused an overlfow.
I attempted to minimize fallout to error output in tests, but some was
unavoidable. Those changes are in a follow-on commit.
* The error patterns had a typo.
* Our current constant evaluation would silently allow the overflow
(filed as Issue 22531).
* The overflowing-mul test was accidentally doing addition instead of
multiplication.
Adds overflow checking to integer addition, multiplication, and subtraction
when `-Z force-overflow-checks` is true, or if `--cfg ndebug` is not passed to
the compiler. On overflow, it panics with `arithmetic operation overflowed`.
Also adds `overflowing_add`, `overflowing_sub`, and `overflowing_mul`
intrinsics for doing unchecked arithmetic.
[breaking-change]
Namely, I have been annoyed in the past when I have done
`RUST_BACKTRACE=1 make check` only to discover (again) that such a
trick causes this test to fail, because it assumes that the
`RUST_BACKTRACE` environment variable is not set.
The API this exposes is a little strange (being attached to `static`s),
so it makes sense to conservatively feature gate it. If it is highly
popular, it is possible to reverse this gating.
* count_ones/zeros, trailing_ones/zeros return u32, not usize
* rotate_left/right take u32, not usize
* RADIX, MANTISSA_DIGITS, DIGITS, BITS, BYTES are u32, not usize
Doesn't touch pow because there's another PR for it.
[breaking-change]
* The lint visitor's visit_ty method did not recurse, and had a
reference to the now closed#10894
* The newly enabled recursion has only affected the `deprectated` lint
which now detects uses of deprecated items in trait impls and
function return types
* Renamed some references to `CowString` and `CowVec` to `Cow<str>` and
`Cow<[T]>`, respectively, which appear outside of the crate which
defines them
* Replaced a few instances of `InvariantType<T>` with
`PhantomData<Cell<T>>`
* Disabled the `deprecated` lint in several places that
reference/implement traits on deprecated items which will get cleaned
up in the future
* Disabled the `exceeding_bitshifts` lint for
compile-fail/huge-array-simple test so it doesn't shadow the expected
error on 32bit systems
* Unfortunately, this means that if a library declares
`#![deny(deprecated)]` and marks anything as deprecated, it will have
to disable the lint for any uses of said item, e.g. any impl the now
deprecated item
For any library that denies deprecated items but has deprecated items
of its own, this is a [breaking-change]
Namely, I have been annoyed in the past when I have done
`RUST_BACKTRACE=1 make check` only to discover (again) that such a
trick causes this test to fail, because it assumes that the
`RUST_BACKTRACE` environment variable is not set.
Fix#22870
type-outlives works for closure types so that it ensures that all upvars
outlive the region in question. This gives the same guarantees but
without introducing artificial regions (and gives better error messages
to boot).
This is an implementation of RFC 899 and adds stdio functionality to the new
`std::io` module. Details of the API can be found on the RFC, but from a high
level:
* `io::{stdin, stdout, stderr}` constructors are now available. There are also
`*_raw` variants for unbuffered and unlocked access.
* All handles are globally shared (excluding raw variants).
* The stderr handle is no longer buffered.
* All handles can be explicitly locked (excluding the raw variants).
The `print!` and `println!` machinery has not yet been hooked up to these
streams just yet. The `std::fmt::output` module has also not yet been
implemented as part of this commit.
Check for unbounded recursion during dropck.
Such recursion can be introduced by the erroneous use of non-regular types (aka types employing polymorphic recursion), which Rust does not support.
Fix#22443
This is an implementation of RFC 899 and adds stdio functionality to the new
`std::io` module. Details of the API can be found on the RFC, but from a high
level:
* `io::{stdin, stdout, stderr}` constructors are now available. There are also
`*_raw` variants for unbuffered and unlocked access.
* All handles are globally shared (excluding raw variants).
* The stderr handle is no longer buffered.
* All handles can be explicitly locked (excluding the raw variants).
The `print!` and `println!` machinery has not yet been hooked up to these
streams just yet. The `std::fmt::output` module has also not yet been
implemented as part of this commit.
static_assert is documented as working on static with type `bool`, but
we currently accept it on any const static and crash when the const has
an non-integral type.
This is a breaking-change for anyone who used static_assert on types
likes i32, which happened to work but seems like an unintended
consequence of the missing error checking.
[breaking-change]
Fixes#22056
Fixing #21475. Right now this code can not be parsed:
```rust
use m::{START, END};
fn main() {
match 42u32 {
m::START...m::END => {}, // error: expected one of `::`, `=>`, or `|`, found `...`
_ => {},
}
}
mod m {
pub const START: u32 = 4;
pub const END: u32 = 14;
}
```
I fixed the parser and added test for this case, but now there are still problems with mixing literals and paths in interval:
```rust
match 42u32 {
0u32...m::END => {}, // mismatched types in range [E0031]
m::START...59u32 => {}, // mismatched types in range [E0031]
_ => {},
}
}
```
I'll try fix this problem and need review.
static_assert is documented as working on static with type `bool`, but
we currently accept it on any const static and crash when the const has
an non-integral type.
This is a breaking-change for anyone who used static_assert on types
likes i32, which happened to work but seems like an unintended
consequence of the missing error checking.
[breaking-change]
Fixes#22056
MacEager is a MacResult implementation for the common case where you've already built each form of AST that you might return.
Fixes#17637. Based on #18814.
This is a [breaking-change] for syntax extensions:
* MacExpr::new becomes MacEager::expr.
* MacPat::new becomes MacEager::pat.
* MacItems::new becomes MacEager::items. It takes a SmallVector directly,
not an iterator.
r? @sfackler
