This same source is being built in the Cargo ecosystem and hence needs to build
on stable Rust as well. This commit places the `no_std` attribute along with the
`no_std` feature behind a `cfg_attr` flag so they are not processed when
compiled on crates.io
This stability attribute was left out by accident and the stability pass has
since picked up the ability to check for this. As a result, crates are currently
getting warnings for implementations of `Index`.
Updates to the bison grammar to account for recent grammar additions and new tests. In particular:
* Support parsing `impl MyTrait for .. { }`
* Support parsing ExprQualifiedPaths without \"as TRAIT_REF\" such as `<Foo>::bar(&Foo)`
* Support parsing \"for\" clauses at the beginning of where clauses such as `where for<'a, 'b> &'a T: Bar<'b>`
Currently, the list of files linted in `tidy.py` is unordered. It seems more appropriate for more frequently appearing files (like `.rs`) to appear at the top of the list and for \"other files\" to appear at the very end. This PR also changes the wildcard import of `check_license()` into an explicit one.
```
Before: After:
* linted 4 .sh files * linted 5034 .rs files
* linted 4 .h files * linted 29 .c files
* linted 29 .c files * linted 28 .py files
* linted 2 .js files * linted 4 .sh files
* linted 0 other files * linted 4 .h files
* linted 28 .py files * linted 2 .js files
* linted 5034 .rs files * linted 0 other files
```
r? @brson
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.
[breaking-change]
The new `io` module has had some time to bake and this commit stabilizes some of
the utilities associated with it. This commit also deprecates a number of
`std::old_io::util` functions and structures.
These items are now `#[stable]`
* `Cursor`
* `Cursor::{new, into_inner, get_ref, get_mut, position, set_position}`
* Implementations of I/O traits for `Cursor<T>`
* Delegating implementations of I/O traits for references and `Box` pointers
* Implementations of I/O traits for primitives like slices and `Vec<T>`
* `ReadExt::bytes`
* `Bytes` (and impls)
* `ReadExt::chain`
* `Chain` (and impls)
* `ReadExt::take` (and impls)
* `BufReadExt::lines`
* `Lines` (and impls)
* `io::copy`
* `io::{empty, Empty}` (and impls)
* `io::{sink, Sink}` (and impls)
* `io::{repeat, Repeat}` (and impls)
These items remain `#[unstable]`
* Core I/O traits. These may want a little bit more time to bake along with the
commonly used methods like `read_to_end`.
* `BufReadExt::split` - this function may be renamed to not conflict with
`SliceExt::split`.
* `Error` - there are a number of questions about its representation,
`ErrorKind`, and usability.
These items are now `#[deprecated]` in `old_io`
* `LimitReader` - use `take` instead
* `NullWriter` - use `io::sink` instead
* `ZeroReader` - use `io::repeat` instead
* `NullReader` - use `io::empty` instead
* `MultiWriter` - use `broadcast` instead
* `ChainedReader` - use `chain` instead
* `TeeReader` - use `tee` instead
* `copy` - use `io::copy` instead
[breaking-change]
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.
us to construct trait-references and do other things without forcing a
full evaluation of the supertraits. One downside of this scheme is that
we must invoke `ensure_super_predicates` before using any construct that
might require knowing about the super-predicates.
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, positions of line-beginnings, etc. but not the actual source code itself.
Crate metadata size is increased by this change because spans in the encoded ASTs take up space now:
```
BEFORE AFTER
libcore 36 MiB 39.6 MiB +10%
libsyntax 51.1 MiB 60.5 MiB +18.4%
libcollections 11.2 MiB 12.8 MiB +14.3%
```
This only affects binaries containing metadata (rlibs and dylibs), executables should not be affected in size.
Fixes#19228 and probably #22226.
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.
The failing concurrency example was doing something different from the
working example. This commit changes just enough of the failing example
to (1) still fail with the same error, (2) tries to do the same as the
working example (increment a vector value and print it).
r? @steveklabnik
This same source is being built in the Cargo ecosystem and hence needs to build
on stable Rust as well. This commit places the `no_std` attribute along with the
`no_std` feature behind a `cfg_attr` flag so they are not processed when
compiled on crates.io
Runway for RFC 809 (overloaded box/placement-in) by adding type annotations or explicit calls to `Box::new` where I found it necessary on PR #22086.
I have broken this up into more than one PR because the entire commit chain (see PR #22086) is long, widespread and unwieldy to rebase frequently.
To my knowledge this is not a breaking change. Also, there is in principle nothing stopping someone from reverting some/all of these annotations, since without the rest of the commit chain in #22086, the associated code would continue to compile.
All I can do is ask: Try to discourage others from removing seemingly "unnecessary" uses of the `Box` type or the `Box::new()` function, until the rest of RFC 809 lands.
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.
This stability attribute was left out by accident and the stability pass has
since picked up the ability to check for this. As a result, crates are currently
getting warnings for implementations of `Index`.
