Commit Graph

1652 Commits

Author SHA1 Message Date
bors
a6cdd81eff Auto merge of #108714 - estebank:ice_dump, r=oli-obk
On nightly, dump ICE backtraces to disk

Implement rust-lang/compiler-team#578.

When an ICE is encountered on nightly releases, the new rustc panic handler will also write the contents of the backtrace to disk. If any `delay_span_bug`s are encountered, their backtrace is also added to the file. The platform and rustc version will also be collected.

<img width="1032" alt="Screenshot 2023-03-03 at 2 13 25 PM" src="https://user-images.githubusercontent.com/1606434/222842420-8e039740-4042-4563-b31d-599677171acf.png">

The current behavior will *always* write to disk on nightly builds, regardless of whether the backtrace is printed to the terminal, unless the environment variable `RUSTC_ICE_DISK_DUMP` is set to `0`. This is a compromise and can be changed.
2023-07-20 01:29:17 +00:00
Dylan DPC
c1d6d322f4
Rollup merge of #113716 - DianQK:add-no_builtins-to-function, r=pnkfelix
Add the `no-builtins` attribute to functions when `no_builtins` is applied at the crate level.

**When `no_builtins` is applied at the crate level, we should add the `no-builtins` attribute to each function to ensure it takes effect in LTO.**

This is also the reason why no_builtins does not take effect in LTO as mentioned in #35540.

Now, `#![no_builtins]` should be similar to `-fno-builtin` in clang/gcc, see https://clang.godbolt.org/z/z4j6Wsod5.

Next, we should make `#![no_builtins]` participate in LTO again. That makes sense, as LTO also takes into consideration function-level instruction optimizations, such as the MachineOutliner. More importantly, when a user writes a large `#![no_builtins]` crate, they would like this crate to participate in LTO as well.

We should also add a function-level no_builtins attribute to allow users to have more control over it. This is similar to Clang's `__attribute__((no_builtin))` feature, see https://clang.godbolt.org/z/Wod6KK6eq. Before implementing this feature, maybe we should discuss whether to support more fine-grained control, such as `__attribute__((no_builtin("memcpy")))`.

Related discussions:
- #109821
- #35540

Next (a separate pull request?):
- [ ] Revert #35637
- [ ] Add a function-level `no_builtin` attribute?
2023-07-19 22:37:06 +05:30
Esteban Küber
8eb5843a59 On nightly, dump ICE backtraces to disk
Implement rust-lang/compiler-team#578.

When an ICE is encountered on nightly releases, the new rustc panic
handler will also write the contents of the backtrace to disk. If any
`delay_span_bug`s are encountered, their backtrace is also added to the
file. The platform and rustc version will also be collected.
2023-07-19 14:10:07 +00:00
DianQK
cc08749df2
Add the no-builtins attribute to functions when no_builtins is applied at the crate level.
When `no_builtins` is applied at the crate level, we should add the
`no-builtins` attribute to each function to ensure it takes effect in LTO.
2023-07-18 22:15:47 +08:00
chenx97
d3727148a0 support for mips32r6 as a target_arch value 2023-07-18 18:58:18 +08:00
chenx97
a132b3ec03 merge patterns 2023-07-18 18:58:18 +08:00
chenx97
c6e03cd951 support for mips64r6 as a target_arch value 2023-07-18 18:58:18 +08:00
Nicholas Nethercote
b52f9eb6ca Introduce MonoItemData.
It replaces `(Linkage, Visibility)`, making the code nicer. Plus the
next commit will add another field.
2023-07-17 08:44:48 +10:00
bors
55be59d2ce Auto merge of #113626 - Urgau:dedup-native-static-libs, r=petrochenkov
De-duplicate consecutive libs when printing native-static-libs

This PR adds a de-duplicate step just before printing the `native-static-libs`.

This step de-duplicates all the consecutive libs based only on the relevant comparison elements (this exclude spans, ast elements, ...).

Fixes https://github.com/rust-lang/rust/issues/113209
2023-07-16 10:59:45 +00:00
bors
7a17f577b3 Auto merge of #112157 - erikdesjardins:align, r=nikic
Resurrect: rustc_target: Add alignment to indirectly-passed by-value types, correcting the alignment of byval on x86 in the process.

Same as #111551, which I [accidentally closed](https://github.com/rust-lang/rust/pull/111551#issuecomment-1571222612) :/

---

This resurrects PR #103830, which has sat idle for a while.

Beyond #103830, this also:
- fixes byval alignment for types containing vectors on Darwin (see `tests/codegen/align-byval-vector.rs`)
- fixes byval alignment for overaligned types on x86 Windows (see `tests/codegen/align-byval.rs`)
- fixes ABI for types with 128bit requested alignment on ARM64 Linux (see `tests/codegen/aarch64-struct-align-128.rs`)

r? `@nikic`

---

`@pcwalton's` original PR description is reproduced below:

Commit 88e4d2c from five years ago removed
support for alignment on indirectly-passed arguments because of problems with
the `i686-pc-windows-msvc` target. Unfortunately, the `memcpy` optimizations I
recently added to LLVM 16 depend on this to forward `memcpy`s. This commit
attempts to fix the problems with `byval` parameters on that target and now
correctly adds the `align` attribute.

The problem is summarized in [this comment] by `@eddyb.` Briefly, 32-bit x86 has
special alignment rules for `byval` parameters: for the most part, their
alignment is forced to 4. This is not well-documented anywhere but in the Clang
source. I looked at the logic in Clang `TargetInfo.cpp` and tried to replicate
it here. The relevant methods in that file are
`X86_32ABIInfo::getIndirectResult()` and
`X86_32ABIInfo::getTypeStackAlignInBytes()`. The `align` parameter attribute
for `byval` parameters in LLVM must match the platform ABI, or miscompilations
will occur. Note that this doesn't use the approach suggested by eddyb, because
I felt it was overkill to store the alignment in `on_stack` when special
handling is really only needed for 32-bit x86.

As a side effect, this should fix #80127, because it will make the `align`
parameter attribute for `byval` parameters match the platform ABI on LLVM
x86-64.

[this comment]: #80822 (comment)
2023-07-15 15:39:53 +00:00
Mahdi Dibaiee
e55583c4b8 refactor(rustc_middle): Substs -> GenericArg 2023-07-14 13:27:35 +01:00
Matthias Krüger
fc1cb0459d
Rollup merge of #113631 - lqd:fix-113597, r=petrochenkov
make MCP510 behavior opt-in to avoid conflicts between the CLI and target flavors

Fixes #113597, which contains more details on how this happens through the code, and showcases an unexpected `Gnu(Cc::Yes, Lld::Yes)` flavor.

#112910 added support to use `lld` when the flavor requests it, but didn't explicitly do so only when using `-Clink-self-contained=+linker` or one of the unstable `-Clinker-flavor`s.

The problem: some targets have a `lld` linker and flavor, e.g. `thumbv6m-none-eabi` from that issue. Users can override the linker but there are no linker flavors precise enough to describe the linker opting out of lld: when using `-Clinker=arm-none-eabi-gcc`, we infer this is a `Cc::Yes` linker flavor, but the `lld` component is unknown and therefore defaulted to the target's linker flavor, `Lld::Yes`.

<details>
<summary>Walkthrough of how this happens</summary>

The linker flavor used is a mix between what can be inferred from the CLI (`-C linker`) and the target's default linker flavor:

- there is no linker flavor on the CLI (and that also offers another workaround on nightly: `-C linker-flavor=gnu-cc -Zunstable-options`), so it will have to be inferred [from here](5dac6b320b/compiler/rustc_codegen_ssa/src/back/link.rs (L1334-L1336)) to [here](5dac6b320b/compiler/rustc_codegen_ssa/src/back/link.rs (L1321-L1327)).
- in [`infer_linker_hints`](5dac6b320b/compiler/rustc_target/src/spec/mod.rs (L320-L352)) `-C linker=arm-none-eabi-gcc` infers a `Some(Cc::Yes)` cc hint, and no hint about lld.
- the target's `linker_flavor` is combined in `with_cli_hints` with these hints. We have our `Cc::Yes`, but there is no hint about lld, [so the target's flavor `lld` component is used](5dac6b320b/compiler/rustc_target/src/spec/mod.rs (L356-L358)). It's [`Gnu(Cc::No, Lld::Yes)`](993deaa0bf/compiler/rustc_target/src/spec/thumb_base.rs (L35)).
- so we now have our `Gnu(Cc::Yes, Lld::Yes)` flavor

</details>

This results in a `Gnu(Cc::Yes, Lld::Yes)` flavor on a non-lld linker, causing an additional unexpected `-fuse-ld=lld` argument to be passed.

I don't know if this target defaulting to `rust-lld` is expected, but until MCP510's new linker flavor are stable, when people will be able to describe their linker/flavor accurately, this PR keeps the stable behavior of not doing anything when the linker/flavor on the CLI unexpectedly conflict with the target's.

I've tested this on a `no_std` `-C linker=arm-none-eabi-gcc -C link-arg=-nostartfiles --target thumbv6m-none-eabi` example, trying to simulate one of `cortex-m`'s test mentioned in issue #113597 (I don't know how to build a local complete  `thumbv6m-none-eabi` toolchain to run the exact test), and checked that `-fuse-lld` was indeed gone and the error disappeared.

r? `````@petrochenkov`````
2023-07-13 22:33:25 +02:00
Mark Rousskov
cc907f80b9 Re-format let-else per rustfmt update 2023-07-12 21:49:27 -04:00
Rémy Rakic
2b61a5e17a make MCP510 behavior explicitly opt-in
because sometimes users can't opt out
2023-07-12 20:17:10 +00:00
Urgau
ad16606471 De-duplicate consecutive libs when printing native-static-libs 2023-07-12 20:04:30 +02:00
Charisee
650243977b Use constants from object crate
Replace hard-coded values with  GNU_PROPERTY_{X86|AARCH64}_FEATURE_1_AND from the object crate.
2023-07-11 23:48:18 +00:00
Matthias Krüger
685ba08693
Rollup merge of #113497 - xSetech:mips_32_abi, r=davidtwco
Support explicit 32-bit MIPS ABI for the synthetic object

PR #95604 introduced a "synthetic object file to ensure all exported and used symbols participate in the linking". One constraint on this file is that for MIPS-based targets, its architecture-specific ELF flags must be the same as all other object files passed to the linker. That's enforced by LLD, here:
https://github.com/llvm/llvm-project/blob/llvmorg-16.0.6/lld/ELF/Arch/MipsArchTree.cpp#L77

The current approach to determining e_flags for 32-bit was implemented in PR #96930, which links to this issue that summarizes the problem well: https://github.com/ayrtonm/psx-sdk-rs/issues/9

> ... the temporary object file is created with an e_flags which is
> invalid for 32-bit MIPS targets. The main issue is that it omits the ABI
> bits (EF_MIPS_ABI_O32) which implies it uses the N64 ABI.

To enable the N32 MIPS ABI (which succeeded O32), this patch enables setting the synthetic object's ABI based on the target "llvm-abiname" field, if it's given; otherwise, the O32 ABI is assumed for 32-bit MIPS targets.

More information about the N32 ABI can be found here: https://web.archive.org/web/20160121005457/http://techpubs.sgi.com/library/manuals/2000/007-2816-005/pdf/007-2816-005.pdf
2023-07-11 17:46:19 +02:00
Erik Desjardins
0e76446a9f ensure byval allocas are sufficiently aligned 2023-07-10 19:19:38 -04:00
Seth Junot
329e099400 Support explicit 32-bit MIPS ABI for the synthetic object
PR #95604 introduced a "synthetic object file to ensure all exported and
used symbols participate in the linking". One constraint on this file is
that for MIPS-based targets, its architecture-specific ELF flags must be
the same as all other object files passed to the linker. That's enforced
by LLD, here:
https://github.com/llvm/llvm-project/blob/llvmorg-16.0.6/lld/ELF/Arch/MipsArchTree.cpp#L77

The current approach to determining e_flags for 32-bit was implemented
in PR #96930, which links to this issue that summarizes the problem well:
https://github.com/ayrtonm/psx-sdk-rs/issues/9

> ... the temporary object file is created with an e_flags which is
> invalid for 32-bit MIPS targets. The main issue is that it omits the ABI
> bits (EF_MIPS_ABI_O32) which implies it uses the N64 ABI.

To enable the N32 MIPS ABI (which succeeded O32), this patch enables
setting the synthetic object's ABI based on the target "llvm-abiname"
field, if it's given; otherwise, the O32 ABI is assumed for 32-bit MIPS
targets.

More information about the N32 ABI can be found here:
https://web.archive.org/web/20160121005457/http://techpubs.sgi.com/library/manuals/2000/007-2816-005/pdf/007-2816-005.pdf
2023-07-09 11:17:37 -07:00
Matthias Krüger
4406a92cd1
Rollup merge of #111618 - cjgillot:name-return-place, r=tmiasko
Always name the return place.

MIR opts more and more consider `_0` as just another local, so there is no point in keeping the special case in debug-info logic.
2023-07-09 16:33:35 +02:00
Camille GILLOT
d7983a2f23 Always name the return place. 2023-07-08 15:38:40 +02:00
Nilstrieb
2beabbbf6f Rename adjustment::PointerCast and variants using it to PointerCoercion
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.
2023-07-07 18:17:16 +02:00
Boxy
12138b8e5e Move TyCtxt::mk_x to Ty::new_x where applicable 2023-07-05 20:27:07 +01:00
Zalathar
cb570d6bc1 Move coverageinfo::ffi and coverageinfo::map out of SSA 2023-07-05 20:40:40 +10:00
Zalathar
9c430d38cf Remove trait CoverageInfoMethods, since non-LLVM backends don't need it
These methods are only ever called from within `rustc_codegen_llvm`, so they
can just be declared there as well.
2023-07-05 20:40:40 +10:00
Zalathar
4169d0f756 Narrow trait CoverageInfoBuilderMethods down to just one method
This effectively inlines most of `FunctionCx::codegen_coverage` into the LLVM
implementation of `CoverageInfoBuilderMethods`.
2023-07-05 20:40:39 +10:00
bors
131a03664e Auto merge of #113040 - Kobzol:llvm-remark-streamer, r=tmiasko
Add `-Zremark-dir` unstable flag to write LLVM optimization remarks to YAML

This PR adds an option for `rustc` to emit LLVM optimization remarks to a set of YAML files, which can then be digested by existing tools, like https://github.com/OfekShilon/optview2. When `-Cremark-dir` is passed, and remarks are enabled (`-Cremark=all`), the remarks will be now written to the specified directory, **instead** of being printed to standard error output.  The files are named based on the CGU from which they are being generated.

Currently, the remarks are written using the LLVM streaming machinery, directly in the diagnostics handler. It seemed easier than going back to Rust and then form there back to C++ to use the streamer from the diagnostics handler. But there are many ways to implement this, of course, so I'm open to suggestions :)

I included some comments with questions into the code. Also, I'm not sure how to test this.

r? `@tmiasko`
2023-07-02 12:48:44 +00:00
Jakub Beránek
62728c7aaf
Add rustc option to output LLVM optimization remarks to YAML files 2023-07-02 13:41:36 +02:00
bors
72b2101434 Auto merge of #112718 - oli-obk:SIMD-destructure_mir_const, r=cjgillot
Make simd_shuffle_indices use valtrees

This removes the second-to-last user of the `destructure_mir_constant` query. So in a follow-up we can remove the query and just move the query provider function directly into pretty printing (which is the last user).

cc `@rust-lang/clippy` there's a small functional change, but I think it is correct?
2023-07-02 07:43:36 +00:00
bors
8e2d5e3a58 Auto merge of #112910 - lqd:mcp510, r=petrochenkov
Implement most of MCP510

This implements most of what remains to be done for MCP510:
- turns `-C link-self-contained` into a `+`/`-` list of components, like `-C link-self-contained=+linker,+crto,+libc,+unwind,+sanitizers,+mingw`. The scaffolding is present for all these expected components to be implemented and stabilized in the future on their own time. This PR only handles the `-Zgcc-ld=lld` subset of these link-self-contained components as  `-Clink-self-contained=+linker`
- handles  `-C link-self-contained=y|n`  as-is today, for compatibility with `rustc_codegen_ssa:🔙🔗:self_contained`'s [explicit opt-in and opt-out](9eee230cd0/compiler/rustc_codegen_ssa/src/back/link.rs (L1671-L1676)).
- therefore supports our plan to opt out of `rust-lld` (when it's enabled by default) even for current `-Clink-self-contained` users, with e.g. `-Clink-self-contained -Clink-self-contained=-linker`
- turns `add_gcc_ld_path` into its expected final form, by using the `-C link-self-contained=+linker`  CLI flag, and whether the `LinkerFlavor`  has the expected `Cc::Yes` and `Lld::Yes` shape (this is not yet the case in practice for any CLI linker flavor)
- makes the [new clean linker flavors](https://github.com/rust-lang/rust/pull/96827#issuecomment-1208441595) selectable in the CLI in addition to the legacy ones, in order to opt-in to using `cc` and `lld` to emulate `-Zgcc-ld=lld`
- ensure the new `-C link-self-contained` components, and `-C linker-flavor`s are unstable, and require `-Z unstable-options` to be used

The up-to-date set of flags for the future stable CLI version of `-Zgcc-ld=lld` is currently: `-Clink-self-contained=+linker -Clinker-flavor=gnu-lld-cc -Zunstable-options`.

It's possible we'll also need to do something for distros that don't ship `rust-lld`, but maybe there are already no tool search paths to be added to `cc` in this situation anyways.

r? `@petrochenkov`
2023-07-02 02:25:01 +00:00
bors
7905eff5f7 Auto merge of #112550 - loongarch-rs:fix-eflags, r=cjgillot
loongarch: Fix ELF header flags

This patch changes the ELF header flags so that the ABI matches the floating-point features. It also updates the link to the new official documentation.
2023-07-01 09:31:35 +00:00
Rémy Rakic
1da271b6d0 refactor add_gcc_ld_path into its final form 2023-06-30 21:07:05 +00:00
Rémy Rakic
0fb80715bb use LinkSelfContained for -C link-self-contained 2023-06-30 21:01:38 +00:00
bors
af9df2fd91 Auto merge of #106619 - agausmann:avr-object-file, r=nagisa
Fix unset e_flags in ELF files generated for AVR targets

Closes #106576

~~Sort-of blocked by gimli-rs/object#500~~ (merged)

I'm not sure whether the list of AVR CPU names is okay here. Maybe it could be moved out-of-line to improve the readability of the function.
2023-06-30 08:55:56 +00:00
Matthias Krüger
4696a92183
Rollup merge of #111322 - mirkootter:master, r=davidtwco
Support for native WASM exceptions

### Motivation
Currently, rustc does not support native WASM exceptions. It does support JavaScript based exceptions for the wasm32-emscripten-target, but this requires back&forth with javascript for many calls, which is very slow.

Native wasm support for exceptions is quite common: Clang+LLVM implemented them years ago, and all major browsers support them by now. They enable zero-cost exceptions, at least with regard to runtime-performance-cost. They may increase startup-time and code size, though.

### Important: This PR does not change default behaviour
Exceptions usually add a lot of code in form of unwinding blocks, increasing the binary size. Most users probably do not want that, especially which regard to web development.

Therefore, wasm exceptions play a similar role as WASM-threads: rustc should support them, like clang does, but users who want to use it have to use some command-line magic like rustflags to opt in.

### What does this PR do?
As stated above, the default behaviour is not changed. It is already possible to opt-in into wasm exceptions using the command line. Unfortunately, the LLVM IR is invalid and the LLVM backend crashes.
```
rustc <sourcefile>
  --target wasm32-unknown-unknown
  -C panic=unwind
  -C llvm-args=-wasm-enable-eh
  -C target-feature=+exception-handling
```
As it turns out, LLVM is quite picky when it comes to IR for exception handling. If the IR does not look exactly like it should, some LLVM-assertions fail and the code generation crashes.

This PR adds the necessary modifications to the code generator to make it work. It also adds `exception-handling` as a wasm target feature.

### What this PR does not / what is missing
This PR is not a full fledges solution. It is the first step. A few parts are still missing; however, it is already useable (see next section).

Currently missing:
* The std library has to be adapted. Currently, only [no_std] crates work
* Usually, nested exceptions abort the program (i.e. a panic during the cleanup of another panic). This is currently not done yet.
  - Currently, code inside cleanup handlers does not unwind
  - To fix this requires a little more work: The code generator currently maintains a single terminate block per function for this. Unfortunately, WASM requires funclet based exception handling. Therefore, we need to create a terminate block per funclet. This is probably not a big problem, but I want to keep this PR simple.

### How to use the compiler given this PR?
This PR does not add any command line flags or features. It uses those which are already there. To compile with exceptions enabled, you need
* to set the panic strategy to unwind, i.e. `-C panic=unwind`
* to enable the exception-handling target feature, i.e. `-C target-feature=+exception-handling`
* to tell LLVM about the exception handling, i.e. `-C llvm-args=-wasm-enable-eh`

Since the standard library has not been adapted, you can only use it in [no_std] crates as of now. The intrinsic `core::intrinsics::r#try` works. To throw exceptions, you need the ```@llvm.wasm.throw``` intrinsic.

I created a sample application which works for me: https://github.com/mirkootter/rust-wasm-demos
This example can be run at https://webassembly.sh
2023-06-29 16:36:30 +02:00
Takayuki Maeda
bad0688563
Rollup merge of #112946 - nnethercote:improve-cgu-naming-and-ordering, r=wesleywiser
Improve cgu naming and ordering

Some quality of life improvements when debugging and profiling CGU formation.

r? `@wesleywiser`
2023-06-29 03:29:32 +09:00
bors
bb95b7dcd6 Auto merge of #112307 - lcnr:operand-ref, r=compiler-errors
mir opt + codegen: handle subtyping

fixes #107205

the same issue was caused in multiple places:
- mir opts: both copy and destination propagation
- codegen: assigning operands to locals (which also propagates values)

I changed codegen to always update the type in the operands used for locals which should guard against any new occurrences of this bug going forward. I don't know how to make mir optimizations more resilient here. Hopefully the added tests will be enough to detect any trivially wrong optimizations going forward.
2023-06-28 00:41:37 +00:00
Matthias Krüger
1880e83ae3
Rollup merge of #112207 - qwandor:virt_feature, r=davidtwco
Add trustzone and virtualization target features for aarch32.

These are LLVM target features which allow the `smc` and `hvc` instructions respectively to be used in inline assembly.
2023-06-27 22:10:12 +02:00
Oli Scherer
acdfec6061 Move mir const to valtree conversion to its own method. 2023-06-26 09:34:52 +00:00
Oli Scherer
168de14ac9 Make simd_shuffle_indices use valtrees 2023-06-26 09:34:52 +00:00
Nicholas Nethercote
666b1b68a7 Tweak thread names for CGU processing.
For non-incremental builds on Unix, currently all the thread names look
like `opt regex.f10ba03eb5ec7975-cgu.0`. But they are truncated by
`pthread_setname` to `opt regex.f10ba`, hiding the numeric suffix that
distinguishes them. This is really annoying when using a profiler like
Samply.

This commit changes these thread names to a form like `opt cgu.0`, which
is much better.
2023-06-26 09:14:45 +10:00
Nicholas Nethercote
fae4f45214 Remove unused fields from CodegenContext. 2023-06-22 09:07:19 +10:00
Nicholas Nethercote
3bbf9f0128 Introduce CodegenState.
The codegen main loop has two bools, `codegen_done` and
`codegen_aborted`. There are only three valid combinations: `(false,
false)`, `(true, false)`, `(true, true)`.

This commit replaces them with a single tri-state enum, which makes
things clearer.
2023-06-22 09:07:15 +10:00
Nicholas Nethercote
a521ba400d Add comments to Message and WorkItem.
This is particularly useful for `Message`.
2023-06-22 08:07:59 +10:00
Nicholas Nethercote
88cd8f9324 Simplify Message.
`Message` is an enum with multiple variants. Four of those variants map
directly onto the four variants of `WorkItemResult`. This commit reduces
those four `Message` variants to a single variant containing a
`WorkItemResult`. This requires increasing `WorkItemResult`'s visibility
to `pub(crate)` visibility, but `WorkItem` and `Message` can also have
their visibility reduced to `pub(crate)`.

This change avoids some boilerplate enum translation code, and makes
`Message` easier to understand.
2023-06-22 08:07:59 +10:00
Nicholas Nethercote
757c290fba Move Message::CodegenItem to a separate type.
`Message` is an enum with multiple variants, for messages sent to the
coordinator thread. *Except* for `Message::CodegenItem`, which is
entirely disjoint, being for messages sent from the coordinator thread
to the main thread.

This commit move `Message::CodegenItem` into a separate type,
`CguMessage`, which makes the code much clearer.
2023-06-22 08:07:59 +10:00
Nilstrieb
904994e101
Rollup merge of #112830 - nnethercote:more-codegen-cleanups, r=oli-obk
More codegen cleanups

Some additional cleanups I found while looking closely at this code, following up from #112827.

r= `@oli-obk`
2023-06-21 07:37:03 +02:00
Nicholas Nethercote
c696307a87 Inline and remove WorkItem::start_profiling and execute_work_item.
They both match on a `WorkItem`. It's simpler to do it all in one place.
2023-06-21 10:56:19 +10:00
Guillaume Gomez
0688182f9b
Rollup merge of #112794 - bjorn3:fix_lib_global_alloc, r=oli-obk
Fix linker failures when #[global_allocator] is used in a dependency

Fixes https://github.com/rust-lang/rust/issues/112715
2023-06-20 14:23:41 +02:00
Michael Goulet
31d1fbf8d2
Rollup merge of #112232 - fee1-dead-contrib:match-eq-const-msg, r=b-naber
Better error for non const `PartialEq` call generated by `match`

Resolves #90237
2023-06-19 17:53:33 -07:00