1
Fork 0
Commit graph

2556 commits

Author SHA1 Message Date
Ben Kimock
4d01ca8ae9 Remove polymorphization 2024-12-06 16:42:09 -05:00
bjorn3
e8ad19987d Merge commit '57845a397e' into sync_cg_clif-2024-12-06 2024-12-06 12:10:30 +00:00
Matthias Krüger
7174bcc8d6 Rollup merge of #133545 - clubby789:symbol-intern-lit, r=jieyouxu
Lint against Symbol::intern on a string literal

Disabled in tests where this doesn't make much sense
2024-12-03 17:27:06 +01:00
Matthias Krüger
c5acac93fd Rollup merge of #133395 - calebzulawski:simd_relaxed_fma, r=workingjubilee
Add simd_relaxed_fma intrinsic

Adds compiler support for https://github.com/rust-lang/portable-simd/issues/387#issuecomment-2337169786

r? `@workingjubilee`

cc `@RalfJung` is this kind of nondeterminism a problem for miri/opsem?
2024-12-03 07:48:33 +01:00
clubby789
a2e9aac905 Replace Symbol::intern calls with preinterned symbols 2024-11-28 15:45:27 +00:00
Guillaume Gomez
1aded6079a Rollup merge of #133463 - taiki-e:aarch64-asm-x18, r=Amanieu
Fix handling of x18 in AArch64 inline assembly on ohos/trusty or with -Zfixed-x18

Currently AArch64 inline assembly allows using x18 on ohos/trusty or with -Zfixed-x18.

7db7489f9b/compiler/rustc_target/src/asm/aarch64.rs (L74-L76)

However, x18 is reserved in these environments and should not be allowed in the input/output operands of inline assemblies as it is in Android, Windows, etc..

7db7489f9b/compiler/rustc_target/src/spec/targets/aarch64_unknown_linux_ohos.rs (L19)
7db7489f9b/compiler/rustc_target/src/spec/targets/aarch64_unknown_trusty.rs (L18)
7db7489f9b/compiler/rustc_codegen_llvm/src/llvm_util.rs (L764-L771)

(As for ohos, +reserve-x18 is [redundant](c417b7a695 (diff-0ddf23e0bf2b28b2d05f842f087d1e6f694e8e06d1765e8d0f10d47fddcdff9c)) since 7a966b9188 that starting using llvm's ohos targets. So removed it from target-spec.)

This fix may potentially break the code for tier 2 target (aarch64-unknown-linux-ohos). (As for others, aarch64-unknown-trusty is tier 3 and -Zfixed-x18 is unstable so breaking them should be fine.)
However, in any case, it seems suspicious that the code that is broken by this was sound.

r? `@Amanieu`

`@rustbot` label O-AArch64 +A-inline-assembly
2024-11-28 12:06:02 +01:00
Guillaume Gomez
4161cefabe Rollup merge of #133422 - taiki-e:riscv-e-clobber-abi, r=Amanieu
Fix clobber_abi in RV32E and RV64E inline assembly

Currently clobber_abi in RV32E and RV64E inline assembly is implemented using InlineAsmClobberAbi::RiscV, but broken since x16-x31 cannot be used in RV32E and RV64E.

```
error: cannot use register `x16`: register can't be used with the `e` target feature
  --> <source>:42:14
   |
42 |     asm!("", clobber_abi("C"), options(nostack, nomem, preserves_flags));
   |              ^^^^^^^^^^^^^^^^

error: cannot use register `x17`: register can't be used with the `e` target feature
  --> <source>:42:14
   |
42 |     asm!("", clobber_abi("C"), options(nostack, nomem, preserves_flags));
   |              ^^^^^^^^^^^^^^^^

error: cannot use register `x28`: register can't be used with the `e` target feature
  --> <source>:42:14
   |
42 |     asm!("", clobber_abi("C"), options(nostack, nomem, preserves_flags));
   |              ^^^^^^^^^^^^^^^^

error: cannot use register `x29`: register can't be used with the `e` target feature
  --> <source>:42:14
   |
42 |     asm!("", clobber_abi("C"), options(nostack, nomem, preserves_flags));
   |              ^^^^^^^^^^^^^^^^

error: cannot use register `x30`: register can't be used with the `e` target feature
  --> <source>:42:14
   |
42 |     asm!("", clobber_abi("C"), options(nostack, nomem, preserves_flags));
   |              ^^^^^^^^^^^^^^^^

error: cannot use register `x31`: register can't be used with the `e` target feature
  --> <source>:42:14
   |
42 |     asm!("", clobber_abi("C"), options(nostack, nomem, preserves_flags));
   |              ^^^^^^^^^^^^^^^^
```

r? `@Amanieu`

`@rustbot` label O-riscv +A-inline-assembly
2024-11-28 12:06:01 +01:00
Taiki Endo
e5bc7e38c3 Fix handling of x18 in AArch64 inline assembly on ohos/trusty or with -Zfixed-x18 2024-11-26 03:10:22 +09:00
Matthias Krüger
e73d32190b Rollup merge of #131664 - taiki-e:s390x-asm-vreg-inout, r=Amanieu
Support input/output in vector registers of s390x inline assembly (under asm_experimental_reg feature)

This extends currently clobber-only vector registers (`vreg`) support to allow passing `#[repr(simd)]` types, floats (f32/f64/f128), and integers (i32/i64/i128) as input/output.

This is unstable and gated under new `#![feature(asm_experimental_reg)]` (tracking issue: https://github.com/rust-lang/rust/issues/133416). If the feature is not enabled, only clober is supported as before.

| Architecture | Register class | Target feature | Allowed types |
| ------------ | -------------- | -------------- | -------------- |
| s390x | `vreg` | `vector` | `i32`, `f32`, `i64`, `f64`, `i128`, `f128`, `i8x16`, `i16x8`, `i32x4`, `i64x2`, `f32x4`, `f64x2` |

This matches the list of types that are supported by the vector registers in LLVM:
https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.td#L301-L313

In addition to `core::simd` types and floats listed above, custom `#[repr(simd)]` types of the same size and type are also allowed. All allowed types other than i32/f32/i64/f64/i128, and relevant target features are currently unstable.

Currently there is no SIMD type for s390x in `core::arch`, but this is tracked in https://github.com/rust-lang/rust/issues/130869.

cc https://github.com/rust-lang/rust/issues/130869 about vector facility support in s390x
cc https://github.com/rust-lang/rust/issues/125398 & https://github.com/rust-lang/rust/issues/116909 about f128 support in asm

`@rustbot` label +O-SystemZ +A-inline-assembly
2024-11-25 07:01:37 +01:00
Taiki Endo
b9e2bdd050 Fix clobber_abi in RV32E and RV64E inline assembly 2024-11-25 00:36:22 +09:00
Taiki Endo
1876e520e8 Make s390x non-clobber-only vector register support unstable 2024-11-24 21:42:22 +09:00
Caleb Zulawski
8f9d76550b Add simd_relaxed_fma intrinsic 2024-11-23 14:39:42 -05:00
lcnr
510943ab55 remove remaining references to Reveal 2024-11-23 13:52:56 +01:00
Ding Xiang Fei
329cd79cb4 reduce false positives of tail-expr-drop-order from consumed values
take 2

open up coroutines

tweak the wordings

the lint works up until 2021

We were missing one case, for ADTs, which was
causing `Result` to yield incorrect results.

only include field spans with significant types

deduplicate and eliminate field spans

switch to emit spans to impl Drops

Co-authored-by: Niko Matsakis <nikomat@amazon.com>

collect drops instead of taking liveness diff

apply some suggestions and add explantory notes

small fix on the cache

let the query recurse through coroutine

new suggestion format with extracted variable name

fine-tune the drop span and messages

bugfix on runtime borrows

tweak message wording

filter out ecosystem types earlier

apply suggestions

clippy

check lint level at session level

further restrict applicability of the lint

translate bid into nop for stable mir

detect cycle in type structure
2024-11-20 20:53:11 +08:00
bors
67c8877102 Auto merge of #133212 - lcnr:questionable-uwu, r=compiler-errors
continue `ParamEnv` to `TypingEnv` transition

cc #132279

r? `@compiler-errors`
2024-11-20 06:22:01 +00:00
lcnr
bf45e9f7f3 InterpCx store TypingEnv instead of a ParamEnv 2024-11-19 21:36:23 +01:00
lcnr
a4acd22dbb move fn is_item_raw to TypingEnv 2024-11-19 18:06:20 +01:00
Jieyou Xu
c5c3709d80 Explicitly disable llvm tools for cranelift 2024-11-19 20:29:54 +08:00
bors
43181b4d75 Auto merge of #132460 - lcnr:questionable-uwu, r=compiler-errors
Use `TypingMode` throughout the compiler instead of `ParamEnv`

Hopefully the biggest single PR as part of https://github.com/rust-lang/types-team/issues/128.

## `infcx.typing_env` while defining opaque types

I don't know how'll be able to correctly handle opaque types when using something taking a `TypingEnv` while defining opaque types. To correctly handle the opaques we need to be able to pass in the current `opaque_type_storage` and return constraints, i.e. we need to use a proper canonical query. We should migrate all the queries used during HIR typeck and borrowck where this matters to proper canonical queries. This is

## `layout_of` and `Reveal::All`

We convert the `ParamEnv` to `Reveal::All` right at the start of the `layout_of` query, so I've changed callers of `layout_of` to already use a post analysis `TypingEnv` when encountering it.

ca87b535a0/compiler/rustc_ty_utils/src/layout.rs (L51)

## `Ty::is_[unpin|sized|whatever]`

I haven't migrated `fn is_item_raw` to use `TypingEnv`, will do so in a followup PR, this should significantly reduce the amount of `typing_env.param_env`. At some point there will probably be zero such uses as using the type system while ignoring the `typing_mode` is incorrect.

## `MirPhase` and phase-transitions

When inside of a MIR-body, we can mostly use its `MirPhase` to figure out the right `typing_mode`. This does not work during phase transitions, most notably when transitioning from `Analysis` to `Runtime`:

dae7ac133b/compiler/rustc_mir_transform/src/lib.rs (L606-L625)

All these passes still run with `MirPhase::Analysis`, but we should only use `Reveal::All` once we're run the `RevealAll` pass. This required me to manually construct the right `TypingEnv` in all these passes. Given that it feels somewhat easy to accidentally miss this going forward, I would maybe like to change `Body::phase` to an `Option` and replace it at the start of phase transitions. This then makes it clear that the MIR is currently in a weird state.

r? `@ghost`
2024-11-18 21:07:05 +00:00
lcnr
19a8eb2a7f use TypingEnv when no infcx is available
the behavior of the type system not only depends on the current
assumptions, but also the currentnphase of the compiler. This is
mostly necessary as we need to decide whether and how to reveal
opaque types. We track this via the `TypingMode`.
2024-11-18 10:38:56 +01:00
Ralf Jung
22b0e3c0d4 remove pointless cold_path impl in interpreter 2024-11-18 08:41:28 +01:00
Jiri Bobek
1a27566d20 Likely unlikely fix 2024-11-17 21:49:10 +01:00
bjorn3
995ccb684b Add a default implementation for CodegenBackend::link
As a side effect this should add raw-dylib support to cg_gcc as the
default ArchiveBuilderBuilder that is used implements
create_dll_import_lib. I haven't tested if the raw-dylib support
actually works however.
2024-11-09 20:42:56 +00:00
bjorn3
df983ce470 Merge commit '1fa693ca44' into sync_cg_clif-2024-11-09 2024-11-09 13:48:06 +00:00
Ralf Jung
00354ddaa6 remove support for rustc_safe_intrinsic attribute; use rustc_intrinsic functions instead 2024-11-08 09:16:00 +01:00
Ralf Jung
ba6a38495f remove 'platform-intrinsic' ABI leftovers 2024-11-07 17:42:49 +01:00
bors
12677fd3d0 Auto merge of #132526 - bjorn3:sync_cg_clif-2024-11-02, r=bjorn3
Subtree sync for rustc_codegen_cranelift

The highlight this time is an update to Cranelift 0.113,

r? `@ghost`

`@rustbot` label +A-codegen +A-cranelift +T-compiler
2024-11-03 05:03:52 +00:00
Noratrieb
541c33ec41 Rename target triple to target tuple in many places in the compiler
This changes the naming to the new naming, used by `--print
target-tuple`.
It does not change all locations, but many.
2024-11-02 21:29:59 +01:00
bjorn3
e2a5108657 Merge commit '5b1246bb4b' into sync_cg_clif-2024-11-02 2024-11-02 14:53:30 +00:00
Mads Marquart
322d392d90 Move versioned LLVM target creation to rustc_codegen_ssa
The OS version depends on the deployment target environment variables,
the access of which we want to move to later in the compilation pipeline
that has access to more information, for example `env_depinfo`.
2024-11-01 17:07:18 +01:00
Jubilee Young
e3c154705c cg_clif: rustc_abi::Abi => BackendRepr 2024-10-29 15:01:01 -07:00
Jubilee Young
988f49d04f cg_clif: Rename LayoutS to LayoutData 2024-10-27 22:32:40 -07:00
Matthias Krüger
a29a8f523e Rollup merge of #132168 - fee1-dead-contrib:fxclean, r=compiler-errors
Effects cleanup

- removed extra bits from predicates queries that are no longer needed in the new system
- removed the need for `non_erasable_generics` to take in tcx and DefId, removed unused arguments in callers

r? compiler-errors
2024-10-26 06:29:48 +02:00
Deadbeef
83f1121ebd Effects cleanup
- removed extra bits from predicates queries that are no longer needed in the new system
- removed the need for `non_erasable_generics` to take in tcx and DefId, removed unused arguments in callers
2024-10-26 10:19:07 +08:00
Ralf Jung
6ca276df2e Re-do recursive const stability checks
Fundamentally, we have *three* disjoint categories of functions:
1. const-stable functions
2. private/unstable functions that are meant to be callable from const-stable functions
3. functions that can make use of unstable const features

This PR implements the following system:
- `#[rustc_const_stable]` puts functions in the first category. It may only be applied to `#[stable]` functions.
- `#[rustc_const_unstable]` by default puts functions in the third category. The new attribute `#[rustc_const_stable_indirect]` can be added to such a function to move it into the second category.
- `const fn` without a const stability marker are in the second category if they are still unstable. They automatically inherit the feature gate for regular calls, it can now also be used for const-calls.

Also, several holes in recursive const stability checking are being closed.
There's still one potential hole that is hard to avoid, which is when MIR
building automatically inserts calls to a particular function in stable
functions -- which happens in the panic machinery. Those need to *not* be
`rustc_const_unstable` (or manually get a `rustc_const_stable_indirect`) to be
sure they follow recursive const stability. But that's a fairly rare and special
case so IMO it's fine.

The net effect of this is that a `#[unstable]` or unmarked function can be
constified simply by marking it as `const fn`, and it will then be
const-callable from stable `const fn` and subject to recursive const stability
requirements. If it is publicly reachable (which implies it cannot be unmarked),
it will be const-unstable under the same feature gate. Only if the function ever
becomes `#[stable]` does it need a `#[rustc_const_unstable]` or
`#[rustc_const_stable]` marker to decide if this should also imply
const-stability.

Adding `#[rustc_const_unstable]` is only needed for (a) functions that need to
use unstable const lang features (including intrinsics), or (b) `#[stable]`
functions that are not yet intended to be const-stable. Adding
`#[rustc_const_stable]` is only needed for functions that are actually meant to
be directly callable from stable const code. `#[rustc_const_stable_indirect]` is
used to mark intrinsics as const-callable and for `#[rustc_const_unstable]`
functions that are actually called from other, exposed-on-stable `const fn`. No
other attributes are required.
2024-10-25 20:31:40 +02:00
Adrian Taylor
c5a5e86baa Rename Receiver -> LegacyReceiver
As part of the "arbitrary self types v2" project, we are going to
replace the current `Receiver` trait with a new mechanism based on a
new, different `Receiver` trait.

This PR renames the old trait to get it out the way. Naming is hard.
Options considered included:
* HardCodedReceiver (because it should only be used for things in the
  standard library, and hence is sort-of hard coded)
* LegacyReceiver
* TargetLessReceiver
* OldReceiver

These are all bad names, but fortunately this will be temporary.
Assuming the new mechanism proceeds to stabilization as intended, the
legacy trait will be removed altogether.

Although we expect this trait to be used only in the standard library,
we suspect it may be in use elsehwere, so we're landing this change
separately to identify any surprising breakages.

It's known that this trait is used within the Rust for Linux project; a
patch is in progress to remove their dependency.

This is a part of the arbitrary self types v2 project,
https://github.com/rust-lang/rfcs/pull/3519
https://github.com/rust-lang/rust/issues/44874

r? @wesleywiser
2024-10-22 12:55:16 +00:00
Michael Goulet
65201c20a6 Fix tests 2024-10-19 18:07:35 +00:00
Michael Goulet
2f1b15f145 Allow dropping dyn principal 2024-10-17 20:43:31 +02:00
Jed Brown
270fb2130c intrinsics.fmuladdf{16,32,64,128}: expose llvm.fmuladd.* semantics
Add intrinsics `fmuladd{f16,f32,f64,f128}`. This computes `(a * b) +
c`, to be fused if the code generator determines that (i) the target
instruction set has support for a fused operation, and (ii) that the
fused operation is more efficient than the equivalent, separate pair
of `mul` and `add` instructions.

https://llvm.org/docs/LangRef.html#llvm-fmuladd-intrinsic

MIRI support is included for f32 and f64.

The codegen_cranelift uses the `fma` function from libc, which is a
correct implementation, but without the desired performance semantic. I
think this requires an update to cranelift to expose a suitable
instruction in its IR.

I have not tested with codegen_gcc, but it should behave the same
way (using `fma` from libc).
2024-10-11 15:32:56 -06:00
Jubilee Young
48504415cf cg_clif: Factor out rustc_target::abi 2024-10-08 18:24:56 -07:00
Folkert de Vries
2811ce715d various fixes for naked_asm! implementation
- fix for divergence
- fix error message
- fix another cranelift test
- fix some cranelift things
- don't set the NORETURN option for naked asm
- fix use of naked_asm! in doc comment
- fix use of naked_asm! in run-make test
- use `span_bug` in unreachable branch
2024-10-06 19:00:09 +02:00
Urgau
0bd0b99729 Use wide pointers consistenly across the compiler 2024-10-04 14:06:48 +02:00
Michael Goulet
d10a16ae40 Relax a debug assertion in codegen 2024-09-30 12:18:02 -04:00
Ralf Jung
9b31c68c0e fix cranelift CI 2024-09-29 07:32:08 +02:00
Michael Goulet
6fdc133daa Add a debug assertion in codegen that unsize casts of the same principal trait def id are truly NOPs 2024-09-25 11:13:59 -04:00
Lukas Markeffsky
25b66d8091 be even more precise about "cast" vs "coercion" 2024-09-24 23:12:02 +02:00
Lukas Markeffsky
1efad22339 unify dyn* coercions with other pointer coercions 2024-09-24 22:17:55 +02:00
Michael Goulet
631ab21ff0 Check vtable projections for validity in miri 2024-09-23 19:38:26 -04:00
bjorn3
9d8572d33b Rustfmt 2024-09-23 11:28:15 +00:00
bjorn3
f3ae4237ab Revert change to apply_patches to fix panic 2024-09-23 11:20:56 +00:00