bors [Sat, 16 Nov 2019 07:26:57 +0000 (07:26 +0000)]
Auto merge of #66255 - ehuss:update-cc, r=alexcrichton
Update cc, git2, num_cpus.
This updates the `cc` crate, bringing in better parallel building support. Also updates `git2` which enables the parallel feature. (Note: I don't expect it will have a significant impact on build time, but seems good to update anyways.)
The main thorn is that `cc` gained knowledge about RISC-V architectures (https://github.com/alexcrichton/cc-rs/pull/428, https://github.com/alexcrichton/cc-rs/pull/429, https://github.com/alexcrichton/cc-rs/pull/430), but the builders on CI do not have the riscv C compiler installed. This means that bootstraps' cc detection was finding a C compiler that isn't installed, and fails.
The solution here is to override the cc detection to `false`. The C compiler isn't actually used on riscv platforms. AFAIK, the only location would be compiler_builtins, and it currently forces C support off (https://github.com/rust-lang/compiler-builtins/blob/a533ae9c5aa325db209659679535fe1f186eae81/build.rs#L49-L55).
Other possible solutions:
- Add the override in cc_detect for riscv (or any "no-C" platform like wasm32 and nvptx)
- Install and use the appropriate c compiler. I tried this the `g++-riscv64-linux-gnu` package, but it failed missing some header file.
bors [Sat, 16 Nov 2019 02:40:52 +0000 (02:40 +0000)]
Auto merge of #66453 - Centril:rollup-w1ohzxs, r=Centril
Rollup of 5 pull requests
Successful merges:
- #66350 (protect creation of destructors by a mutex)
- #66407 (Add more tests for fixed ICEs)
- #66415 (Add --force-run-in-process unstable option to libtest)
- #66427 (Move the JSON error emitter to librustc_errors)
- #66441 (libpanic_unwind for Miri: make sure we have the SEH lang items when needed)
bors [Fri, 15 Nov 2019 23:28:50 +0000 (23:28 +0000)]
Auto merge of #66326 - Nadrieril:refactor-intrange, r=varkor
Refactor integer range handling in the usefulness algorithm
Integer range handling had accumulated a lot of debt. This cleans up a lot of it.
In particular this:
- removes unnecessary conversions between `Const` and `u128`, and between `Constructor` and `IntRange`
- clearly distinguishes between on the one hand ranges of integers that may or may not be matched exhaustively, and on the other hand ranges of non-integers that are never matched exhaustively and are compared using Const-based shenanigans
- cleans up some overly complicated code paths
- generally tries to be more idiomatic.
As a nice side-effect, I measured a 10% perf increase on `unicode_normalization`.
There's one thing that I feel remains to clean up: the [overlapping range check](https://github.com/rust-lang/rust/pull/64007), which is currently quite ad-hoc. But that is intricate enough that I'm leaving it out of this PR.
There's also one little thing I'm not sure I understand: can `try_eval_bits` fail for an integer constant value in that code ? What would that mean, and how do I construct a test case for this possibility ?
libpanic_unwind for Miri: make sure we have the SEH lang items when needed
r? @oli-obk @alexcrichton This is required to fix the Miri toolstate. Turns out rustc complains when doing codegen for MSVC and these lang items do not exist. For now `cfg(miri)` needs to still be able to codegen (we [plan to change that](https://github.com/rust-lang/miri/pull/1048#issuecomment-554108470) but that's a larger project requiring improvements to xargo and maybe also cargo; that should not block fixing the toolstate). Yes, this is a hack, but it is inside `cfg(miri)` so I hope this is okay.
Rollup merge of #66427 - Mark-Simulacrum:errors-json, r=Centril
Move the JSON error emitter to librustc_errors
This is done both as a cleanup (it makes little sense for this emitter to be in libsyntax), but also as part of broader work to decouple Session from librustc itself.
Along the way, this also moves SourceMap to syntax_pos, which is also nice for the above reasons, as well as allowing dropping the SourceMapper trait from code. This had the unfortunate side-effect of moving `FatalError` to rustc_data_structures (it's needed in syntax_pos, due to SourceMap, but putting it there feels somehow worse).
Rollup merge of #66415 - tmandry:force-test-in-process, r=alexcrichton
Add --force-run-in-process unstable option to libtest
When running tests with `-Zpanic_abort_tests`, it's sometimes desirable to fall back to the old behavior of only running tests in-process. This comes in handy if the system process launcher is unavailable, or the test code somehow expects all tests to be run in the same process.
For example, in Fuchsia we have unit tests that actually test the process launcher itself, in which case we can't use the process launcher to run the tests :).
Nadrieril [Sat, 9 Nov 2019 21:46:46 +0000 (21:46 +0000)]
Remove fishy condition
That condition was leftover from a refactor, and was probably not
intended. In fact it can't trigger: it would require a ConstantValue of
an integral type for which `try_eval_bits` fails. But since we only
apply `subtract_ctors` to the output of `all_ctors`, this won't happen.
Mark Rousskov [Fri, 15 Nov 2019 13:32:31 +0000 (08:32 -0500)]
Remove SourceMapper trait
SourceMap is now in the root of all rustc-specific crates, syntax_pos,
so there's no need for the trait object to decouple the dependencies
between librustc_errors and libsyntax as was needed previously.
Tyler Mandry [Fri, 15 Nov 2019 13:44:52 +0000 (14:44 +0100)]
Rollup merge of #66443 - GuillaumeGomez:port-erased-cleanup, r=Mark-Simulacrum
Port erased cleanup
Just realised that the changes I made in #65965 were removed after the move of all error codes so here it is. I made them into separate commits to make the history look better this time.
Tyler Mandry [Fri, 15 Nov 2019 13:44:47 +0000 (14:44 +0100)]
Rollup merge of #66197 - Centril:transparent-ast, r=varkor
Push `ast::{ItemKind, ImplItemKind}::OpaqueTy` hack down into lowering
We currently have a hack in the form of `ast::{ItemKind, ImplItemKind}::OpaqueTy` which is constructed literally when you write `type Alias = impl Trait;` but not e.g. `type Alias = Vec<impl Trait>;`. Per https://github.com/rust-lang/rfcs/pull/2515, this needs to change to allow `impl Trait` in nested positions. This PR achieves this change for the syntactic aspect but not the semantic one, which will require changes in lowering and def collection. In the interim, `TyKind::opaque_top_hack` is introduced to avoid knock-on changes in lowering, collection, and resolve. These hacks can then be removed and fixed one by one until the desired semantics are supported.
Mark Rousskov [Fri, 15 Nov 2019 13:27:09 +0000 (08:27 -0500)]
Move SourceMap to syntax_pos
This does not update the use sites or delete the now unnecessary
SourceMapper trait, to allow git to interpret the file move as a rename
rather than a new file.
Mark Rousskov [Thu, 14 Nov 2019 19:01:03 +0000 (14:01 -0500)]
Move FatalError to syntax_pos
This is a bit unfortunate, but code needs to be able to fatally error
early on (in particular, syntax_pos after we move SourceMap there). It's
also a tiny bit of code, which means it's ultimately not that bad.
bors [Fri, 15 Nov 2019 09:37:24 +0000 (09:37 +0000)]
Auto merge of #66438 - JohnTitor:rollup-qpv3wia, r=JohnTitor
Rollup of 12 pull requests
Successful merges:
- #65557 (rename Error::iter_chain() and remove Error::iter_sources())
- #66013 (Avoid hashing the key twice in `get_query()`.)
- #66306 (Remove cannot mutate statics in initializer of another static error)
- #66338 (Update mdbook.)
- #66388 (Do not ICE on recovery from unmet associated type bound obligation)
- #66390 (Fix ICE when trying to suggest `Type<>` instead of `Type()`)
- #66391 (Do not ICE in `if` without `else` in `async fn`)
- #66398 (Remove some stack frames from `.async` calls)
- #66410 (miri: helper methods for max values of machine's usize/isize)
- #66418 (Link to tracking issue in HIR const-check error code description)
- #66419 (Don't warn labels beginning with `_` on unused_labels lint)
- #66428 (Cleanup unused function)
Yuki Okushi [Fri, 15 Nov 2019 09:36:32 +0000 (18:36 +0900)]
Rollup merge of #66418 - ecstatic-morse:hir-const-check-err-msg, r=estebank
Link to tracking issue in HIR const-check error code description
This is a follow up to #66170 that addresses [this comment](https://github.com/rust-lang/rust/pull/66170#discussion_r344021268).
As an aside, the only other error code whose description uses the phrase "tracking issue" is `E0202`. We may want to come up with standards around this, especially since error codes are now centralized and easier to keep track of (thanks @GuillaumeGomez).
Yuki Okushi [Fri, 15 Nov 2019 09:36:29 +0000 (18:36 +0900)]
Rollup merge of #66398 - sfackler:no-async-nesting, r=Centril
Remove some stack frames from `.async` calls
The `Context` argument is currently smuggled through TLS for
async-generated futures. The current infrastructure is closure-based,
and results in an extra 6 stack frames when .awaiting an async-generated
future!
While the long (medium?) term solution is to remove the use of TLS
entirely, we can improve things a bit in the meantime. In particular,
this commit does 2 things:
1. `get_task_context` has been inlined into `poll_with_tls_context`,
removing 2 frames (16 and 17 above).
2. `set_task_context` now returns a guard type that resets the TLS
rather than taking a closure, removing 2 frames (13 and 14 above).
We can also remove frame 18 by removing `poll_with_tls_context` in favor
of a `get_task_context` function which returns a guard, but that
requires adjusting the code generated for .await, so I've left that off
for now.
Yuki Okushi [Fri, 15 Nov 2019 09:36:23 +0000 (18:36 +0900)]
Rollup merge of #66338 - ehuss:update-mdbook, r=alexcrichton
Update mdbook.
This brings in some important updates to fix some rendering issues in the books. In particular fixing hidden lines in code blocks, and some escaping issues. More details at https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md
Yuki Okushi [Fri, 15 Nov 2019 09:36:22 +0000 (18:36 +0900)]
Rollup merge of #66306 - spastorino:remove-error-handled-by-miri, r=oli-obk
Remove cannot mutate statics in initializer of another static error
r? @oli-obk
This is just a refactoring. As the removed code itself said, it only a heuristic catching a few cases early instead of leaving it all to const eval. It's easy to work around the static check and then run into the miri-engine check.
So, it seems, that even Path::ancestors() includes itself. So, to avoid confusion and simplify it more, I reduced PR #65557 to only have `chained` and `Chain`.
Rationale:
1. Such iterators are helpful. They should better be stabilized sooner than later.
1. self should be included. It is easy to .skip(1) it. Not including self is harmful because it is harder to add self to the iterator than to remove it.
1. The chosen name should be telling and reflect the fact that self is included. `.chained()` was chosen in honor of error-chain and because the iterator iterates over the chain of errors that is somehow included in self.
1. The resulting iterator is named `Chain` because the `error::Chain` is what we want to have.
bors [Fri, 15 Nov 2019 01:23:51 +0000 (01:23 +0000)]
Auto merge of #64432 - gnzlbg:simplify_truncate, r=alexcrichton
Make the semantics of Vec::truncate(N) consistent with slices.
This commit simplifies the implementation of `Vec::truncate(N)` and
makes its semantics identical to dropping the `[vec.len() - N..]`
sub-slice tail of the vector, which is the same behavior as dropping a
vector containing the same sub-slice.
This changes two unspecified aspects of `Vec::truncate` behavior:
* the drop order, from back-to-front to front-to-back,
* the behavior of `Vec::truncate` on panics: if dropping one element of
the tail panics, currently, `Vec::truncate` panics, but with this PR all other
elements are still dropped, and if dropping a second element of the tail
panics, with this PR, the program aborts.
Programs can trivially observe both changes. For example
([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=7bef575b83b06e82b3e3529e4edbcac7)):
```rust
fn main() {
struct Bomb(usize);
impl Drop for Bomb {
fn drop(&mut self) {
panic!(format!("{}", self.0));
}
}
let mut v = vec![Bomb(0), Bomb(1)];
std::panic::catch_unwind(std::panic::AssertUnwindSafe(|| {
v.truncate(0);
}));
assert_eq!(v.len(), 1);
std::mem::forget(v);
}
```
panics printing `1` today and succeeds. With this change, it panics
printing `0` first (due to the drop order change), and then aborts
with a double-panic printing `1`, just like dropping the
`[Bomb(0), Bomb(1)]` slice does, or dropping
`vec![Bomb(0), Bomb(1)]` does.
projects / rust.git / log