fix function arguments in constant promotion
we can't create the target block until *after* we promote the arguments - otherwise the arguments will be promoted into the target block. oops.
Fixes#38985.
This is a regression introduced in the beta-nominated #38833, so beta-nominating this one too (sorry @brson).
r? @eddyb
rustbuild: Don't enable debuginfo in rustc
In #37280 we enabled line number debugging information in release artifacts,
primarily to close out #36452 where debugging information was critical for MSVC
builds of Rust to be useful in production. This commit, however, apparently had
some unfortunate side effects.
Namely it was noticed in #37477 that if `RUST_BACKTRACE=1` was set then any
compiler error would take a very long time for the compiler to exit. The cause
of the problem here was somewhat deep:
* For all compiler errors, the compiler will `panic!` with a known value. This
tears down the main compiler thread and allows cleaning up all the various
resources. By default, however, this panic output is suppressed for "normal"
compiler errors.
* When `RUST_BACKTRACE=1` was set this caused every compiler error to generate a
backtrace.
* The libbacktrace library hits a pathological case where it spends a very long
time in its custom allocation function, `backtrace_alloc`, because the
compiler has so much debugging information. More information about this can be
found in #29293 with a summary at the end of #37477.
To solve this problem this commit simply removes debuginfo from the compiler but
not from the standard library. This should allow us to keep #36452 closed while
also closing #37477. I've measured the difference to be orders of magnitude
faster than it was before, so we should see a much quicker time-to-exit after a
compile error when `RUST_BACKTRACE=1` is set.
Closes#37477Closes#37571
we can't create the target block until *after* we promote the arguments
- otherwise the arguments will be promoted into the target block. oops.
Fixes#38985.
Teach diagnostics to correct margin of multiline messages
Make the suggestion list have a correct padding:
```
error[E0308]: mismatched types
--> file.rs:3:20
|
3 | let x: usize = "";
| ^^ expected usize, found reference
|
= note: expected type `usize`
= note: found type `&'static str`
= help: here are some functions which might fulfill your needs:
- .len()
- .foo()
- .bar()
```
In #37280 we enabled line number debugging information in release artifacts,
primarily to close out #36452 where debugging information was critical for MSVC
builds of Rust to be useful in production. This commit, however, apparently had
some unfortunate side effects.
Namely it was noticed in #37477 that if `RUST_BACKTRACE=1` was set then any
compiler error would take a very long time for the compiler to exit. The cause
of the problem here was somewhat deep:
* For all compiler errors, the compiler will `panic!` with a known value. This
tears down the main compiler thread and allows cleaning up all the various
resources. By default, however, this panic output is suppressed for "normal"
compiler errors.
* When `RUST_BACKTRACE=1` was set this caused every compiler error to generate a
backtrace.
* The libbacktrace library hits a pathological case where it spends a very long
time in its custom allocation function, `backtrace_alloc`, because the
compiler has so much debugging information. More information about this can be
found in #29293 with a summary at the end of #37477.
To solve this problem this commit simply removes debuginfo from the compiler but
not from the standard library. This should allow us to keep #36452 closed while
also closing #37477. I've measured the difference to be orders of magnitude
faster than it was before, so we should see a much quicker time-to-exit after a
compile error when `RUST_BACKTRACE=1` is set.
Closes#37477Closes#37571
Use little-endian encoding for Blake2 hashing on all architectures
Like many hash functions, the blake2 hash is mathematically defined on
a sequence of 64-bit words. As Rust's hash interface operates on
sequences of octets, some encoding must be used to bridge that
difference.
The Blake2 RFC (RFC 7693) specifies that:
```
Byte (octet) streams are interpreted as words in little-endian order,
with the least-significant byte first.
```
So use that encoding consistently.
Fixes#38891.
Beta-nominating since this is a regression since 1.15.
r? @michaelwoerister
Implement `iter::Sum` and `iter::Product` for `Result`
This introduces a private iterator adapter `ResultShunt`, which allows
treating an iterator of `Result<T, E>` as an iterator of `T`.
Improved rustdoc rendering for unstable features
This replaces "unstable" with "this is an experimental API", and uses a `<details>` tag to expand to the reason.
The `<details>` tag renders as a regular div (with the details show) on browsers which don't support it, On browsers which do support it, it shows only the summary line with an expandy-arrow next to it, and on clicking it the details will turn up below it.
This is somewhat a strawman proposal. The main issue is that we need to improve our messaging around unstable APIs. Since they turn up in the docs, we should be clearer that they are experimental (and perhaps add something about nightly-only). I'm making this PR to kickstart discussion on this.
Example rendering: http://manishearth.github.io/rust-internals-docs/std/io/trait.Read.html#method.chars
<img width="375" alt="screen shot 2017-01-04 at 10 15 37 pm" src="https://cloud.githubusercontent.com/assets/1617736/21670712/5a96c7de-d2cb-11e6-86a6-87f70818d634.png">
expands to
<img width="799" alt="screen shot 2017-01-04 at 10 15 43 pm" src="https://cloud.githubusercontent.com/assets/1617736/21670714/5db88bb4-d2cb-11e6-8fcc-5cf11d198b75.png">
cc @steveklabnik @jdub
Like many hash functions, the blake2 hash is mathematically defined on
a sequence of 64-bit words. As Rust's hash interface operates on
sequences of octets, some encoding must be used to bridge that
difference.
The Blake2 RFC (RFC 7693) specifies that:
Byte (octet) streams are interpreted as words in little-endian order,
with the least-significant byte first.
So use that encoding consistently.
Fixes#38891.
Update vec.rs
Add a warning not to convert char* from c to Vec<u8> (I thought you could until I asked on irc).
Reasoning is that it will help people avoid an error that could cause crashes and undefined behaviour. Only drawback is that it could confuse someone not familiar with C, but beginners are unlikely to be using this function anyway.
std: Remove unused objects from compiler-builtins
We don't actually use trampoline_setup.c and all the `*tf3` business
seems related to f80/f128 business. Specifically this'll fix some
warnings showing up during builds on OSX.
book: use abort() over loop {} for panic
Due to #28728 `loop {}` is very risky and can lead to fun debugging experiences such as #38136. Besides, aborting is probably better behavior than an infinite loop.
r? @steveklabnik
Remove destructor-related restrictions from unions
They don't have drop glue.
This doesn't fix the rvalue promotion issues when trying to do things like `static FOO: NoDrop<Bar> = NoDrop {inner: Bar}`. I'm not sure if we should fix that.
Don't restrict docs in compiler-docs mode
Search is broken without this. We want all crates to be included in compiler-docs mode. This was changed in https://github.com/rust-lang/rust/pull/38858, this PR brings that functionality back in compiler-docs mode.
Avoid large number of stage 0 warnings about --no-stack-check
```
....
rustc: x86_64-pc-windows-gnu/stage0/lib/rustlib/x86_64-pc-windows-gnu/lib/libstd
warning: the --no-stack-check flag is deprecated and does nothing
rustc: x86_64-pc-windows-gnu/stage0/lib/rustlib/x86_64-pc-windows-gnu/lib/libgetopts
warning: the --no-stack-check flag is deprecated and does nothing
rustc: x86_64-pc-windows-gnu/stage0/lib/rustlib/x86_64-pc-windows-gnu/lib/libterm
warning: the --no-stack-check flag is deprecated and does nothing
rustc: x86_64-pc-windows-gnu/stage0/lib/rustlib/x86_64-pc-windows-gnu/lib/liblog
warning: the --no-stack-check flag is deprecated and does nothing
....
```
r? @alexcrichton
std: Add a nonblocking `Child::try_wait` method
This commit adds a new method to the `Child` type in the `std::process` module
called `try_wait`. This method is the same as `wait` except that it will not
block the calling thread and instead only attempt to collect the exit status. On
Unix this means that we call `waitpid` with the `WNOHANG` flag and on Windows it
just means that we pass a 0 timeout to `WaitForSingleObject`.
Currently it's possible to build this method out of tree, but it's unfortunately
tricky to do so. Specifically on Unix you essentially lose ownership of the pid
for the process once a call to `waitpid` has succeeded. Although `Child` tracks
this state internally to be resilient to multiple calls to `wait` or a `kill`
after a successful wait, if the child is waited on externally then the state
inside of `Child` is not updated. This means that external implementations of
this method must be extra careful to essentially not use a `Child`'s methods
after a call to `waitpid` has succeeded (even in a nonblocking fashion).
By adding this functionality to the standard library it should help canonicalize
these external implementations and ensure they can continue to robustly reuse
the `Child` type from the standard library without worrying about pid ownership.
Make any diagnostic line to have the correct margin to align with the
first line:
```
error: message
--> file.rs:3:20
|
3 | <CODE>
| ^^^^
|
= note: this is a multiline
note with a correct
margin
= note: this is a single line note
= help: here are some functions which might fulfill your needs:
- .len()
- .foo()
- .bar()
= suggestion: this is a multiline
suggestion with a
correct margin
```
travis: Wrap submodules updates in travis_retry
Let's try to squash some of those network issues with a `travis_retry`
tool to just retry the command a few times.
rustbuild: Don't build target compilers in stage0
The `doc-book` and `doc-nomicon` steps accidentally depended on a rustbook
compiled by a cross-compiled compiler, which isn't necessary. Be sure to set the
`host` on these dependency edges to the build compiler to ensure that we're
always using a tool compiled for the host platform.
This was discovered trawling the build logs for the new dist bots and
discovering that they're building one too many compilers in stage0.
Allow projections to be promoted to constants in MIR.
This employs the `LvalueContext` additions by @pcwalton to properly extend the MIR promotion of temporaries to allow projections (field accesses, indexing and dereferences) on said temporaries.
It's needed both parity with the old constant qualification logic (for current borrowck) and it fixes#38074.
The former is *required for soundness* if we accept the RFC for promoting rvalues to `'static` constants.
That is, until we get MIR borrowck and the same source of truth will be used for both checks and codegen.
