bors [Tue, 28 Jan 2020 20:26:24 +0000 (20:26 +0000)]
Auto merge of #68606 - jonas-schievink:normalize-fastpath, r=Zoxc
Add an early-exit to `QueryNormalizer::fold_ty`
Pulled out from https://github.com/rust-lang/rust/pull/68524, this results in a ~60-70% reduction in compile time for the await-call-tree benchmarks. This should unblock https://github.com/rust-lang/rust/issues/67982 as well.
bors [Tue, 28 Jan 2020 16:25:35 +0000 (16:25 +0000)]
Auto merge of #68533 - tmiasko:compiletest, r=nikomatsakis
compiletest: Unit tests for `EarlyProps` (+ small cleanup)
* Parse `EarlyProps` from a reader
* Add unit tests for `EarlyProps`
* Remove unused `llvm-cxxflags` option
* Remove unnecessary memory allocations in `iter_header`
* Update mode list displayed in `--help`
bors [Tue, 28 Jan 2020 08:44:20 +0000 (08:44 +0000)]
Auto merge of #68529 - TimDiekmann:rename-alloc, r=Amanieu
Rename `Alloc` to `AllocRef`
The allocator-wg has decided to merge this change upstream in https://github.com/rust-lang/wg-allocators/issues/8#issuecomment-577122958.
This renames `Alloc` to `AllocRef` because types that implement `Alloc` are a reference, smart pointer, or ZSTs. It is not possible to have an allocator like `MyAlloc([u8; N])`, that owns the memory and also implements `Alloc`, since that would mean, that moving a `Vec<T, MyAlloc>` would need to correct the internal pointer, which is not possible as we don't have move constructors.
For further explanation please see https://github.com/rust-lang/wg-allocators/issues/8#issuecomment-489464843 and the comments after that one.
Additionally it clarifies the semantics of `Clone` on an allocator. In the case of `AllocRef`, it is clear that the cloned handle still points to the same allocator instance, and that you can free data allocated from one handle with another handle.
The initial proposal was to rename `Alloc` to `AllocHandle`, but `Ref` expresses the semantics better than `Handle`. Also, the only appearance of `Handle` in `std` are for windows specific resources, which might be confusing.
Blocked on https://github.com/rust-lang/miri/pull/1160
bors [Tue, 28 Jan 2020 05:31:34 +0000 (05:31 +0000)]
Auto merge of #68234 - CAD97:slice-from-raw-parts, r=KodrAus
Stabilize ptr::slice_from_raw_parts[_mut]
Closes #36925, the tracking issue.
Initial impl: #60667
r? @rust-lang/libs
In addition to stabilizing, I've adjusted the example of `ptr::slice_from_raw_parts` to use `slice_from_raw_parts` instead of `slice_from_raw_parts_mut`, which was unnecessary for the example as written.
Yuki Okushi [Tue, 28 Jan 2020 01:48:17 +0000 (10:48 +0900)]
Rollup merge of #68570 - cr1901:msp430-fix-1-2020, r=alexcrichton
Bump LLVM submodule to fix LLVM assertion failure in MSP430 interrupt generation.
This PR brings in changes introduced by [this cherry-pick](https://github.com/rust-lang/llvm-project/pull/37) to the Rust repository.
Nightlies downloaded from `rustup` do not appear to have llvm assertions enabled; the assertion failure [sometimes](https://github.com/YuhanLiin/msp430fr2355-quickstart/issues/3) causes link errors that shouldn't occur. I couldn't find any indication of other bugs; however, it should still be fixed.
These methods are small and self-contained, and are used as the basis for the existing `DebugMap::entry` method, so have been used in the wild for the last 6 months or so.
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.
projects / rust.git / log