bors [Mon, 27 Jan 2020 11:59:57 +0000 (11:59 +0000)]
Auto merge of #68566 - pietroalbini:rollup-22hbo3e, r=pietroalbini
Rollup of 4 pull requests
Successful merges:
- #67928 (Update RELEASES.md for 1.41.0)
- #68370 (Ensure that we error when calling "const extern fn" with wrong convention)
- #68531 ([self-profiler] Two small cleanups)
- #68562 (Fix spelling errors)
bors [Mon, 27 Jan 2020 08:42:56 +0000 (08:42 +0000)]
Auto merge of #68165 - thomcc:lt_ones, r=sfackler
Add leading_ones and trailing_ones methods to the primitive integer types
I was surprised these were missing (given that `leading_zeros` and `trailing_zeros` exist), and they seem trivial and hopefully not controversial.
Note that there's some precedent in that `count_ones` and `count_zeros` are both supported even though only one of these has an intrinsic.
I'm not sure if these need a `rustc_const_unstable` flag (the tests don't seem to mind that it's missing). I just made them const, since there's not really any reason for these to be non-const when the `_zeros` variants are const.
Note: My understanding is trivial stuff like (hopefully) this can land without an RFC, but I'm not fully sure about the process though. Questions like "when does the tracking issue get filed?", are a total mystery to me. So, any guidance is appreciated, and sorry in advance if I should have gone through some more involved process for this.
bors [Mon, 27 Jan 2020 03:01:59 +0000 (03:01 +0000)]
Auto merge of #68447 - estebank:sugg-type-param, r=petrochenkov
Suggest defining type parameter when appropriate
```
error[E0412]: cannot find type `T` in this scope
--> file.rs:3:12
|
3 | impl Trait<T> for Struct {}
| - ^ not found in this scope
| |
| help: you might be missing a type parameter: `<T>`
```
A `struct` with only a single non-ZST field (let's call it `foo`) can be marked as `#[repr(transparent)]`. Such a `struct` has the same layout and ABI as `foo`. Here, we also extend this ability to `enum`s with only one variant, subject to the same restrictions as for the equivalent `struct`. That is, you can now write:
which, in terms of layout and ABI, is equivalent to:
```rust
#[repr(transparent)]
struct Foo(u8);
```
## Motivation
This is not a major feature that will unlock new and important use-cases. The utility of `repr(transparent)` `enum`s is indeed limited. However, there is still some value in it:
1. It provides conceptual simplification of the language in terms of treating univariant `enum`s and `struct`s the same, as both are product types. Indeed, languages like Haskell only have `data` as the only way to construct user-defined ADTs in the language.
2. In rare occasions, it might be that the user started out with a univariant `enum` for whatever reason (e.g. they thought they might extend it later). Now they want to make this `enum` `transparent` without breaking users by turning it into a `struct`. By lifting the restriction here, now they can.
## Technical specification
The reference specifies [`repr(transparent)` on a `struct`](https://doc.rust-lang.org/nightly/reference/type-layout.html#the-transparent-representation) as:
> ### The transparent Representation
>
> The `transparent` representation can only be used on `struct`s that have:
> - a single field with non-zero size, and
> - any number of fields with size 0 and alignment 1 (e.g. `PhantomData<T>`).
>
> Structs with this representation have the same layout and ABI as the single non-zero sized field.
>
> This is different than the `C` representation because a struct with the `C` representation will always have the ABI of a `C` `struct` while, for example, a struct with the `transparent` representation with a primitive field will have the ABI of the primitive field.
>
> Because this representation delegates type layout to another type, it cannot be used with any other representation.
Here, we amend this to include univariant `enum`s as well with the same static restrictions and the same effects on dynamic semantics.
## Tests
All the relevant tests are adjusted in the PR diff but are recounted here:
- `src/test/ui/repr/repr-transparent.rs` checks that `repr(transparent)` on an `enum` must be univariant, rather than having zero or more than one variant. Restrictions on the fields inside the only variants, like for those on `struct`s, are also checked here.
- A number of codegen tests are provided as well:
- `src/test/codegen/repr-transparent.rs` (the canonical test)
- `src/test/codegen/repr-transparent-aggregates-1.rs`
- `src/test/codegen/repr-transparent-aggregates-2.rs`
- `src/test/codegen/repr-transparent-aggregates-3.rs`
- `src/test/ui/lint/lint-ctypes-enum.rs` tests the interactions with the `improper_ctypes` lint.
## History
- 2019-04-30, RFC https://github.com/rust-lang/rfcs/pull/2645
Author: @mjbshaw
Reviewers: The Language Team
This is the RFC that proposes allowing `#[repr(transparent)]` on `enum`s and `union`.
- 2019-06-11, PR https://github.com/rust-lang/rust/pull/60463
Author: @mjbshaw
Reviewers: @varkor and @rkruppe
The PR reorganizes the static checks taking advantage of the fact that `struct`s and `union`s are internally represented as ADTs with a single variant.
- This PR stabilizes `transparent_enums`.
## Related / possible future work
The remaining work here is to figure out the semantics of `#[repr(transparent)]` on `union`s and stabilize those. This work continues to be tracked in https://github.com/rust-lang/rust/issues/60405.
bors [Sun, 26 Jan 2020 21:01:13 +0000 (21:01 +0000)]
Auto merge of #68407 - eddyb:iter-macro-backtrace, r=petrochenkov
rustc_span: return an impl Iterator instead of a Vec from macro_backtrace.
Having `Span::macro_backtrace` produce an `impl Iterator<Item = ExpnData>` allows #67359 to use it instead of rolling its own similar functionality.
The move from `MacroBacktrace` to `ExpnData` (which the first two commits are prerequisites for) both eliminates unnecessary allocations, and is strictly more flexible (exposes more information).
Esteban Küber [Wed, 22 Jan 2020 07:01:21 +0000 (23:01 -0800)]
Suggest defining type parameter when appropriate
```
error[E0412]: cannot find type `T` in this scope
--> file.rs:3:12
|
3 | impl Trait<T> for Struct {}
| - ^ not found in this scope
| |
| help: you might be missing a type parameter: `<T>`
```
bors [Sun, 26 Jan 2020 08:36:23 +0000 (08:36 +0000)]
Auto merge of #68522 - estebank:impl-trait-sugg-2, r=oli-obk
Further improve `impl Trait`/`dyn Trait` suggestions
After reading [_Returning Trait Objects_ by Bryce Fisher-Fleig](https://bryce.fisher-fleig.org/blog/returning-trait-objects/), [I noticed that](https://www.reddit.com/r/rust/comments/esueur/returning_trait_objects/ffczl4k/) #68195 had a few bugs due to not ignoring `ty::Error`.
- Account for `ty::Error`.
- Account for `if`/`else` and `match` blocks when pointing at return types and referencing their types.
- Increase the multiline suggestion output from 6 lines to 20.
bors [Sat, 25 Jan 2020 22:44:39 +0000 (22:44 +0000)]
Auto merge of #68546 - JohnTitor:rollup-znuot4b, r=JohnTitor
Rollup of 5 pull requests
Successful merges:
- #68485 (add a test for #60976)
- #68498 (Add some type-alias-impl-trait regression tests)
- #68514 (Use Self instead of self return type)
- #68534 (Update submodules to rust-lang)
- #68540 (clean up error codes E0229 and E0261)
bors [Sat, 25 Jan 2020 07:49:40 +0000 (07:49 +0000)]
Auto merge of #68448 - maurer:dyn-cdylib, r=alexcrichton
rustc: Allow cdylibs to link against dylibs
Previously, rustc mandated that cdylibs could only link against rlibs as dependencies (not dylibs).
This commit disables that restriction and tests that it works in a simple case.
I don't have a windows rustc dev environment, so I guessed at the MSVC test code, I'm hoping the CI can run that for me.
Additionally, we might want to consider emitting (through cargo or rustc) some metadata to help C users of a cdylib figure out where all the dylibs they need are. I don't think that should be needed to land this change, as it will still be usable by homogeneous build systems without it.
My new test was templated off the `tests/run-make-fulldeps/cdylib` test. It seemed more appropriate to have it as a separate test, since both foo.rs and bar.rs would need to be replicated to make that test cover both cases, but I can do that if it would be preferred.
If I'm doing anything out of order/process, please let me know; this is only my second change to rustc and the prior one was trivial.
bors [Fri, 24 Jan 2020 23:04:54 +0000 (23:04 +0000)]
Auto merge of #68526 - JohnTitor:rollup-3mmljof, r=JohnTitor
Rollup of 6 pull requests
Successful merges:
- #68111 (Print constants in `type_name` for const generics)
- #68374 (Fix invalid link to the C++ Exception Handling ABI documentation)
- #68504 (Use check-pass mode for lint tests and nll tests)
- #68509 (Clean up error codes E0223 and E0225 explanations)
- #68511 (Remove unused ignore-license directives)
- #68515 (Support feature process_set_argv0 for VxWorks)
r? @oli-obk as there may have been a deliberate decision not to in https://github.com/rust-lang/rust/commit/5b9848912a85e28d000602fc2e81bad9c2f2a981#diff-4ed1a72c0bfdf17be769ed520932cd02R80.
bors [Fri, 24 Jan 2020 14:00:56 +0000 (14:00 +0000)]
Auto merge of #68414 - michaelwoerister:share-drop-glue, r=alexcrichton
Also share drop-glue when compiling with -Zshare-generics (i.e. at opt-level=0)
This PR adds drop-glue to the set of monomorphizations that can be shared across crates via `-Zshare-generics`.
This version of the PR might have detrimental effects on performance as it makes lots of stuff dependent on a single query results (`upstream_monomorphizations_for(def_id_of_drop_in_place)`). That should be fixable but let's do a perf run first.
Potentially fixes issue https://github.com/rust-lang/rust/issues/64140. (cc @alexcrichton)
The changes here are related to @matthewjasper's https://github.com/rust-lang/rust/pull/67332 but should be mostly orthogonal.
bors [Fri, 24 Jan 2020 08:32:10 +0000 (08:32 +0000)]
Auto merge of #68506 - tmandry:rollup-kz9d33v, r=tmandry
Rollup of 7 pull requests
Successful merges:
- #68424 (Suggest borrowing `Vec<NonCopy>` in for loop)
- #68438 (Account for non-types in substs for opaque type error messages)
- #68469 (Avoid overflow in `std::iter::Skip::count`)
- #68473 (Enable ASan on Fuchsia)
- #68479 (Implement `unused_parens` for block return values)
- #68483 (Add my (@flip1995) name to .mailmap)
- #68500 (Clear out std, not std tools)
Tyler Mandry [Fri, 24 Jan 2020 08:30:58 +0000 (00:30 -0800)]
Rollup merge of #68473 - nopsledder:rust_sanitizer_fuchsia, r=alexcrichton
Enable ASan on Fuchsia
This change adds the x86_64-fuchsia and aarch64-fuchsia LLVM targets to
those allowed to invoke -Zsanitizer. Currently, the only overlap between
compiler_rt sanitizers supported by both rustc and Fuchsia is ASan.
Matthew Maurer [Wed, 22 Jan 2020 06:47:03 +0000 (22:47 -0800)]
rustc: Allow cdylibs to link against dylibs
Previously, rustc mandated that cdylibs could only link against rlibs as
dependencies (not dylibs).
This commit disables that restriction and tests that it works in a
simple case.
bors [Thu, 23 Jan 2020 19:39:07 +0000 (19:39 +0000)]
Auto merge of #68391 - tmiasko:compiletest-debuginfo, r=alexcrichton
compiletest: Simplify multi-debugger support
Previous implementation used a single mode type to store various pieces
of otherwise loosely related information:
* Whether debuginfo mode is in use or not.
* Which debuggers should run in general.
* Which debuggers are enabled for particular test case.
The new implementation introduces a separation between those aspects.
There is a single debuginfo mode parametrized by a debugger type.
The debugger detection is performed first and a separate configuration
is created for each detected debugger. The test cases are gathered
independently for each debugger which makes it trivial to implement
support for `ignore` / `only` conditions.
Functional changes:
* A single `debuginfo` entry point (rather than `debuginfo-cdb`, `debuginfo-gdb+lldb`, etc.).
* Debugger name is included in the test name.
* Test outputs are placed in per-debugger directory.
* Fixed spurious hash mismatch. Previously, the config mode would change
from `DebugInfoGdbLldb` (when collecting tests) to `DebugInfoGdb` or
`DebugInfoLldb` (when running them) which would affect hash computation.
* PYTHONPATH is additionally included in gdb hash.
* lldb-python and lldb-python-dir are additionally included in lldb hash.
bors [Thu, 23 Jan 2020 03:48:07 +0000 (03:48 +0000)]
Auto merge of #68298 - Mark-Simulacrum:binary-depdep-fix, r=petrochenkov
Avoid declaring a fake dependency edge
When we're producing an rlib, we do not need anything more than an rmeta file
for each of our dependencies (this is indeed utilized by Cargo for pipelining).
Previously, we were still storing the paths of possible rlib/dylib crates, which
meant that they could still plausibly be accessed. With -Zbinary-dep-depinfo,
that meant that Cargo thought that rustc was using both the rlib and an (earlier
emitted) rmeta, and so needed a recompile, as the rlib may have finished writing
*after* compilation started (for more detail, see issue 68149).
This commit changes metadata loading to not store the filepaths of dylib/rlib if
we're going to end up creating an rlib only.
Tyler Mandry [Thu, 23 Jan 2020 00:02:19 +0000 (16:02 -0800)]
Rollup merge of #68440 - matthiaskrgr:xpyclippy, r=Mark-Simulacrum
bootstrap: update clippy subcmd decription
Clarify where the clippy used in `./x.py clippy` is coming from.
It uses whatever clippy binary was installed via rustup, cargo-install
or otherwise and does NOT use the binary generated by `./x.py build src/tools/clippy`.