Rollup merge of #64895 - davidtwco:issue-64130-async-error-definition, r=nikomatsakis
async/await: improve not-send errors
cc #64130.
```
note: future does not implement `std::marker::Send` because this value is used across an await
--> $DIR/issue-64130-non-send-future-diags.rs:15:5
|
LL | let g = x.lock().unwrap();
| - has type `std::sync::MutexGuard<'_, u32>`
LL | baz().await;
| ^^^^^^^^^^^ await occurs here, with `g` maybe used later
LL | }
| - `g` is later dropped here
```
For example (this also shows that we are sensitive to the typo `||`):
```
error: a trailing `|` is not allowed in an or-pattern
--> $DIR/remove-leading-vert.rs:33:11
|
LL | A || => {}
| - ^^ help: remove the `||`
| |
| while parsing this or-pattern starting here
|
= note: alternatives in or-patterns are separated with `|`, not `||`
```
Rollup merge of #63931 - petrochenkov:stabmac, r=Centril
Stabilize macros in some more positions
- Fn-like macros and attribute macros in `extern` blocks
- Fn-like procedural macros in type positions
- ~Attribute macros on inline modules~ (moved to https://github.com/rust-lang/rust/pull/64273)
Rollup merge of #63674 - petrochenkov:meta2, r=Centril
syntax: Support modern attribute syntax in the `meta` matcher
Where "modern" means https://github.com/rust-lang/rust/pull/57367:
```
PATH
PATH `(` TOKEN_STREAM `)`
PATH `[` TOKEN_STREAM `]`
PATH `{` TOKEN_STREAM `}`
```
Unfortunately, `meta` wasn't future-proofed using the `FOLLOW` token set like other matchers (https://github.com/rust-lang/rust/issues/34011), so code like `$meta:meta {` or `$meta:meta [` may break, and we need a crater run to find out how often this happens in practice.
Closes https://github.com/rust-lang/rust/issues/49629 (by fully supporting `meta` rather than removing it.)
bors [Tue, 1 Oct 2019 02:31:48 +0000 (02:31 +0000)]
Auto merge of #64932 - tmandry:rollup-7t8x1nz, r=tmandry
Rollup of 9 pull requests
Successful merges:
- #64377 (Add long error explanation for E0493)
- #64786 (Use https for curl when building for linux)
- #64828 (Graphviz debug output for generic dataflow analysis)
- #64838 (Add long error explanation for E0550)
- #64891 (Fix `vec![x; n]` with null raw fat pointer zeroing the pointer metadata)
- #64893 (Zero-initialize `vec![None; n]` for `Option<&T>`, `Option<&mut T>` and `Option<Box<T>>`)
- #64911 (Fixed a misleading documentation issue #64844)
- #64921 (Add test for issue-64662)
- #64923 (Add missing links for mem::needs_drop)
David Wood [Wed, 25 Sep 2019 12:58:41 +0000 (13:58 +0100)]
async/await: improve obligation errors
This commit improves obligation errors for async/await:
```
note: future does not implement `std::marker::Send` because this value is used across an
await
--> $DIR/issue-64130-non-send-future-diags.rs:15:5
|
LL | let g = x.lock().unwrap();
| - has type `std::sync::MutexGuard<'_, u32>`
LL | baz().await;
| ^^^^^^^^^^^ await occurs here, with `g` maybe used later
LL | }
| - `g` is later dropped here
```
Rollup merge of #64891 - SimonSapin:vec-of-fat-raw-ptr, r=sfackler
Fix `vec![x; n]` with null raw fat pointer zeroing the pointer metadata
https://github.com/rust-lang/rust/pull/49496 introduced specialization based on:
```rust
unsafe impl<T: ?Sized> IsZero for *mut T {
fn is_zero(&self) -> bool {
(*self).is_null()
}
}
```
… to call `RawVec::with_capacity_zeroed` for creating `Vec<*mut T>`, which is incorrect for fat pointers since `<*mut T>::is_null` only looks at the data component. That is, a fat pointer can be “null” without being made entirely of zero bits.
This commit fixes it by removing the `?Sized` bound on this impl (and the corresponding `*const T` one). This regresses `vec![x; n]` with `x` a null raw slice of length zero, but that seems exceptionally uncommon. (Vtable pointers are never null, so raw trait objects would not take the fast path anyway.)
An alternative to keep the `?Sized` bound (or even generalize to `impl<U: Copy> IsZero for U`) would be to cast to `&[u8]` of length `size_of::<U>()`, but the optimizer seems not to be able to propagate alignment information and sticks with comparing one byte at a time:
https://rust.godbolt.org/z/xQFkwL
----
Without the library change, the new test fails as follows:
Rollup merge of #64828 - ecstatic-morse:generic-dataflow-graphviz, r=oli-obk
Graphviz debug output for generic dataflow analysis
A follow up to #64566.
This outputs graphviz diagrams in the generic dataflow engine when `#[rustc_mir(borrowck_graphviz_postflow="suffix.dot")]` is set on an item. This code is based on [`dataflow/graphviz.rs`](https://github.com/rust-lang/rust/blob/master/src/librustc_mir/dataflow/graphviz.rs), but displays different information since there are no "gen"/"kill" sets and transfer functions cannot be coalesced in the generic analysis. As a result, we show the dataflow state at the start and end of each block, as well as the changes resulting from each statement. I also render the state bitset in full (`{_1,_2}`) instead of hex-encoded as the current renderer does (`06`).
Auto merge of #64600 - scottmcm:no-slice-tryfold-unroll, r=bluss
Remove manual unrolling from slice::Iter(Mut)::try_fold
While this definitely helps sometimes (particularly for trivial closures), it's also a pessimization sometimes, so it's better to leave this to (hypothetical) future LLVM improvements instead of forcing this on everyone.
I think it's better for the advice to be that sometimes you need to unroll manually than you sometimes need to not-unroll manually (like #64545).
---
For context see https://github.com/rust-lang/rust/pull/64572#issuecomment-532961046
Auto merge of #64673 - Mark-Simulacrum:opt-match-ck, r=oli-obk
Optimize try_eval_bits to avoid layout queries
This specifically targets match checking, but is possibly more widely
useful as well. In code with large, single-value match statements, we
were previously spending a lot of time running layout_of for the
primitive types (integers, chars) -- which is essentially useless. This
optimizes the code to avoid those query calls by directly obtaining the
size for these types, when possible.
It may be worth considering adding a `size_of` query in the future which
might be far faster, especially if specialized for "const" cases --
match arms being the most obvious example. It's possibly such a function
would benefit from *not* being a query as well, since it's trivially
evaluatable from the sty for many cases whereas a query needs to hash
the input and such.
Mark Rousskov [Sat, 21 Sep 2019 22:39:35 +0000 (18:39 -0400)]
Optimize try_eval_bits to avoid layout queries
This specifically targets match checking, but is possibly more widely
useful as well. In code with large, single-value match statements, we
were previously spending a lot of time running layout_of for the
primitive types (integers, chars) -- which is essentially useless. This
optimizes the code to avoid those query calls by directly obtaining the
size for these types, when possible.
It may be worth considering adding a `size_of` query in the future which
might be far faster, especially if specialized for "const" cases --
match arms being the most obvious example. It's possibly such a function
would benefit from *not* being a query as well, since it's trivially
evaluatable from the sty for many cases whereas a query needs to hash
the input and such.
Auto merge of #64902 - Centril:rollup-1i431vs, r=Centril
Rollup of 6 pull requests
Successful merges:
- #64691 (Point at definition when misusing ADT)
- #64735 (Add long error explanation for E0533)
- #64825 (Point at enclosing match when expecting `()` in arm)
- #64858 (Add support for relating slices in `super_relate_consts`)
- #64894 (syntax: fix dropping of attribute on first param of non-method assocated fn)
- #64898 (fixed typo)
Rollup merge of #64894 - Centril:fix-64682, r=petrochenkov
syntax: fix dropping of attribute on first param of non-method assocated fn
Fixes #64682.
The general idea is that we bake parsing of `self` into `parse_param_general` and then we just use standard list parsing. Overall, this simplifies the parsing and makes it more consistent.
Simon Sapin [Sun, 29 Sep 2019 08:45:47 +0000 (10:45 +0200)]
Fix `vec![x; n]` with null raw fat pointer zeroing the pointer metadata
https://github.com/rust-lang/rust/pull/49496 introduced specialization based on:
```
unsafe impl<T: ?Sized> IsZero for *mut T {
fn is_zero(&self) -> bool {
(*self).is_null()
}
}
```
… to call `RawVec::with_capacity_zeroed` for creating `Vec<*mut T>`,
which is incorrect for fat pointers
since `<*mut T>::is_null` only looks at the data component.
That is, a fat pointer can be “null” without being made entirely of zero bits.
This commit fixes it by removing the `?Sized` bound on this impl
(and the corresponding `*const T` one).
This regresses `vec![x; n]` with `x` a null raw slice of length zero,
but that seems exceptionally uncommon.
(Vtable pointers are never null, so raw trait objects would not take
the fast path anyway.
An alternative to keep the `?Sized` bound
(or even generalize to `impl<U: Copy> IsZero for U`)
would be to cast to `&[u8]` of length `size_of::<U>()`,
but the optimizer seems not to be able to propagate alignment information
and sticks with comparing one byte at a time:
https://rust.godbolt.org/z/xQFkwL
----
Without the library change, the new test fails as follows:
Auto merge of #64886 - Centril:rollup-30dqh8j, r=Centril
Rollup of 5 pull requests
Successful merges:
- #63492 (Remove redundancy from the implementation of C variadics.)
- #64589 (Differentiate AArch64 bare-metal targets between hf and non-hf.)
- #64799 (Fix double panic when printing query stack during an ICE)
- #64824 (No StableHasherResult everywhere)
- #64884 (Add pkg-config to dependency list if building for Linux on Linux)
Rollup merge of #64884 - jakevossen5:master, r=Mark-Simulacrum
Add pkg-config to dependency list if building for Linux on Linux
I got this message when building from source on Ubuntu:
```
It looks like you're compiling on Linux and also targeting Linux. Currently this
requires the `pkg-config` utility to find OpenSSL but unfortunately `pkg-config`
could not be found. If you have OpenSSL installed you can likely fix this by
installing `pkg-config`.
```
I feel like it would be a better experience to show this in the dependencies instead of having to run into this issue.
Rollup merge of #64824 - Mark-Simulacrum:no-stable-hasher-result-everywhere, r=michaelwoerister
No StableHasherResult everywhere
This removes the generic parameter on `StableHasher`, instead moving it to the call to `finish`. This has the side-effect of making all `HashStable` impls nicer, since we no longer need the verbose `<W: StableHasherResult>` that previously existed -- often forcing line wrapping.
This is done for two reasons:
* we should avoid false "generic" dependency on the result of StableHasher
* we don't need to codegen two/three copies of all the HashStable impls when they're transitively used to produce a fingerprint, u64, or u128. I haven't measured, but this might actually make our artifacts somewhat smaller too.
* Easier to understand/read/write code -- the result of the stable hasher is irrelevant when writing a hash impl.
Rollup merge of #64799 - Aaron1011:fix/double-panic, r=Mark-Simulacrum
Fix double panic when printing query stack during an ICE
On the latest nightly, any call to `bug` or `span_bug` will result in two panics - the first one as a normal result of calling `bug` / `span_bug`, and the second as a result of trying to print the query stack from the panic handler. This is caused by the query-printing code attempting to acquire a lock on `HandlerInnder`, which is still being held by `bug`.
This PR moves the actual panic out of `HandlerInner`, into `Handler`. This allows us to release the lock on `HandlerInner` before triggering the panic, ensuring that the panic handler will be able to acquire the lock if necessary.
Rollup merge of #64589 - andre-richter:aarch64_bare_metal, r=Amanieu
Differentiate AArch64 bare-metal targets between hf and non-hf.
CC @parched, kindly request you to review.
~~Note: This change breaks code that uses the target `aarch64-unknown-none` for the sake of clearer naming as discussed in the links posted below. A search on github reveals that code using `aarch64-unknown-none` is almost exclusively forked from our embedded WG's OS tutorials repo at https://github.com/rust-embedded/rust-raspi3-OS-tutorials, for which the target was originally created.~~
~~I will adapt this repo to the new target name asap once this PR would go upstream. The minor annoyance for the forks to break temporarily should be acceptable for the sake of introducing a better differentiation now before it is too late.
Also, the break would only happen upon updating the toolchain, giving the user a good hint at what has happened.~~
---------- Patch commit message:
Following up on [1] and [2], this PR adds differntiation for aarch64 bare-metal
targets between versions with and without floating point enabled.
This streamlines the target naming with other existing ARM targets and provides
the user clear indication if he is getting float or non-float for his bare-metal
target.
Rollup merge of #63492 - eddyb:cvarargs, r=nagisa,matthewjasper
Remove redundancy from the implementation of C variadics.
This cleanup was first described in https://github.com/rust-lang/rust/issues/44930#issuecomment-497163539:
* AST doesn't track `c_variadic: bool` anymore, relying solely on a trailing `CVarArgs` type in fn signatures
* HIR doesn't have a `CVarArgs` anymore, relying solely on `c_variadic: bool`
* same for `ty::FnSig` (see tests for diagnostics improvements from that)
* `{hir,mir}::Body` have one extra argument than the signature when `c_variadic == true`
* `rustc_typeck` and `rustc_mir::{build,borrowck}` need to give that argument the right type (which no longer uses a lifetime parameter, but a function-internal scope)
* `rustc_target::abi::call` doesn't need special hacks anymore (since it never sees the `VaListImpl` now, it's all inside the body)
Auto merge of #64470 - ecstatic-morse:split-promotion-and-validation, r=eddyb,oli-obk
Implement dataflow-based const validation
This PR adds a separate, dataflow-enabled pass that checks the bodies of `const`s, `static`s and `const fn`s for [const safety](https://github.com/rust-rfcs/const-eval/blob/master/const.md). This is based on my work in #63860, which tried to integrate into the existing pass in [`qualify_consts.rs`](https://github.com/rust-lang/rust/blob/master/src/librustc_mir/transform/qualify_consts.rs). However, the resulting pass was even more unwieldy than the original. Unlike its predecessor, this PR is designed to be combined with #63812 to replace the existing pass completely.
The new checker lives in [`librustc_mir/transform/check_consts`](https://github.com/ecstatic-morse/rust/tree/split-promotion-and-validation/src/librustc_mir/transform/check_consts).
[`qualifs.rs`](https://github.com/ecstatic-morse/rust/blob/split-promotion-and-validation/src/librustc_mir/transform/check_consts/qualifs.rs) contains small modifications to the existing `Qualif` trait and its implementors, but is mostly unchanged except for the removal of `IsNotPromotable` and `IsNotImplicitlyPromotable`, which are only necessary for promotion.
[`resolver.rs`](https://github.com/ecstatic-morse/rust/blob/split-promotion-and-validation/src/librustc_mir/transform/check_consts/resolver.rs) contains the dataflow analysis used to propagate qualifs between locals.
Finally, [`validation.rs`](https://github.com/ecstatic-morse/rust/blob/split-promotion-and-validation/src/librustc_mir/transform/check_consts/validation.rs) contains a refactored version of the existing [`Visitor`](https://github.com/rust-lang/rust/blob/ca3766e2e58f462a20922e42c821a37eaf0e13db/src/librustc_mir/transform/qualify_consts.rs#L1024) in `qualfy_consts.rs`. All errors have been associated with a `struct` to make [comparison with the existing pass](https://github.com/ecstatic-morse/rust/blob/1c19f2d540ca0a964900449d79a5d5181b43146d/src/librustc_mir/transform/qualify_consts.rs#L1006) simple.
The existing validation logic in [`qualify_consts`](https://github.com/rust-lang/rust/blob/master/src/librustc_mir/transform/qualify_consts.rs) has been modified to allow it to run in parallel with the new validator. If [`use_new_validator`](https://github.com/rust-lang/rust/pull/64470/files#diff-c2552a106550d05b69d5e07612f0f812R950) is not set, the old validation will be responsible for actually generating the errors, but those errors can be compared with the ones from the new validator.
Auto merge of #64883 - Centril:rollup-uehjt63, r=Centril
Rollup of 10 pull requests
Successful merges:
- #64131 (data_structures: Add deterministic FxHashMap and FxHashSet wrappers)
- #64387 (Fix redundant semicolon lint interaction with proc macro attributes)
- #64678 (added more context for duplicate lang item errors (fixes #60561))
- #64763 (Add E0734 and its long explanation)
- #64793 (Fix format macro expansions spans to be macro-generated)
- #64837 (Improve wording in documentation of MaybeUninit)
- #64852 (Print ParamTy span when accessing a field (#52082))
- #64875 (Upgrade async/await to "used" keywords.)
- #64876 (Fix typo in intrinsics op safety)
- #64880 (Slice docs: fix typo)
Rollup merge of #64793 - immunant:format_spans, r=matthewjasper
Fix format macro expansions spans to be macro-generated
New Exprs generated as part of the format macro expansion should get the macro
expansion span with an expansion context, rather than the span of the format string
which does not.
Rollup merge of #64678 - tomtau:fix/no-std-error, r=matthewjasper
added more context for duplicate lang item errors (fixes #60561)
Some more information about #60561 -- these errors are pretty common when one works in restrictive environments with `no_std` or customized `std`, but they don't provide much context for debugging, as any transitive dependency could have brought in `std` crate. With that, currently, one needs to use something like `cargo tree` and investigate transitive dependencies one by one.
It'll be more helpful to know at least the crate that uses `std` (which `cargo tree` doesn't show) to pin down this investigation when debugging.
I'm not sure what the best way to get this context is inside rustc internals (I'm new to them). I found that `all_crate_nums` query returns the crates in some dependency order, so printing out the name of the preceding crate seems to do the trick. But I welcome suggestions if this can be done in a better way.
Rollup merge of #64387 - nathanwhit:redundant-semi-fix, r=varkor
Fix redundant semicolon lint interaction with proc macro attributes
Fixes #63967 and fixes #63947, both of which were caused by the lint's changes to the parser interacting poorly with proc macro attributes and causing span information to be lost
Rollup merge of #64131 - shivan1b:deterministic-fxhashmap, r=Mark-Simulacrum
data_structures: Add deterministic FxHashMap and FxHashSet wrappers
StableMap
A wrapper for FxHashMap that allows to `insert`, `remove`, `get`, `get_mut` and convert a hashmap into a sorted vector using the method `into_sorted_vector` but no iteration support.
StableSet
A wrapper for FxHashSet that allows to `insert`, `remove`, `get` and convert a hashset into a sorted vector using the method `into_sorted_vector` but no iteration support.
projects / rust.git / log