| Age | Commit message (Collapse) | Author | Lines |
|
|
|
(And added Ralf's suggested test.)
Added my own three-variant multi-variant as well.
|
|
|
|
This is a minimal regression test for the issue #68794: "TEXTREL in
i686", which was fixed with e86019c4a0968a1e393cdd0731649168624a88b8.
The test links a minimal rust static library into a shared library, and
checks that the linker didn't have to add the TEXTREL flag.
|
|
This change avoids the ICE by actually emitting an appropriate error. The
output will be duplicated in some cases, but that's better than the
avoidable ICE.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This fixes a a segfault in safe code, a stable regression. Reported in
\#69225.
This reverts commit a983e0590a43ed8b0f60417828efd4e79b51f494.
Also adds a test for the expected behaviour.
|
|
Disable the testcase for Vxworks.
r? @alexcrichton
|
|
Don't call `tcx.fn_sig` on closures
Fixes #68542
|
|
|
|
Fix spelling errors
|
|
Ensure that we error when calling "const extern fn" with wrong convention
See #64926
|
|
Fixes #68542
|
|
|
|
See #64926
|
|
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>`
```
Fix #64298.
|
|
Stabilize `#[repr(transparent)]` on `enum`s in Rust 1.42.0
# Stabilization report
The following is the stabilization report for `#![feature(transparent_enums)]`.
Tracking issue: https://github.com/rust-lang/rust/issues/60405
[Version target](https://forge.rust-lang.org/#current-release-versions): 1.42 (2020-01-30 => beta, 2020-03-12 => stable).
## User guide
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:
```rust
#[repr(transparent)]
enum Foo { Bar(u8) }
```
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 implements the RFC aforementioned in full.
- 2019, PR https://github.com/rust-lang/rust/pull/67323
Author: @Centril
Reviewers: @davidtwco
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.
|
|
```
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>`
```
Fix #64298.
|
|
|
|
Use better bound names in `-Zverbose` mode
r? @petrochenkov as per https://github.com/rust-lang/rust/pull/67951/files#r365524015
|
|
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.
|
|
Don't use spaces before type ascription like colons
Split out of #67133 to make that PR simpler
r? @eddyb
|
|
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)
Failed merges:
r? @ghost
|
|
Add some type-alias-impl-trait regression tests
Fixes #57611
Fixes #57807
|
|
add a test for #60976
The test fails on 1.36.0 but passes on master.
Huge thanks for @hellow554 actually digging out the minimized version of the
repro.
Fixes #60976.
|
|
|
|
|
|
Do not ICE on multipart suggestions touching multiple files
When encountering a multipart suggestion with spans belonging to
different contexts, skip that suggestion.
Fix #68449. Similar to #68256.
|
|
Update LLVM to fix crash on Emscripten targets
Fixes #66308 (for real this time). r? @alexcrichton
|
|
Render const pointers in MIR more compactly
Split out from #67133 to make that PR simpler
cc @RalfJung
r? @eddyb
|
|
|
|
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.
r? alexcrichton
|
|
Suggest to shorten temporary borrow from raw pointer
Closes https://github.com/rust-lang/rust/issues/65436
r? @estebank
cc @tmandry
|
|
Fixes #57611
Fixes #57807
|
|
When encountering a multipart suggestion with spans belonging to
different contexts, skip that suggestion.
|
|
Remove unused ignore-license directives
The tidy check was removed in rust-lang/rust#53617
|
|
Use check-pass mode for lint tests and nll tests
Helps with issue #62277.
|
|
Print constants in `type_name` for const generics
Fixes https://github.com/rust-lang/rust/issues/65372.
r? @oli-obk as there may have been a deliberate decision not to in https://github.com/rust-lang/rust/commit/5b9848912a85e28d000602fc2e81bad9c2f2a981#diff-4ed1a72c0bfdf17be769ed520932cd02R80.
|
|
|
|
|
|
|