| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Turn off the MIR SROA optimization by default to prevent incorrect
debuginfo generation and rustc ICEs caused by invalid LLVM IR being
created.
Related to #115113
|
|
(cherry picked from commit c7428d50520446ccd44ca89bbbf4ff7a4725570e)
|
|
(cherry picked from commit 9e5a67e57f715ec5eda915db1261cdf4c4a04642)
|
|
unconditional logic otherwise.
(cherry picked from commit a2058ddbed82adda55ce39f0e0915996706cb2b9)
|
|
rustc_codegen_ssa::back::linker::exported_symbols to only export the two symbols that proc-macros need.
(cherry picked from commit 3000c24afc37fe09c65772a71331002a7505dc11)
|
|
Now that this lint runs on any external-ABI fn-ptr, normalization won't
always succeed, so use `try_normalize_erasing_regions` instead.
Signed-off-by: David Wood <david@davidtw.co>
(cherry picked from commit 09434a2575cee12b241c516ad91f21d4b4f9c3fd)
|
|
(cherry picked from commit 45ffe41d144e3e5bc8993abcbcdd54d870a2ff53)
|
|
Consider `()` within types to be FFI-safe, and `()` to be FFI-safe as a
return type (incl. when in a transparent newtype).
Signed-off-by: David Wood <david@davidtw.co>
(cherry picked from commit 24f90fdd2654e9c5437a684d3a72a4e70826a985)
|
|
Simplify this function a bit, it was quite hard to reason about.
Signed-off-by: David Wood <david@davidtw.co>
(cherry picked from commit 99b1897cf640d5f6dac74416761c9b3c75e1ef7a)
|
|
`()` is normally FFI-unsafe, but is FFI-safe when used as a return type.
It is also desirable that a transparent newtype for `()` is FFI-safe when
used as a return type.
In order to support this, when an type was deemed FFI-unsafe, because of
a `()` type, and was used in return type - then the type was considered
FFI-safe. However, this was the wrong approach - it didn't check that the
`()` was part of a transparent newtype! The consequence of this is that
the presence of a `()` type in a more complex return type would make it
the entire type be considered safe (as long as the `()` type was the
first that the lint found) - which is obviously incorrect.
Instead, this logic is removed, and a unit return type or a transparent
wrapper around a unit is checked for directly for functions and fn-ptrs.
Signed-off-by: David Wood <david@davidtw.co>
(cherry picked from commit f53cef31f5ea41c9a5ab8e5335637a6873b9f0b5)
|
|
(cherry picked from commit f25ad54a4d0febbcb2b7e951835228b7b2320b49)
|
|
(cherry picked from commit 3dbbf23e29516218863bda29d2983bd503e6b7fd)
|
|
because sometimes users can't opt out
|
|
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #113005 (Don't call `query_normalize` when reporting similar impls)
- #113064 (std: edit [T]::swap docs)
- #113138 (Add release notes for 1.71.0)
- #113217 (resolve typerelative ctors to adt)
- #113254 (Use consistent formatting in Readme)
- #113482 (Migrate GUI colors test to original CSS color format)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
r=cjgillot
resolve typerelative ctors to adt
Associated issue: #110508
r? ``@spastorino``
|
|
Don't call `query_normalize` when reporting similar impls
Firstly, It's sketchy to be using `query_normalize` at all during HIR typeck -- it's asking for an ICE 😅. Secondly, we're normalizing an impl trait ref that potentially has parameter types in `ty::ParamEnv::empty()`, which is kinda sketchy as well.
The only UI test change from removing this normalization is that we don't evaluate anonymous constants in impls, which end up giving us really ugly suggestions:
```
error[E0277]: the trait bound `[X; 35]: Default` is not satisfied
--> /home/gh-compiler-errors/test.rs:4:5
|
4 | <[X; 35] as Default>::default();
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `Default` is not implemented for `[X; 35]`
|
= help: the following other types implement trait `Default`:
&[T]
&mut [T]
[T; 32]
[T; core::::array::{impl#30}::{constant#0}]
[T; core::::array::{impl#31}::{constant#0}]
[T; core::::array::{impl#32}::{constant#0}]
[T; core::::array::{impl#33}::{constant#0}]
[T; core::::array::{impl#34}::{constant#0}]
and 27 others
```
So just fold the impls with a `BottomUpFolder` that calls `ty::Const::eval`. This doesn't work totally correctly with generic-const-exprs, but it's fine for stable code, and this is error reporting after all.
|
|
Rollup of 7 pull requests
Successful merges:
- #112931 (Enable zlib in LLVM on aarch64-apple-darwin)
- #113158 (tests: unset `RUSTC_LOG_COLOR` in a test)
- #113173 (CI: include workflow name in concurrency group)
- #113335 (Reveal opaques in new solver)
- #113390 (CGU formation tweaks)
- #113399 (Structurally normalize again for byte string lit pat checking)
- #113412 (Add basic types to SMIR)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Add basic types to SMIR
Still incomplete but I think this can be merged and we can keep iterating over it.
r? ``@oli-obk``
|
|
Structurally normalize again for byte string lit pat checking
We need to structurally normalize the pointee of a match scrutinee when trying to match byte string patterns -- we used[^1] to call `structurally_resolve_type`, which errors for type vars[^2], but lcnr added `try_structurally_resolve_type`[^3] in the mean time, which is the right thing to use here since it's totally opportunistic.
Fixes rust-lang/trait-system-refactor-initiative#38
[^1]: #112428
[^2]: #112993
[^3]: #113086
|
|
CGU formation tweaks
Minor improvements I found while trying out something bigger that didn't work out.
r? ``@wesleywiser``
|
|
Reveal opaques in new solver
We were testing against the wrong reveal mode :fearful:
Also a couple of misc commits that I don't want to really put in separate prs
r? ``@lcnr``
|
|
Nilstrieb:pointer-coercions-are-not-casts-because-that-sounds-way-to-general-aaaa, r=oli-obk
Rename `adjustment::PointerCast` and variants using it to `PointerCoercion`
It makes it sounds like the `ExprKind` and `Rvalue` are supposed to represent all pointer related casts, when in reality their just used to share a little enum variants. Make it clear there these are only coercions and that people who see this and think "why are so many pointer related casts not in these variants" aren't insane.
This enum was added in #59987. I'm not sure whether the variant sharing is actually worth it, but this at least makes it less confusing.
r? oli-obk
|
|
Rollup of 8 pull requests
Successful merges:
- #113413 (Add needs-triage to all new issues)
- #113426 (Don't ICE in `resolve_bound_vars` when associated return-type bounds are in bad positions)
- #113427 (Remove `variances_of` on RPITIT GATs, remove its one use-case)
- #113441 (miri: check that assignments do not self-overlap)
- #113453 (Remove unused from_method from rustc_on_unimplemented)
- #113456 (Avoid calling report_forbidden_specialization for RPITITs)
- #113466 (Update cargo)
- #113467 (Fix comment of `fn_can_unwind`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Fix comment of `fn_can_unwind`
Reopen of #113213
|
|
Avoid calling report_forbidden_specialization for RPITITs
Fixes #113438
r? ``@compiler-errors``
|
|
Remove unused from_method from rustc_on_unimplemented
Fixes #113439
`on_unimplemented_note` was calling `item_name` for RPITITs and that produced ICEs. I've added a regression test for that but also have removed `from_method` symbol entirely because it wasn't even used and by doing that the `item_name` call was also removed.
r? ``@compiler-errors``
|
|
miri: check that assignments do not self-overlap
r? `````@oli-obk`````
|
|
r=spastorino
Remove `variances_of` on RPITIT GATs, remove its one use-case
It doesn't make sense to implement variances on a GAT anyways, since we don't relate GATs with variance:
https://github.com/rust-lang/rust/blob/85bf07972a1041b9e25393b803d0e006bec3eaaf/compiler/rustc_middle/src/ty/relate.rs#L569-L579
r? ``@spastorino``
|
|
Require TAITs to be mentioned in the signatures of functions that register hidden types for them
r? `@lcnr` `@compiler-errors`
This implements the lang team decision from [the TAIT design meeting](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/design.20meeting.202023-05-31.20TAITs/near/362518164).
|
|
bad positions
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It makes it sound like the `ExprKind` and `Rvalue` are supposed to represent all pointer related
casts, when in reality their just used to share a some enum variants. Make it clear there these
are only coercion to make it clear why only some pointer related "casts" are in the enum.
|
|
|
|
sanity check field offsets in unsizeable structs
As promised in https://github.com/rust-lang/rust/pull/112062#issuecomment-1567494994, this PR extends the layout sanity checks to ensure that structs fields don't move around when unsizing and prevent issues like https://github.com/rust-lang/rust/issues/112048 in the future. Like most other layout sanity checks, this only runs on compilers with debug assertions enabled.
Here is how it looks when it fails:
```text
error: internal compiler error: compiler/rustc_ty_utils/src/layout.rs:533:21: unsizing GcNode<std::boxed::Box<i32>> changed field order!
Layout { size: Size(32 bytes), align: AbiAndPrefAlign { abi: Align(8 bytes), pref: Align(8 bytes) }, abi: Aggregate { sized: true }, fields: Arbitrary { offsets: [Size(0 bytes), Size(8 bytes), Size(24 bytes)], memory_index: [0, 1, 2] }, largest_niche: Some(Niche { offset: Size(24 bytes), value: Pointer(AddressSpace(0)), valid_range: 1..=18446744073709551615 }), variants: Single { index: 0 } }
Layout { size: Size(24 bytes), align: AbiAndPrefAlign { abi: Align(8 bytes), pref: Align(8 bytes) }, abi: Aggregate { sized: false }, fields: Arbitrary { offsets: [Size(16 bytes), Size(0 bytes), Size(24 bytes)], memory_index: [1, 0, 2] }, largest_niche: None, variants: Single { index: 0 } }
```
r? `@the8472`
|
|
|
|
|
|
|
|
|
|
intermediate `Vec` first
|
|
|
|
|
|
|
