bors [Wed, 10 Jun 2020 22:01:37 +0000 (22:01 +0000)]
Auto merge of #73206 - Dylan-DPC:rollup-rha9g8q, r=Dylan-DPC
Rollup of 9 pull requests
Successful merges:
- #72706 (Add windows group to triagebot)
- #72789 (resolve: Do not suggest imports from the same module in which we are resolving)
- #72890 (improper ctypes: normalize return types and transparent structs)
- #72897 (normalize adt fields during structural match checking)
- #73005 (Don't create impl candidates when obligation contains errors)
- #73023 (Remove noisy suggestion of hash_map )
- #73070 (Add regression test for const generic ICE in #72819)
- #73157 (Don't lose empty `where` clause when pretty-printing)
- #73184 (Reoder order in which MinGW libs are linked to fix recent breakage)
bors [Wed, 10 Jun 2020 18:02:34 +0000 (18:02 +0000)]
Auto merge of #73213 - ehuss:fix-emsdk, r=Mark-Simulacrum
Fix emcc failure for wasm32.
The wasm32 job is currently failing on CI with the error `ERROR: llc executable not found at /usr/bin/llc`. The issue is that https://github.com/emscripten-core/emsdk/pull/472 has changed how emsdk discovers its configuration. We were relying on the global behavior that would use a configuration from the home directory. However, it looks like emsdk is moving away from that approach. This change adds the necessary env var for emcc to find the correct configuration.
There are a few alternate approaches this could take. The `--no-embedded` option could be passed to `emsdk activate` to use the old behavior, but it seems like they want to move away from that. Another option is to source `emsdk_env.sh`, which is how these env vars normally get set. I'm not entirely sure how to do that easily in a Dockerfile, though.
Dylan DPC [Wed, 10 Jun 2020 09:03:51 +0000 (11:03 +0200)]
Rollup merge of #73184 - mati865:fix-mingw-libs-order, r=petrochenkov
Reoder order in which MinGW libs are linked to fix recent breakage
Recent upstream mingw-w64 changes made libmsvcrt depend on libmingwex breaking compilation in some cases when using **external** MinGW.
Applying this change to the master fixes nightly and stage{1,2} build. For stage0 one has to export `RUSTFLAGS_BOOTSTRAP='-C link-arg=-lmsvcrt'` until this PR lands in bootstrap compiler.
Therefore I'm humbly asking to also backport it to the beta and update bootstrap compiler.
Dylan DPC [Wed, 10 Jun 2020 09:03:49 +0000 (11:03 +0200)]
Rollup merge of #73157 - Aaron1011:where-oh-where-has-my-little-span-gone, r=ecstatic-morse
Don't lose empty `where` clause when pretty-printing
Previously, we would parse `struct Foo where;` and `struct Foo;`
identically, leading to an 'empty' `where` clause being omitted during
pretty printing. This will cause us to lose spans when proc-macros
involved, since we will have a collected `where` token that does not
appear in the pretty-printed item.
We now explicitly track the presence of a `where` token during parsing,
so that we can distinguish between `struct Foo where;` and `struct Foo;`
during pretty-printing
Dylan DPC [Wed, 10 Jun 2020 09:03:43 +0000 (11:03 +0200)]
Rollup merge of #73005 - Aaron1011:fix/error-overflow, r=estebank
Don't create impl candidates when obligation contains errors
Fixes #72839
In PR #72621, trait selection was modified to no longer bail out early
when an error type was encountered. This allowed us treat `ty::Error` as
`Sized`, causing us to avoid emitting a spurious "not sized" error after
a type error had already occured.
However, this means that we may now try to match an impl candidate
against the error type. Since the error type will unify with almost
anything, this can cause us to infinitely recurse (eventually triggering
an overflow) when trying to verify certain `where` clauses.
This commit causes us to skip generating any impl candidates when an
error type is involved.
Dylan DPC [Wed, 10 Jun 2020 09:03:42 +0000 (11:03 +0200)]
Rollup merge of #72897 - lcnr:structurally-match-normalize, r=pnkfelix
normalize adt fields during structural match checking
fixes #72896
currently only fixes the issue itself and compiles stage 1 libs.
I believe we have to use something else to normalize the adt fields here,
as I expect some partially resolved adts to cause problems :thinking:
stage 1 libs and the test itself pass, not sure about the rest...
Will spend some more time looking into it tomorrow.
Dylan DPC [Wed, 10 Jun 2020 09:03:40 +0000 (11:03 +0200)]
Rollup merge of #72890 - davidtwco:issue-66202-normalize-and-transparent-improper-ctypes, r=varkor
improper ctypes: normalize return types and transparent structs
Fixes #66202.
See each commit individually (except the first which adds a test) for more detailed explanations on the changes made.
In summary, this PR ensures that return types are normalized before being checked for FFI-safety, and that transparent newtype wrappers are FFI-safe if the type being wrapped is FFI-safe (often true previously, but not if, after substitution, all types in a transparent newtype were zero sized).
Dylan DPC [Tue, 9 Jun 2020 23:06:30 +0000 (01:06 +0200)]
Rollup merge of #73133 - doctorn:unwind-mir-validation, r=jonas-schievink
Enforce unwind invariants
I had a quick look at #72959. The failure message probably needs to be more detailed but I just wanted to check I got the right idea. I have no idea how to right a test for this either...
Dylan DPC [Tue, 9 Jun 2020 23:06:27 +0000 (01:06 +0200)]
Rollup merge of #73122 - doctorn:issue-73116, r=varkor
Resolve E0584 conflict
Adds a new error code (`E0761`) to indicate ambiguity in module file names and an accompanying expanded description to resolve a conflict over `E0584`.
Dylan DPC [Tue, 9 Jun 2020 23:06:25 +0000 (01:06 +0200)]
Rollup merge of #73098 - jyn514:rustdoc-is-fake, r=GuillaumeGomez
Add Item::is_fake for rustdoc
I wasn't aware items _could_ be fake, so I think having a function
mentioning it could be helpful. Also, I'd need to make this change for
cross-crate intra-doc links anyway, so I figured it's better to make the
refactor separate.
David Wood [Mon, 1 Jun 2020 16:00:58 +0000 (17:00 +0100)]
lint: transitive FFI-safety for transparent types
This commit ensures that if a `repr(transparent)` newtype's only
non-zero-sized field is FFI-safe then the newtype is also FFI-safe.
Previously, ZSTs were ignored for the purposes of linting FFI-safety
in transparent structs - thus, only the single non-ZST would be checked
for FFI-safety. However, if the non-zero-sized field is a generic
parameter, and is substituted for a ZST, then the type would be
considered FFI-unsafe (as when every field is thought to be zero-sized,
the type is considered to be "composed only of `PhantomData`" which is
FFI-unsafe).
In this commit, for transparent structs, the non-zero-sized field is
identified (before any substitutions are applied, necessarily) and then
that field's type (now with substitutions) is checked for FFI-safety
(where previously it would have been skipped for being zero-sized in
this case).
To handle the case where the non-zero-sized field is a generic
parameter, which is substituted for `()` (a ZST), and is being used
as a return type - the `FfiUnsafe` result (previously `FfiPhantom`) is
caught and silenced.
David Wood [Mon, 1 Jun 2020 14:41:36 +0000 (15:41 +0100)]
lint: check for unit ret type after normalization
This commit moves the check that skips unit return types to after
where the return type has been normalized - therefore ensuring that
FFI-safety lints are not emitted for types which normalize to unit.
David Wood [Mon, 1 Jun 2020 14:34:45 +0000 (15:34 +0100)]
improper_ctypes: add test for #66202
This commit adds a test of the improper ctypes lint, checking that
return type are normalized bethat return types are normalized before
being checked for FFI-safety, and that transparent newtype wrappers
are FFI-safe if the type being wrapped is FFI-safe.
bors [Tue, 9 Jun 2020 03:41:43 +0000 (03:41 +0000)]
Auto merge of #73153 - ecstatic-morse:revert-71956, r=tmandry
Revert #71956
...since it caused unsoundness in #73137. Also adds a reduced version of #73137 to the test suite. The addition of the `MaybeInitializedLocals` dataflow analysis has not been reverted, but it is no longer used.
Presumably there is a more targeted fix, but I'm worried that other bugs may be lurking. I'm not yet sure what the root cause of #73137 is.
Aaron Hill [Tue, 9 Jun 2020 01:09:54 +0000 (21:09 -0400)]
Don't lose empty `where` clause when pretty-printing
Previously, we would parse `struct Foo where;` and `struct Foo;`
identically, leading to an 'empty' `where` clause being omitted during
pretty printing. This will cause us to lose spans when proc-macros
involved, since we will have a collected `where` token that does not
appear in the pretty-printed item.
We now explicitly track the presence of a `where` token during parsing,
so that we can distinguish between `struct Foo where;` and `struct Foo;`
during pretty-printing
bors [Mon, 8 Jun 2020 23:52:04 +0000 (23:52 +0000)]
Auto merge of #73147 - Dylan-DPC:rollup-9saqhj5, r=Dylan-DPC
Rollup of 8 pull requests
Successful merges:
- #71842 (doc: make impl block collapsible if it has an associated constant)
- #72912 (Add new E0758 error code)
- #73008 (Update RELEASES.md)
- #73090 (Use `LocalDefId` directly in `Resolver::export_map`)
- #73118 (Improve the wording in documentation of std::mem::drop)
- #73124 (Removed lifetime parameters from Explanation of E0207 )
- #73138 (Use shorthand linker strip arguments in order to support MacOS)
- #73143 (Update books)
Rename some identifiers in `RawVec` and `libarena`.
- Use `len` more consistently for the number of elements in a vector,
because that's the usual name.
- Use `additional` more consistently for the number of elements we want
to add, because that's what `Vec::reserve()` uses.
- Use `cap` consistently rather than `capacity`.
- Plus a few other tweaks.
Remove the `reserve_in_place` calls in `{Typed,Dropless}Arena::grow`.
They are pointless. No reasonable allocator will be able to satisfy a
`reserve_in_place` request that *doubles* the size of an allocation when
dealing with allocations that are 4 KiB and larger.
Just to be sure, I confirmed on Linux that the `reserve_in_place` calls
never succeed.
(Note however that the `reserve_in_place` call for `DroplessArena::grow`
did occasionally succeed prior to the off-by-one fix in the previous
commit, because we would sometimes do a `reserve_in_place` request for
the chunk's current size, which would trivially succeed!)
5 commits in becdca9477c9eafa96a4eea5156fe7a2730d9dd2..5d40ba5c2515caffa7790cda621239dc21ef5a72
2020-05-21 21:08:02 +0100 to 2020-06-06 20:25:36 -0700
- Add some links to Disambiguating Function Calls. (rust-lang-nursery/reference#829)
- change bash to sh as shell code blocks language indentifier (rust-lang-nursery/reference#827)
- Fix sentence mistake in array-expr.md (rust-lang-nursery/reference#826)
- removed the word "Second" form the beginning of the 2nd list item and labelled it as `2` (rust-lang-nursery/reference#822)
- Update fn-like proc-macro invocation restrictions. (rust-lang-nursery/reference#816)
## book
14 commits in e8a4714a9d8a6136a59b8e63544e149683876e36..30cd9dfe71c446de63826bb4472627af45acc9db
2020-05-25 10:29:27 -0500 to 2020-06-07 23:07:19 -0500
- Unnecessarily long type name in Ch 13 (rust-lang/book#2362)
- Tweak example in chapter 10 (rust-lang/book#2363)
- Mention that to_lowercase isn't perfect (rust-lang/book#2364)
- fix typo in CONTRIBUTING.md (rust-lang/book#2360)
- Link German translation in appendix F (rust-lang/book#2347)
- Updates wording on Box example (rust-lang/book#2332)
- fix: match 15-24 with 15-18 (rust-lang/book#2324)
- Reword ch01-03 recap paragraph (rust-lang/book#2305)
- Remove some confusing wording. (rust-lang/book#2358)
- Clarify some wording a bit (rust-lang/book#2357)
- Update ch12-05 PowerShell note (rust-lang/book#2348)
- text -> console (rust-lang/book#2352)
- Improve wording around drop (rust-lang/book#2350)
- Make some statements about crates more correct (rust-lang/book#2349)
Dylan DPC [Mon, 8 Jun 2020 20:15:19 +0000 (22:15 +0200)]
Rollup merge of #73138 - eggyal:macos-linker-strip, r=petrochenkov
Use shorthand linker strip arguments in order to support MacOS
Per discussion from https://github.com/rust-lang/rust/issues/72110#issuecomment-636609419 onward, the current `-Z strip` options aren't supported by the MacOS linker, but I think only because it doesn't support the longhand arguments `--strip-debug` and `--strip-all`.
This PR switches to using the shorthand arguments `-s` and `-S` instead, which (I believe) are supported by all GCC linkers.
Dylan DPC [Mon, 8 Jun 2020 20:15:15 +0000 (22:15 +0200)]
Rollup merge of #73118 - alamb:alamb/doc-drop-typo, r=shepmaster
Improve the wording in documentation of std::mem::drop
I thought the original phrasing was somewhat awkward compared to rest of the (very well written) documentation, so figured I would propose a change to improve it.
bors [Mon, 8 Jun 2020 20:10:07 +0000 (20:10 +0000)]
Auto merge of #72655 - jethrogb:sgx-lvi-hardening, r=petrochenkov
Enable LVI hardening for x86_64-fortanix-unknown-sgx
This implements mitigations for the Load Value Injection vulnerability (CVE-2020-0551) for the `x86_64-fortanix-unknown-sgx` target by enabling new LLVM passes. More information about LVI and mitigations may be found at https://software.intel.com/security-software-guidance/insights/deep-dive-load-value-injection.
This PR unconditionally enables the mitigations for `x86_64-fortanix-unknown-sgx` since there is no available hardware that doesn't require the mitigations. This may be reconsidered in the future.
* [x] This depends on https://github.com/rust-lang/compiler-builtins/pull/359/
bors [Mon, 8 Jun 2020 16:47:22 +0000 (16:47 +0000)]
Auto merge of #5680 - ebroto:3792_let_return, r=Manishearth
let_and_return: avoid "does not live long enough" errors
EDIT: Add #3324 to the list of fixes
<details>
<summary>Description of old impl</summary>
<br>
Avoid suggesting turning the RHS expression of the last statement into the block tail expression if a temporary borrows from a local that would be destroyed before.
This is my first incursion into MIR so there's probably room for improvement!
</details>
Avoid linting if the return type of some method or function called in the last statement has a lifetime parameter.
changelog: Fix false positive in [`let_and_return`]
bors [Mon, 8 Jun 2020 13:49:29 +0000 (13:49 +0000)]
Auto merge of #5378 - Centril:unnested-or-pats, r=flip1995,phansch
New lint: `unnested_or_patterns`
changelog: Adds a lint `unnested_or_patterns`, suggesting `Some(0 | 2)` as opposed to `Some(0) | Some(2)`. The lint only fires on compilers capable of using `#![feature(or_patterns)]`.
- The lint is primarily encoded as a pure algorithm which to unnest or-patterns in an `ast::Pat` (`fn unnest_or_patterns`) through a `MutVisitor`. After that is done, and assuming that any change was detected, then `pprust::pat_to_string` is used to simply convert the transformed pattern into a suggestion.
- The PR introduces a module `utils::ast_utils` with a bunch of functions for spanless & nodeless equality comparisons of ASTs.
Ralf Jung [Mon, 8 Jun 2020 07:55:31 +0000 (09:55 +0200)]
Rollup merge of #73001 - ilya-bobyr:master, r=dtolnay
Free `default()` forwarding to `Default::default()`
It feels a bit redundant to have to say `Default::default()` every time I need a new value of a type that has a `Default` instance.
Especially so, compared to Haskell, where the same functionality is called `def`.
Providing a free `default()` function that forwards to `Default::default()` seems to improve the situation.
The trait is still there, so if someone wants to be explicit and to say `Default::default()` - it still works, but if imported as `std::default::default;`, then the free function reduces typing and visual noise.
Ralf Jung [Mon, 8 Jun 2020 07:55:30 +0000 (09:55 +0200)]
Rollup merge of #72963 - poliorcetics:cstring-from-raw, r=dtolnay
Cstring `from_raw` and `into_raw` safety precisions
Fixes #48525.
Fixes #68456.
This issue had two points:
- The one about `from_raw` has been addressed (I hope).
- The other one, about `into_raw`, has only been partially fixed.
About `into_raw`: the idea was to:
> steer users away from using the pattern of CString::{into_raw,from_raw} when interfacing with C APIs that may change the effective length of the string by writing interior NULs or erasing the final NUL
I tried making a `Vec<c_char>` like suggested but my current solution feels very unsafe and *hacky* to me (most notably the type cast), I included it here to make it available for discussion:
```rust
fn main() {
use std::os::raw::c_char;
let v = String::from("abc")
.bytes()
// From u8 to i8,
// I feel like it will be a problem for values of u8 > 255
.map(|c| c as c_char)
.collect::<Vec<_>>();
Ralf Jung [Mon, 8 Jun 2020 07:55:26 +0000 (09:55 +0200)]
Rollup merge of #72799 - Aaron1011:feature/span-debug, r=petrochenkov
Add `-Z span-debug` to allow for easier debugging of proc macros
Currently, the `Debug` impl for `proc_macro::Span` just prints out
the byte range. This can make debugging proc macros (either as a crate
author or as a compiler developer) very frustrating, since neither the
actual filename nor the `SyntaxContext` is displayed.
This commit adds a perma-unstable flag `-Z span-debug`. When enabled,
the `Debug` impl for `proc_macro::Span` simply forwards directly to
`rustc_span::Span`. Once #72618 is merged, this will start displaying
actual line numbers.
While `Debug` impls are not subject to Rust's normal stability
guarnatees, we probably shouldn't expose any additional information on
stable until `#![feature(proc_macro_span)]` is stabilized. Otherwise,
we would be providing a 'backdoor' way to access information that's
supposed be behind unstable APIs.
Ralf Jung [Mon, 8 Jun 2020 07:55:22 +0000 (09:55 +0200)]
Rollup merge of #72615 - jschwe:fix-Zprofile-documentation, r=steveklabnik
Fix documentation example for gcov profiling
closes #72546
Improves the documentation for the unstable Rustflag `-Zprofile` by:
- stating that Incremental compilation must be turned off.
- Adding the other `RUSTFLAGS` that should/need to be turned on (taken from [grcov documentation](https://github.com/mozilla/grcov#example-how-to-generate-gcda-files-for-a-rust-project))
- Mentioning `RUSTC_WRAPPER` to prevent everything getting instrumented.
Ralf Jung [Mon, 8 Jun 2020 07:55:20 +0000 (09:55 +0200)]
Rollup merge of #72583 - CAD97:vec-iter-asref-slice, r=dtolnay
impl AsRef<[T]> for vec::IntoIter<T>
Adds `impl<T> AsRef<[T]> for vec::IntoIter<T>`. This mirrors the same trait impl for [`slice::Iter`](https://doc.rust-lang.org/nightly/std/slice/struct.Iter.html). Both types already offer `fn as_slice(&self) -> &[T]`, this just adds the trait impl for `vec::IntoIter`.
If/when `fn as_slice(&self) -> &[T]` stabilizes for `vec::Drain` and `slice::IterMut`, they should get `AsRef<[T]>` impls as well. As thus, tangentially related to #58957.
My ultimate goal here: being able to use `for<T, I: Iterator<Item=T> + AsRef<[T]>> I` to refer to `vec::IntoIter`, `vec::Drain`, and eventually `array::IntoIter`, as an approximation of the set of by-value iterators that can be "previewed" as by-ref iterators. (Actually expressing that as a trait requires GAT.)
Ralf Jung [Mon, 8 Jun 2020 07:55:18 +0000 (09:55 +0200)]
Rollup merge of #72026 - botika:master, r=estebank
Update annotate-snippets-rs to 0.8.0
#59346
I made major changes to this library. In the previous version we worked with owned while in the current one with borrowed.
I have adapted it without changing the behavior.
I have modified the coverage since the previous one did not return correctly the index of the character in the line.
Dylan DPC [Sun, 7 Jun 2020 16:11:27 +0000 (18:11 +0200)]
Rollup merge of #72952 - pnkfelix:regression-test-for-issue-70924, r=nikomatsakis
run-make regression test for issue #70924.
Sometime after my PR #72767 (to fix issue #70924) landed, I realized that I *could* make a local regression test, thanks to `rustc --print sysroot`: I can make a fresh "copy" (really mostly symlinks) of the sysroot, and then modify it to recreate the terms of this bug.
Joshua Nelson [Sun, 7 Jun 2020 16:01:20 +0000 (12:01 -0400)]
Add Item::is_fake for rustdoc
I wasn't aware items _could_ be fake, so I think having a function
mentioning it could be helpful. Also, I'd need to make this change for
cross-crate intra-doc links anyway, so I figured it's better to make the
refactor separate.
bors [Sun, 7 Jun 2020 14:14:34 +0000 (14:14 +0000)]
Auto merge of #73093 - Dylan-DPC:rollup-9gh5tyu, r=Dylan-DPC
Rollup of 5 pull requests
Successful merges:
- #72764 (Be more careful around ty::Error in generators)
- #72908 (rename FalseEdges -> FalseEdge)
- #72970 (Properly handle feature-gated lints)
- #72998 (Mention that some atomic operations may not be available on some platforms)
- #73063 (Elide type on liballoc vec)