Commit Graph

3806 Commits

Author SHA1 Message Date
bors
31395ec382 Auto merge of #113687 - saethlin:inline-assertion-helpers, r=cuviper
Add #[inline] to core debug assertion helpers

These functions are called a lot and not inlined by default in a dev compiler. Adding `#[inline]` should improve things in a dev workflow and be irrelevant in the distributed library.
2023-07-24 21:29:35 +00:00
bors
fd56162af0 Auto merge of #113921 - davidtwco:lint-ctypes-issue-113900, r=petrochenkov
lint/ctypes: only try normalize

Fixes #113900.

Now that this lint runs on any external-ABI fn-ptr, normalization won't always succeed, so use `try_normalize_erasing_regions` instead.
2023-07-24 19:40:01 +00:00
bors
fc8a3e357a Auto merge of #114024 - matthiaskrgr:rollup-uhdbq64, r=matthiaskrgr
Rollup of 8 pull requests

Successful merges:

 - #113969 (add dynamic for smir)
 - #113985 (Use erased self type when autoderefing for trait error suggestion)
 - #113987 (Comment stuff in the new solver)
 - #113992 (arm-none fixups)
 - #113993 (Optimize format usage)
 - #113994 (Optimize format usage)
 - #114006 (Update sparc-unknown-none-elf platform README)
 - #114021 (Add missing documentation for `Session::time`)

r? `@ghost`
`@rustbot` modify labels: rollup
2023-07-24 17:13:24 +00:00
Matthias Krüger
15c723433f
Rollup merge of #113985 - compiler-errors:issue-113951, r=estebank
Use erased self type when autoderefing for trait error suggestion

Let's not try to pass something from `skip_binder` into autoderef.

Fixes #113951
2023-07-24 17:47:08 +02:00
bors
cb6ab9516b Auto merge of #113956 - fmease:rustdoc-fix-x-crate-rpitits, r=GuillaumeGomez,compiler-errors
rustdoc: handle cross-crate RPITITs correctly

Filter out the internal associated types synthesized during the desugaring of RPITITs, they really shouldn't show up in the docs.

This also fixes #113929 since we're no longer invoking `is_impossible_associated_item` (renamed from `is_impossible_method`) which cannot handle them (leading to an ICE). I don't think it makes sense to try to make `is_impossible_associated_item` handle this exotic kind of associated type (CC original author `@compiler-errors).`

@ T-rustdoc reviewers, currently I'm throwing out ITIT assoc tys before cleaning assoc tys at each usage-site. I'm thinking about making `clean_middle_assoc_item` return an `Option<_>` instead and doing the check inside of it to prevent any call sites from forgetting the check for ITITs. Since I wasn't sure if you would like that approach, I didn't go through with it. Let me know what you think.

<details><summary>Explanation on why <code>is_impossible_associated_item(itit_assoc_ty)</code> leads to an ICE</summary>

Given the following code:

```rs
pub trait Trait { fn def<T>() -> impl Default {} }
impl Trait for () {}
```

The generated associated type looks something like (simplified):

```rs
type {opaque#0}<T>: Default = impl Default; // the name is actually `kw::Empty` but this is the `def_path_str` repr
```

The query `is_impossible_associated_item` goes through all predicates of the associated item – in this case `<T as Sized>` – to check if they contain any generic parameters from the (generic) associated type itself. For predicates that don't contain any *own* generics, it does further processing, part of which is instantiating the predicate with the generic arguments of the impl block (which is only correct if they truly don't contain any own generics since they wouldn't get instantiated this way leading to an ICE).

It checks if `parent_def_id(T) == assoc_ty_def_id` to get to know if `T` is owned by the assoc ty. Unfortunately this doesn't work for ITIT assoc tys. In this case, the parent of `T` is `Trait::def` (!) which is the associated function (I'm pretty sure this is very intentional) which is of course not equal to the assoc ty `Trait::{opaque#0}`.

</details>

`@rustbot` label A-cross-crate-reexports
2023-07-24 15:19:00 +00:00
Michael Goulet
d1380a1844 Use erased self type when autoderefing for trait error suggestion 2023-07-23 14:13:52 -04:00
bors
8771282d4e Auto merge of #113976 - GuillaumeGomez:migrate-gui-test-color-23, r=notriddle
Migrate GUI colors test to original CSS color format

Follow-up of https://github.com/rust-lang/rust/pull/111459.

r? `@notriddle`
2023-07-23 17:46:36 +00:00
Guillaume Gomez
e06633fde6 Migrate GUI colors test to original CSS color format 2023-07-23 13:05:40 +02:00
bors
1c44af9b79 Auto merge of #111836 - calebzulawski:target-feature-closure, r=workingjubilee
Fix #[inline(always)] on closures with target feature 1.1

Fixes #108655.  I think this is the most obvious solution that isn't overly complicated.  The comment includes more justification, but I think this is likely better than demoting the `#[inline(always)]` to `#[inline]`, since existing code is unaffected.
2023-07-23 00:16:03 +00:00
bors
1d56e3a6d9 Auto merge of #112953 - compiler-errors:interpolated-block-exprs, r=WaffleLapkin
Support interpolated block for `try` and `async`

I'm putting this up for T-lang discussion, to decide whether or not they feel like this should be supported. This was raised in #112952, which surprised me. There doesn't seem to be a *technical* reason why we don't support this.

### Precedent:

This is supported:

```rust
macro_rules! always {
  ($block:block) => {
    if true $block
  }
}

fn main() {
    always!({});
}
```

### Counterpoint:

However, for context, this is *not* supported:

```rust
macro_rules! unsafe_block {
  ($block:block) => {
    unsafe $block
  }
}

fn main() {
    unsafe_block!({});
}
```

If this support for `async` and `try` with interpolated blocks is *not* desirable, then I can convert them to instead the same diagnostic as `unsafe $block` and make this situation a lot less ambiguous.

----

I'll try to write up more before T-lang triage on Tuesday. I couldn't find anything other than #69760 for why something like `unsafe $block` is not supported, and even that PR doesn't have much information.

Fixes #112952
2023-07-22 20:37:44 +00:00
Matthias Krüger
52153432a8
Rollup merge of #113959 - GuillaumeGomez:migrate-gui-test-color-22, r=notriddle
Migrate GUI colors test to original CSS color format

Follow-up of https://github.com/rust-lang/rust/pull/111459.

r? `@notriddle`
2023-07-22 19:57:38 +02:00
Matthias Krüger
b7183bd167
Rollup merge of #113957 - Urgau:regression-test-issue-113941, r=dtolnay
Add regression test for issue #113941 - naive layout isn't refined

This PR adds a regression test for issue #113941 - `the naive layout isn't refined by the actual layout` based on the minimized repro https://github.com/rust-lang/rust/issues/113941#issuecomment-1646446769.
2023-07-22 19:57:37 +02:00
Matthias Krüger
0ed5f091a6
Rollup merge of #112508 - compiler-errors:trait-sig-lifetime-sugg-ice, r=cjgillot
Tweak spans for self arg, fix borrow suggestion for signature mismatch

1. Adjust a suggestion message that was annoying me
2. Fix #112503 by recording the right spans for the `self` part of the `&self` 0th argument
3. Remove the suggestion for adjusting a trait signature on type mismatch, bc that's gonna probably break all the other impls of the trait even if it fixes its one usage 😅
2023-07-22 19:57:35 +02:00
Ben Kimock
65e52bb26c Add #[inline] to core debug assertion helpers 2023-07-22 12:07:06 -04:00
Michael Goulet
7b962d7543 Support interpolated block for try and async 2023-07-22 15:22:12 +00:00
Guillaume Gomez
d4ce83c385 Migrate GUI colors test to original CSS color format 2023-07-22 14:01:23 +02:00
Urgau
ffa4b6f422 Add regression test for issue #113941 - naive layout isn't refined 2023-07-22 13:02:59 +02:00
León Orell Valerian Liehr
5924043b86
rustdoc: handle cross-crate RPITITs correctly 2023-07-22 12:20:17 +02:00
David Tolnay
5bbf0a8306
Revert "Auto merge of #113166 - moulins:ref-niches-initial, r=oli-obk"
This reverts commit 557359f925, reversing
changes made to 1e6c09a803.
2023-07-21 22:35:57 -07:00
Miguel Ojeda
74b8d324eb Support .comment section like GCC/Clang (!llvm.ident)
Both GCC and Clang write by default a `.comment` section with compiler
information:

```txt
$ gcc -c -xc /dev/null && readelf -p '.comment' null.o

String dump of section '.comment':
  [     1]  GCC: (GNU) 11.2.0

$ clang -c -xc /dev/null && readelf -p '.comment' null.o

String dump of section '.comment':
  [     1]  clang version 14.0.1 (https://github.com/llvm/llvm-project.git c62053979489ccb002efe411c3af059addcb5d7d)
```

They also implement the `-Qn` flag to avoid doing so:

```txt
$ gcc -Qn -c -xc /dev/null && readelf -p '.comment' null.o
readelf: Warning: Section '.comment' was not dumped because it does not exist!

$ clang -Qn -c -xc /dev/null && readelf -p '.comment' null.o
readelf: Warning: Section '.comment' was not dumped because it does not exist!
```

So far, `rustc` only does it for WebAssembly targets and only
when debug info is enabled:

```txt
$ echo 'fn main(){}' | rustc --target=wasm32-unknown-unknown --emit=llvm-ir -Cdebuginfo=2 - && grep llvm.ident rust_out.ll
!llvm.ident = !{!27}
```

In the RFC part of this PR it was decided to always add
the information, which gets us closer to other popular compilers.
An opt-out flag like GCC and Clang may be added later on if deemed
necessary.

Implementation-wise, this covers both `ModuleLlvm::new()` and
`ModuleLlvm::new_metadata()` cases by moving the addition to
`context::create_module` and adds a few test cases.

ThinLTO also sees the `llvm.ident` named metadata duplicated (in
temporary outputs), so this deduplicates it like it is done for
`wasm.custom_sections`. The tests also check this duplication does
not take place.

Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2023-07-21 22:01:50 +02:00
bors
c3c5a5c5f7 Auto merge of #113922 - matthiaskrgr:rollup-90cj2vv, r=matthiaskrgr
Rollup of 4 pull requests

Successful merges:

 - #113887 (new solver: add a separate cache for coherence)
 - #113910 (Add FnPtr ty to SMIR)
 - #113913 (error/E0691: include alignment in error message)
 - #113914 (rustc_target: drop duplicate code)

r? `@ghost`
`@rustbot` modify labels: rollup
2023-07-21 16:52:21 +00:00
Matthias Krüger
4a90553717
Rollup merge of #113913 - dvdhrm:pr/transpalign, r=jackh726
error/E0691: include alignment in error message

Include the computed alignment of the violating field when rejecting transparent types with non-trivially aligned ZSTs.

ZST member fields in transparent types must have an alignment of 1 (to ensure it does not raise the layout requirements of the transparent field). The current error message looks like this:

```text
 LL | struct Foobar(u32, [u32; 0]);
    |                    ^^^^^^^^ has alignment larger than 1
```

This patch changes the report to include the alignment of the violating field:

```text
 LL | struct Foobar(u32, [u32; 0]);
    |                    ^^^^^^^^ has alignment of 4, which is larger than 1
```

In case of unknown alignments, it will yield:

```text
 LL | struct Foobar(u32, [u32; 0]);
    |                    ^^^^^^^^ may have alignment larger than 1
```

This allows developers to get a better grasp why a specific field is rejected. Knowing the alignment of the violating field makes it easier to judge where that alignment-requirement originates, and thus hopefully provide better hints on how to mitigate the problem.

This idea was proposed in 2022 in #98071 as part of a bigger change. This commit simply extracts this error-message change, to decouple it from the other diagnostic improvements.

(Originally proposed by `@compiler-errors` in #98071)
2023-07-21 17:17:42 +02:00
bors
557359f925 Auto merge of #113166 - moulins:ref-niches-initial, r=oli-obk
Prototype: Add unstable `-Z reference-niches` option

MCP: rust-lang/compiler-team#641
Relevant RFC: rust-lang/rfcs#3204

This prototype adds a new `-Z reference-niches` option, controlling the range of valid bit-patterns for reference types (`&T` and `&mut T`), thereby enabling new enum niching opportunities. Like `-Z randomize-layout`, this setting is crate-local; as such, references to built-in types (primitives, tuples, ...) are not affected.

The possible settings are (here, `MAX` denotes the all-1 bit-pattern):
| `-Z reference-niches=` | Valid range |
|:---:|:---:|
| `null` (the default) | `1..=MAX` |
| `size` | `1..=(MAX- size)` |
| `align` | `align..=MAX.align_down_to(align)` |
| `size,align` | `align..=(MAX-size).align_down_to(align)` |

------

This is very WIP, and I'm not sure the approach I've taken here is the best one, but stage 1 tests pass locally; I believe this is in a good enough state to unleash this upon unsuspecting 3rd-party code, and see what breaks.
2023-07-21 15:00:36 +00:00
David Wood
09434a2575
lint/ctypes: only try normalize
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>
2023-07-21 15:42:25 +01:00
Moulins
7f109086ee Track (partial) niche information in NaiveLayout
Still more complexity, but this allows computing exact `NaiveLayout`s
for null-optimized enums, and thus allows calls like
`transmute::<Option<&T>, &U>()` to work in generic contexts.
2023-07-21 14:23:23 +02:00
David Rheinsberg
b0dadff6de error/E0691: include alignment in error message
Include the computed alignment of the violating field when rejecting
transparent types with non-trivially aligned ZSTs.

ZST member fields in transparent types must have an alignment of 1 (to
ensure it does not raise the layout requirements of the transparent
field). The current error message looks like this:

 LL | struct Foobar(u32, [u32; 0]);
    |                    ^^^^^^^^ has alignment larger than 1

This patch changes the report to include the alignment of the violating
field:

 LL | struct Foobar(u32, [u32; 0]);
    |                    ^^^^^^^^ has alignment of 4, which is larger than 1

In case of unknown alignments, it will yield:

 LL | struct Foobar<T>(u32, [T; 0]);
    |                       ^^^^^^ may have alignment larger than 1

This allows developers to get a better grasp why a specific field is
rejected. Knowing the alignment of the violating field makes it easier
to judge where that alignment-requirement originates, and thus hopefully
provide better hints on how to mitigate the problem.

This idea was proposed in 2022 in #98071 as part of a bigger change.
This commit simply extracts this error-message change, to decouple it
from the other diagnostic improvements.
2023-07-21 11:04:16 +02:00
Matthias Krüger
b1d1e99c22
Rollup merge of #113780 - dtolnay:printkindpath, r=b-naber
Support `--print KIND=PATH` command line syntax

As is already done for `--emit KIND=PATH` and `-L KIND=PATH`.

In the discussion of #110785, it was pointed out that `--print KIND=PATH` is nicer than trying to apply the single global `-o` path to `--print`'s output, because in general there can be multiple print requests within a single rustc invocation, and anyway `-o` would already be used for a different meaning in the case of `link-args` and `native-static-libs`.

I am interested in using `--print cfg=PATH` in Buck2. Currently Buck2 works around the lack of support for `--print KIND=PATH` by [indirecting through a Python wrapper script](d43cf3a51a/prelude/rust/tools/get_rustc_cfg.py) to redirect rustc's stdout into the location dictated by the build system.

From skimming Cargo's usages of `--print`, it definitely seems like it would benefit from `--print KIND=PATH` too. Currently it is working around the lack of this by inserting `--crate-name=___ --print=crate-name` so that it can look for a line containing `___` as a delimiter between the 2 other `--print` informations it actually cares about. This is commented as a "HACK" and "abuse". 31eda6f7c3/src/cargo/core/compiler/build_context/target_info.rs (L242) (FYI `@weihanglo` as you dealt with this recently in https://github.com/rust-lang/cargo/pull/11633.)

Mentioning reviewers active in #110785: `@fee1-dead` `@jyn514` `@bjorn3`
2023-07-21 06:52:28 +02:00
Moulins
feb20f2fe7 Track ABI info. in NaiveLayout, and use it for PointerLike checks
THis significantly complicates `NaiveLayout` logic, but is necessary to
ensure that bounds like `NonNull<T>: PointerLike` hold in generic
contexts.

Also implement exact layout computation for structs.
2023-07-21 03:31:46 +02:00
Moulins
c30fbb95a6 Track exactness in NaiveLayout and use it for SizeSkeleton checks 2023-07-21 03:31:46 +02:00
Moulins
30ae640a3c properly handle arrays and wide pointers in naive_layout_of 2023-07-21 03:31:45 +02:00
Moulins
cb8b1d1bc9 add naive_layout_of query 2023-07-21 03:31:45 +02:00
bors
c720a9cd12 Auto merge of #113344 - scottmcm:alt-slice-zst-handing, r=the8472
Get `!nonnull` metadata on slice iterators, without `assume`s

This updates the non-ZST paths to read the end pointer through a pointer-to-`NonNull`, so that they all get `!nonnull` metadata.

That means that the last `assume(!ptr.is_null())` can be deleted, without impacting codegen -- the codegen tests confirm the LLVM-IR ends up exactly the same as before.
2023-07-21 00:11:41 +00:00
bors
e2a7ba2771 Auto merge of #113858 - cjgillot:const-prop-pairs, r=oli-obk
Always const-prop scalars and scalar pairs

This removes some complexity from the pass.

The limitation to propagate ScalarPairs only for tuple comes from https://github.com/rust-lang/rust/pull/67015, when ScalarPair constant were modeled using `Rvalue::Aggregate`. Nowadays, we use `ConstValue::ByRef`, which does not care about the underlying type.

The justification for not propagating in all cases was perf. This seems not to be a clear cut any more: https://github.com/rust-lang/rust/pull/113858#issuecomment-1642396746
2023-07-20 22:22:31 +00:00
Camille GILLOT
ccfa9af29d Propagate ScalarPair for any type. 2023-07-20 21:30:51 +00:00
Camille GILLOT
895e2159f8 Also propagate ScalarPair operands. 2023-07-20 21:30:51 +00:00
Camille GILLOT
12a2edd149 Always propagate into operands. 2023-07-20 21:30:51 +00:00
bors
399b068235 Auto merge of #113856 - WaffleLapkin:vtablin', r=oli-obk
Refactor vtable encoding and optimize it for the case of multiple marker traits

This PR does two things
- Refactor `prepare_vtable_segments` (this was motivated by the other change, `prepare_vtable_segments` was quite hard to understand and while trying to edit it I've refactored it)
  - Mostly remove `loop`s labeled `break`s/`continue`s whenever there is a simpler solution
  - Also use `?`
- Make vtable format a bit more efficient wrt to marker traits
  - See the tests for an example

Fixes https://github.com/rust-lang/rust/issues/113840
cc `@crlf0710`

----

Review wise it's probably best to review each commit individually, as then it's more clear why the refactoring is correct.

I can split the last two commits (which change behavior) into a separate PR if it makes reviewing easier
2023-07-20 20:34:06 +00:00
bors
1554942cdc Auto merge of #113546 - cjgillot:unused-query, r=compiler-errors
Querify unused trait check.

This code transitively loads information for all bodies, and from resolutions. As it does not return a value, it should be beneficial to have it as a query.
2023-07-20 18:45:09 +00:00
Scott McMurray
34732e8560 Get !nonnull metadata consistently in slice iterators, without needing assumes 2023-07-20 11:33:49 -07:00
David Tolnay
7ee059b8ac
Add ui test of LLVM print-from-C++ changes 2023-07-20 11:04:31 -07:00
David Tolnay
f2e3d3fc63
Move OutFileName writing into rustc_session 2023-07-20 11:04:31 -07:00
David Tolnay
11dcd1d3d7
Add test of --print KIND=PATH 2023-07-20 11:04:30 -07:00
bors
092e4f46be Auto merge of #113890 - matthiaskrgr:rollup-k1w2vii, r=matthiaskrgr
Rollup of 7 pull requests

Successful merges:

 - #110765 (rustdoc: fix position of `default` in method rendering)
 - #113529 (Permit pre-evaluated constants in simd_shuffle)
 - #113800 (Avoid another gha group nesting)
 - #113827 (Add Foreign, Never, FnDef, Closure and Generator tys to SMIR)
 - #113835 (new solver: don't consider blanket impls multiple times)
 - #113883 (Remove outdated Firefox-specific CSS for search's crate selector appearance)
 - #113884 (Don't translate compiler-internal bug messages)

r? `@ghost`
`@rustbot` modify labels: rollup
2023-07-20 16:57:05 +00:00
Matthias Krüger
add8298aff
Rollup merge of #113835 - lcnr:assemble-candidates-considering-self-ty, r=compiler-errors
new solver: don't consider blanket impls multiple times

only consider candidates which rely on the self type in `assemble_candidates_after_normalizing_self_ty`.

r? ``@compiler-errors``
2023-07-20 17:19:33 +02:00
Matthias Krüger
8c17e0701e
Rollup merge of #113529 - oli-obk:simd_shuffle_evaluated, r=wesleywiser
Permit pre-evaluated constants in simd_shuffle

fixes https://github.com/rust-lang/rust/issues/113500
2023-07-20 17:19:32 +02:00
Matthias Krüger
80f749dfa0
Rollup merge of #110765 - wackbyte:fix-defaultness-position, r=fmease,GuillaumeGomez
rustdoc: fix position of `default` in method rendering

With the following code:
```rs
#![feature(specialization)]

pub trait A {
    unsafe fn a();
}

impl A for () {
    default unsafe fn a() {}
}
```
rustdoc would render the `impl` of `a` as
```rs
unsafe default fn a()
```
which is inconsistent with the actual position of `default`.
This PR fixes this issue.
2023-07-20 17:19:32 +02:00
bors
06a53ddc0b Auto merge of #113758 - cjgillot:move-dse, r=JakobDegen,oli-obk
Turn copy into moves during DSE.

Dead store elimination computes whether removing a direct store to an unborrowed place is allowed.
Where removing a store is allowed, writing `uninit` is too.

This means that we can use this pass to transform `copy` operands into `move` operands. This is only interesting in call terminators, so we only handle those.

Special care is taken for the `use_both(_1, _1)` case:
- moving the second argument is ok, as `_1` is not live after the call;
- moving the first argument is not, as the second argument reads `_1`.

Fixes #75993
Fixes https://github.com/rust-lang/rust/issues/108068

r? `@RalfJung`
cc `@JakobDegen`
2023-07-20 15:05:39 +00:00
lcnr
2062f2ca82 review 2023-07-20 12:01:34 +02:00
lcnr
2d99f40ec5 assembly: only consider blanket impls once 2023-07-20 11:05:52 +02:00
bors
b14fd2359f Auto merge of #113695 - bjorn3:fix_rlib_cdylib_metadata_handling, r=pnkfelix,petrochenkov
Verify that all crate sources are in sync

This ensures that rustc will not attempt to link against a cdylib as if it is a rust dylib when an rlib for the same crate is available. Previously rustc didn't actually check if any further formats of a crate which has been loaded are of the same version and if they are actually valid. This caused a cdylib to be interpreted as rust dylib as soon as the corresponding rlib was loaded. As cdylibs don't export any rust symbols, linking would fail if rustc decides to link against the cdylib rather than the rlib.

Two crates depended on the previous behavior by separately compiling a test crate as both rlib and dylib. These have been changed to capture their original spirit to the best of my ability while still working when rustc verifies that all crates are in sync. It is unlikely that build systems depend on the current behavior and in any case we are taking a lot of measures to ensure that any change to either the source or the compilation options (including crate type) results in rustc rejecting it as incompatible. We merely didn't do this check here for now obsolete perf reasons.

Fixes https://github.com/rust-lang/rust/issues/10786
Fixes https://github.com/rust-lang/rust/issues/82151
Fixes https://github.com/rust-lang/rust/issues/82972
Closes https://github.com/bevy-cheatbook/bevy-cheatbook/issues/114
2023-07-20 09:00:10 +00:00