Added a pretty printer for &mut slices
Fixes#30232
I have added a test which checks for correctness in gdb, but I need some help to do the same for lldb.
r? @Manishearth
Remove redundant `CompileController` entry points
Remove the `after_expand` and `after_write_deps` `CompileController` entry points.
The only things that separate these entry points from `after_hir_lowering` are dep-info generation and HIR map construction, neither of which is computationally intensive or has the potential to error.
r? @nrc
This is a spiritual succesor to #34268/8531d581, in which we replaced a
number of matches of None to the unit value with `if let` conditionals
where it was judged that this made for clearer/simpler code (as would be
recommended by Manishearth/rust-clippy's `single_match` lint). The same
rationale applies to matches of None to the empty block.
std: Stabilize APIs for the 1.11.0 release
Although the set of APIs being stabilized this release is relatively small, the
trains keep going! Listed below are the APIs in the standard library which have
either transitioned from unstable to stable or those from unstable to
deprecated.
Stable
* `BTreeMap::{append, split_off}`
* `BTreeSet::{append, split_off}`
* `Cell::get_mut`
* `RefCell::get_mut`
* `BinaryHeap::append`
* `{f32, f64}::{to_degrees, to_radians}` - libcore stabilizations mirroring past
libstd stabilizations
* `Iterator::sum`
* `Iterator::product`
Deprecated
* `{f32, f64}::next_after`
* `{f32, f64}::integer_decode`
* `{f32, f64}::ldexp`
* `{f32, f64}::frexp`
* `num::One`
* `num::Zero`
Added APIs (all unstable)
* `iter::Sum`
* `iter::Product`
* `iter::Step` - a few methods were added to accomodate deprecation of One/Zero
Removed APIs
* `From<Range<T>> for RangeInclusive<T>` - everything about `RangeInclusive` is
unstable
Closes#27739Closes#27752Closes#32526Closes#33444Closes#34152
cc #34529 (new tracking issue)
Although the set of APIs being stabilized this release is relatively small, the
trains keep going! Listed below are the APIs in the standard library which have
either transitioned from unstable to stable or those from unstable to
deprecated.
Stable
* `BTreeMap::{append, split_off}`
* `BTreeSet::{append, split_off}`
* `Cell::get_mut`
* `RefCell::get_mut`
* `BinaryHeap::append`
* `{f32, f64}::{to_degrees, to_radians}` - libcore stabilizations mirroring past
libstd stabilizations
* `Iterator::sum`
* `Iterator::product`
Deprecated
* `{f32, f64}::next_after`
* `{f32, f64}::integer_decode`
* `{f32, f64}::ldexp`
* `{f32, f64}::frexp`
* `num::One`
* `num::Zero`
Added APIs (all unstable)
* `iter::Sum`
* `iter::Product`
* `iter::Step` - a few methods were added to accomodate deprecation of One/Zero
Removed APIs
* `From<Range<T>> for RangeInclusive<T>` - everything about `RangeInclusive` is
unstable
Closes#27739Closes#27752Closes#32526Closes#33444Closes#34152
cc #34529 (new tracking issue)
Improve code example for try!
This change improves the code example for try!,
avoiding to use try! in the example code that shows
what code constructs try! can replace.
Book: Small grammatical and stylistic edits to book
I've been reading [the book](https://doc.rust-lang.org/book/) and noticed a few small grammatical and stylistic issues which I've rolled into this pull request.
I'm not sure if I should do so many small, unrelated edits in a single pull request but it seems like a lot of overhead for each small edit. Maybe one commit per edit but one pull request per file/section? Feedback is very much appreciated as this is my first pull request ever!
r? @steveklabnik rollup
Build: Shows total time taken to build the compiler
Fixes#34600
Prints the total time taken to build rustc by executing `src/bootstrap/bootstrap.py`; also includes time taken to download `stage0` compiler and deps.
r? @alexcrichton
Support more python 2.7 versions in bootstrap.py
It seems python broke compatability between 2.7.9 and 2.7.12 as on the former a WindowsError was raised while on the latter a subprocess.CalledProcessError was raised while testing for the existence of uname.
As a WindowsError being thrown obviously indicates we're running on windows, this should probably be accepted too.
Release notes for 1.10.0
[Rundered](https://github.com/brson/rust/tree/relnotes/RELEASES.md).
To me highlights look like panic hooks, unix sockets, cargo, and usability improvements.
f? @rust-lang/core @rust-lang/lang @rust-lang/compiler @rust-lang/tools @bstrie
Revert "Remove the return_address intrinsic."
This reverts commit b30134dbc3.
Servo might want this merged if they don't merge servo/servo#11872 soon.
cc @pnkfelix @jdm
fail obligations that depend on erroring obligations
Fix a bug where an obligation that depend on an erroring obligation would
be regarded as successful, leading to global cache pollution and random
lossage.
Fixes#33723.
Fixes#34503.
r? @eddyb since @nikomatsakis is on vacation
beta-nominating because of the massive lossage potential (e.g. with `Copy` this could lead to random memory leaks), plus this is a regression.
Disallow constants and statics from having unsized types.
This is a `[breaking-change]` which fixes#34390 by banning unsized `const` and `static`, e.g.:
```rust
const A: [i32] = *(&[0, 1, 2] as &[i32]);
static B: str = *"foo";
```
This was not intentionally allowed, and other than for `static` since some versions ago, it ICE'd.
If you've been taking advantage of this with `static`, you should be able to just use references instead.
updated proper link of cargo doc that contains details about list of options available in semantic versioninig for the dependencies section in Cargo.toml
Make the metadata lock more robust
Fixes#33778 and friends.
I also needed to add a metadata encoding version to rlibs, as they did not have it before. To keep it backwards-compatible, I added 4 zeroes to the start of the metadata, which are treated as an empty length field by older rustcs.
r? @alexcrichton
previously, only .so files included a metadata encoding version, *outside*
of the zlib compressed area. This adds an encoding version inside the metadata
itself, in both .so and .rlib files.
Fixes#33778.
remove unneeded allow flag
There isn't anything deprecated being used in this function.
This built fine for me locally, but just to be sure, should check Travis.
Fix README.md command consistency
The `./configure` command in README.md's Building Documentation section was missing the `$` prefix. Add the prefix to be consistent with other commands in the document.
rustbuild: Implement testing for Android
This commit enhances the rustbuild support for testing Android to the same level
of parity as the makefiles. This involved:
* A new step to copy the standard library and other shared objects to the
emulator. This is injected as a dependency of all test suites for Android.
* Appropriate arguments are now passed through to compiletest to ensure that it
can run tests.
* When testing the standard library the test executables are probed for and
shipped to the emulator to run for each test.
* Fixing compilation of compiler-rt a bit
All support added here is modeled after what's found in the makefiles, just
translating one strategy to another. As an added bonus this commit adds support
for the "check" step to automatically run tests for all targets, and the
"check-target" step now runs all tests for a particular target, automatically
filtering the tests if the target is detected as a cross-compile.
Note that we don't (and probably won't) have a bot which is actually going to
exercise any of this just yet, but all tests have passed locally for me at
least.
Reject invalid urls in linkchecker
For example root-relative links will now be rejected.
Also remove some exceptions which have since been fixed and fix a typo in
the broken redirect handling.
configure: Check for valid Python on MinGW as well
The LLVM build system is somewhat picky about which Python is used to build it
as it's known to be incompatible with the default `python2` package that ships
with MinGW. This was previously detected for MSVC builds but the logic was left
out for MinGW by accident (now that we've switched to cmake builds for LLVM
everywhere).
This corrects the `./configure` check and also updates the `README.md`
accordingly. Additionally, a number of instructions were updated to work with
the most recent copy of MSYS2.
Closes https://github.com/rust-lang/rust/issues/28260Closes#34489
Ignore unknown address types when looking up hosts
Previously, any function using a `ToSocketAddrs` input would fail if
passed a hostname that resolves to an address type different from the
ones recognized by Rust.
This also changes the `LookupHost` iterator to only include the known
address types, as a result, it doesn't have to return `Result`s any
more, which are likely misinterpreted as failed name lookups.
Fix a bug where an obligation that depend on an erroring obligation would
be regarded as successful, leading to global cache pollution and random
lossage.
Fixes#33723.
Fixes#34503.
hashmap: use siphash-1-3 as default hasher
Also exposes `SipHash13` and `SipHash24` in `core:#️⃣:sip`, for those that want to differentiate.
For motivation, see this quote from the original issue:
> we proposed SipHash-2-4 as a (strong) PRF/MAC, and so far no attack whatsoever has been found,
although many competent people tried to break it. However, fewer rounds may be sufficient and I would
be very surprised if SipHash-1-3 introduced weaknesses for hash tables.
This keeps a type alias of `SipHasher` to `SipHash24`, and since the internal default hasher of HashMap is specified as "not specified", changing it should not be a breaking change.
Closes#29754
mk: Request -march=i686 on i686 Linux
Apparently the gcc on our dist bot is so old and/or obscure that the default
`-m32` switch doesn't think it can generate i686 code (or something like that).
The compiler-rt build system probes for the `__i686__` define in GCC to compile
for an i686 (vs i386) target, so this was failing on the bots.
This tweaks instead to pass `-march=i686` on i686-unknown-linux-gnu to C code to
ensure that we're compiling for i686 instead of i386. This should hopefully not
actually have an impact other than maybe doing some random optimization it
wasn't able to do so before. In theory this isn't making the target less
compatible as all Rust code is already compiled for i686.
Hopefully closes#34572
