Commit Graph

1679 Commits

Author SHA1 Message Date
Nadrieril
573e7f181d
Rollup merge of #120495 - clubby789:remove-amdgpu-kernel, r=oli-obk
Remove the `abi_amdgpu_kernel` feature

The tracking issue (#51575) has been closed for 3 years, with no activity for 5.
2024-01-31 12:10:53 +01:00
clubby789
f6b21e90d1 Remove the abi_amdgpu_kernel feature 2024-01-30 15:46:40 +00:00
yukang
ad526d831e add missing potential_query_instability for keys and values in hashmap 2024-01-30 12:43:10 +08:00
bors
8af70c7a18 Auto merge of #120062 - davidtwco:llvm-data-layout-check, r=wesleywiser
llvm: change data layout bug to an error and make it trigger more

Fixes #33446.

Don't skip the inconsistent data layout check for custom LLVMs or non-built-in targets.

With #118708, all targets will have a simple test that would trigger this error if LLVM's data layouts do change - so data layouts would be corrected during the LLVM upgrade. Therefore, with builtin targets, this error won't happen with our LLVM because each target will have been confirmed to work. With non-builtin targets, this error is probably useful to have because you can change the data layout in your target and if it is wrong then that could lead to bugs.

When using a custom LLVM, the same justification makes sense for non-builtin targets as with our LLVM, the user can update their target to match their LLVM and that's probably a good thing to do. However, with a custom LLVM, the user cannot change the builtin target data layouts if they don't match - though given that the compiler's data layout is used for layout computation and a bunch of other things - you could get some bugs because of the mismatch and probably want to know about that. I'm not sure if this is something that people do and is okay, but I doubt it?

`CFG_LLVM_ROOT` was also always set during local development with `download-ci-llvm` so this bug would never trigger locally.

In #33446, two points are raised:

- In the issue itself, changing this from a `bug!` to a proper error is what is suggested, by using `isCompatibleDataLayout` from LLVM, but that function still just does the same thing that we do and check for equality, so I've avoided the additional code necessary to do that FFI call.
- `@Mark-Simulacrum` suggests a different check is necessary to maintain backwards compatibility with old LLVM versions. I don't know how often this comes up, but we can do that with some simple string manipulation + LLVM version checks as happens already for LLVM 17 just above this diff.
2024-01-27 12:19:41 +00:00
clubby789
fd29f74ff8 Remove unused features 2024-01-25 14:01:33 +00:00
bors
039d887928 Auto merge of #119911 - NCGThompson:is-statically-known, r=oli-obk
Replacement of #114390: Add new intrinsic `is_var_statically_known` and optimize pow for powers of two

This adds a new intrinsic `is_val_statically_known` that lowers to [``@llvm.is.constant.*`](https://llvm.org/docs/LangRef.html#llvm-is-constant-intrinsic).` It also applies the intrinsic in the int_pow methods to recognize and optimize the idiom `2isize.pow(x)`. See #114390 for more discussion.

While I have extended the scope of the power of two optimization from #114390, I haven't added any new uses for the intrinsic. That can be done in later pull requests.

Note: When testing or using the library, be sure to use `--stage 1` or higher. Otherwise, the intrinsic will be a noop and the doctests will be skipped. If you are trying out edits, you may be interested in [`--keep-stage 0`](https://rustc-dev-guide.rust-lang.org/building/suggested.html#faster-builds-with---keep-stage).

Fixes #47234
Resolves #114390
`@Centri3`
2024-01-25 05:16:53 +00:00
Catherine Flores
5a4561749a Add new intrinsic is_constant and optimize pow
Fix overflow check

Make MIRI choose the path randomly and rename the intrinsic

Add back test

Add miri test and make it operate on `ptr`

Define `llvm.is.constant` for primitives

Update MIRI comment and fix test in stage2

Add const eval test

Clarify that both branches must have the same side effects

guaranteed non guarantee

use immediate type instead

Co-Authored-By: Ralf Jung <post@ralfj.de>
2024-01-19 13:46:27 -05:00
Matthew Maurer
dbff90c2a7 LLVM 18 x86 data layout update
With https://reviews.llvm.org/D86310 LLVM now has i128 aligned to
16-bytes on x86 based platforms. This will be in LLVM-18. This patch
updates all our spec targets to be 16-byte aligned, and removes the
alignment when speaking to older LLVM.

This results in Rust overaligning things relative to LLVM on older LLVMs.

This alignment change was discussed in rust-lang/compiler-team#683

See #54341 for additional information about why this is happening and
where this will be useful in the future.

This *does not* stabilize `i128`/`u128` for FFI.
2024-01-19 10:52:01 +01:00
David Wood
46652dd254
llvm: simplify data layout check
Don't skip the inconsistent data layout check for custom LLVMs.

With #118708, all targets will have a simple test that would trigger this
check if LLVM's data layouts do change - so data layouts would be
corrected during the LLVM upgrade. Therefore, with builtin targets, this
check won't trigger with our LLVM because each target will have been
confirmed to work. With non-builtin targets, this check is probably
useful to have because you can change the data layout in your target and
if its wrong then that could lead to bugs.

When using a custom LLVM, the same justification makes sense for
non-builtin targets as with our LLVM, the user can update their target to
match their LLVM and that's probably a good thing to do. However, with
a custom LLVM, the user cannot change the builtin target data layouts if
they don't match - though given that the compiler's data layout is used
for layout computation and a bunch of other things - you could get some
bugs because of the mismatch and probably want to know about that.

`CFG_LLVM_ROOT` was also always set during local development with
`download-ci-llvm` so this bug would never trigger locally.

Signed-off-by: David Wood <david@davidtw.co>
2024-01-18 10:46:03 +00:00
Michael Woerister
ac58f9ae03 Update measureme crate to version 11 2024-01-13 16:32:03 +01:00
DianQK
aa874c5513
Revert "Auto merge of #113923 - DianQK:restore-no-builtins-lto, r=pnkfelix"
This reverts commit 8c2b577217, reversing
changes made to 9cf18e98f8.
2024-01-12 18:23:04 +08:00
DianQK
6d29eac04b
Revert "Auto merge of #118568 - DianQK:no-builtins-symbols, r=pnkfelix"
This reverts commit 503e129328, reversing
changes made to 0e7f91b75e.
2024-01-12 18:22:39 +08:00
Zalathar
124fff0777 coverage: Add enums to accommodate other kinds of coverage mappings 2024-01-11 16:43:12 +11:00
Nicholas Nethercote
0e388f2192 Change how force-warn lint diagnostics are recorded.
`is_force_warn` is only possible for diagnostics with `Level::Warning`,
but it is currently stored in `Diagnostic::code`, which every diagnostic
has.

This commit:
- removes the boolean `DiagnosticId::Lint::is_force_warn` field;
- adds a `ForceWarning` variant to `Level`.

Benefits:
- The common `Level::Warning` case now has no arguments, replacing
  lots of `Warning(None)` occurrences.
- `rustc_session::lint::Level` and `rustc_errors::Level` are more
  similar, both having `ForceWarning` and `Warning`.
2024-01-11 07:56:17 +11:00
Nicholas Nethercote
ed76b0b882 Rename consuming chaining methods on DiagnosticBuilder.
In #119606 I added them and used a `_mv` suffix, but that wasn't great.

A `with_` prefix has three different existing uses.
- Constructors, e.g. `Vec::with_capacity`.
- Wrappers that provide an environment to execute some code, e.g.
  `with_session_globals`.
- Consuming chaining methods, e.g. `Span::with_{lo,hi,ctxt}`.

The third case is exactly what we want, so this commit changes
`DiagnosticBuilder::foo_mv` to `DiagnosticBuilder::with_foo`.

Thanks to @compiler-errors for the suggestion.
2024-01-10 07:40:00 +11:00
Nicholas Nethercote
3c4f1d85af Rename {create,emit}_warning as {create,emit}_warn.
For consistency with `warn`/`struct_warn`, and also `{create,emit}_err`,
all of which use an abbreviated form.
2024-01-10 07:33:06 +11:00
Matthias Krüger
9e4843e42e
Rollup merge of #117744 - quininer:add-z-sync-uw, r=bjorn3
Add -Zuse-sync-unwind

Currently Rust uses async unwind by default, but async unwind will bring non-negligible size overhead. it would be nice to allow users to choose this.

In addition, async unwind currently prevents LLVM from generate compact unwind for MachO, if one wishes to generate compact unwind for MachO, then also needs this flag.
2024-01-09 05:33:20 +01:00
Nicholas Nethercote
589591efde Use chaining in DiagnosticBuilder construction.
To avoid the use of a mutable local variable, and because it reads more
nicely.
2024-01-08 15:43:07 +11:00
bors
11035f9f52 Auto merge of #119621 - compiler-errors:rollup-5mxtvuk, r=compiler-errors
Rollup of 10 pull requests

Successful merges:

 - #119034 (Allow coverage tests to ignore test modes, and to enable color in coverage reports)
 - #119148 (Tweak suggestions for bare trait used as a type)
 - #119538 (Cleanup error handlers: round 5)
 - #119566 (Remove `-Zdump-mir-spanview`)
 - #119567 (Remove `-Zreport-delayed-bugs`.)
 - #119577 (Migrate memory overlap check from validator to lint)
 - #119583 (Make `intrinsics::assume` const stable)
 - #119586 ([rustdoc] Fix invalid handling for static method calls in jump to definition feature)
 - #119588 (Move `i586-unknown-netbsd` from tier 2 to tier 3 platform support table)
 - #119601 (`Emitter` cleanups)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-01-05 16:31:05 +00:00
Michael Goulet
f361b591ef
Rollup merge of #119538 - nnethercote:cleanup-errors-5, r=compiler-errors
Cleanup error handlers: round 5

More rustc_errors cleanups. A sequel to https://github.com/rust-lang/rust/pull/119171.

r? ````@compiler-errors````
2024-01-05 10:57:21 -05:00
bors
432fffa8af Auto merge of #118991 - nikic:scalar-pair, r=nagisa
Separate immediate and in-memory ScalarPair representation

Currently, we assume that ScalarPair is always represented using a two-element struct, both as an immediate value and when stored in memory.

This currently works fairly well, but runs into problems with https://github.com/rust-lang/rust/pull/116672, where a ScalarPair involving an i128 type can no longer be represented as a two-element struct in memory. For example, the tuple `(i32, i128)` needs to be represented in-memory as `{ i32, [3 x i32], i128 }` to satisfy alignment requirements. Using `{ i32, i128 }` instead will result in the second element being stored at the wrong offset (prior to LLVM 18).

Resolve this issue by no longer requiring that the immediate and in-memory type for ScalarPair are the same. The in-memory type will now look the same as for normal struct types (and will include padding filler and similar), while the immediate type stays a simple two-element struct type. This also means that booleans in immediate ScalarPair are now represented as i1 rather than i8, just like we do everywhere else.

The core change here is to llvm_type (which now treats ScalarPair as a normal struct) and immediate_llvm_type (which returns the two-element struct that llvm_type used to produce). The rest is fixing things up to no longer assume these are the same. In particular, this switches places that try to get pointers to the ScalarPair elements to use byte-geps instead of struct-geps.
2024-01-05 14:31:56 +00:00
Matthias Krüger
12c102ec53
Rollup merge of #119431 - taiki-e:asm-s390x-reg-addr, r=Amanieu
Support reg_addr register class in s390x inline assembly

In s390x, `r0` cannot be used as an address register (it is evaluated as zero in an address context).

Therefore, currently, in assemblies involving memory accesses, `r0` must be [marked as clobbered](1a1155653a/src/arch/s390x.rs (L58)) or [explicitly used to a non-address](1a1155653a/src/arch/s390x.rs (L135)) or explicitly use an address register to prevent `r0` from being allocated to a register for the address.

This patch adds a register class for allocating general-purpose registers, except `r0`, to make it easier to use address registers. (powerpc already has a register class (reg_nonzero) for a similar purpose.)

This is identical to the `a` constraint in LLVM and GCC:

https://llvm.org/docs/LangRef.html#supported-constraint-code-list
> a: A 32, 64, or 128-bit integer address register (excludes R0, which in an address context evaluates as zero).

https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html
> a
> Address register (general purpose register except r0)

cc ``@uweigand``

r? ``@Amanieu``
2024-01-04 15:33:59 +01:00
Nicholas Nethercote
8388112970 Remove is_lint field from Level::Error.
Because it's redundant w.r.t. `Diagnostic::is_lint`, which is present
for every diagnostic level.

`struct_lint_level_impl` was the only place that set the `Error` field
to `true`, and it's also the only place that calls
`Diagnostic::is_lint()` to set the `is_lint` field.
2024-01-04 16:09:31 +11:00
León Orell Valerian Liehr
ea39f19fab
Rollup merge of #119514 - Zalathar:query-stability, r=wesleywiser
coverage: Avoid a query stability hazard in `function_coverage_map`

When #118865 started enforcing the `rustc::potential_query_instability` lint in `rustc_codegen_llvm`, it added an exemption for this site, arguing that the entries are only used to create a list of filenames that is later sorted.

However, the list of entries also gets traversed when creating the function coverage records in LLVM IR, which may be sensitive to hash-based ordering.

This patch therefore changes `function_coverage_map` to use `FxIndexMap`, which should avoid hash-based instability by iterating in insertion order.

cc ``@Enselic``
2024-01-03 16:08:32 +01:00
León Orell Valerian Liehr
3053ced813
Rollup merge of #119444 - compiler-errors:closure-or-coroutine, r=oli-obk
Rename `TyCtxt::is_closure` to `TyCtxt::is_closure_or_coroutine`

This function has always been used to test whether the def-id was a closure **or** coroutine: https://github.com/rust-lang/rust/pull/118311/files#diff-69ebec59f7d38331dd1be84ede7957977dcaa39e30ed2869b04aa8c99b2079ccR552 -- the name is just confusing because it disagrees with other fns named `is_closure`, like `Ty::is_closure`.

So let's rename it.
2024-01-03 16:08:26 +01:00
Taiki Endo
ee41651d2f Support reg_addr register class in s390x inline assembly 2024-01-03 18:00:37 +09:00
Nicholas Nethercote
505c1371d0 Rename some Diagnostic setters.
`Diagnostic` has 40 methods that return `&mut Self` and could be
considered setters. Four of them have a `set_` prefix. This doesn't seem
necessary for a type that implements the builder pattern. This commit
removes the `set_` prefixes on those four methods.
2024-01-03 19:40:20 +11:00
Nikita Popov
8e64fc94d8 Address review comments 2024-01-02 15:03:14 +01:00
Zalathar
5e7c1b93ac coverage: Avoid a query stability hazard in function_coverage_map
When #118865 started enforcing the `rustc::potential_query_instability` lint in
`rustc_codegen_llvm`, it added an exemption for this site, arguing that the
entries are only used to create a list of filenames that is later sorted.

However, the list of entries also gets traversed when creating the function
coverage records in LLVM IR, which may be sensitive to hash-based ordering.

This patch therefore changes `function_coverage_map` to use `FxIndexMap`, which
should avoid hash-based instability by iterating in insertion order.
2024-01-02 22:57:04 +11:00
quininer
12784c3166 Add -Zuse-sync-unwind
This flag specifies whether LLVM generates async unwind or sync unwind.
2023-12-31 15:27:43 +08:00
Nilstrieb
ffafcd8819 Update to bitflags 2 in the compiler
This involves lots of breaking changes. There are two big changes that
force changes. The first is that the bitflag types now don't
automatically implement normal derive traits, so we need to derive them
manually.

Additionally, bitflags now have a hidden inner type by default, which
breaks our custom derives. The bitflags docs recommend using the impl
form in these cases, which I did.
2023-12-30 18:17:28 +01:00
Michael Goulet
07adee7072 is_coroutine -> is_coroutine_or_closure 2023-12-30 15:24:15 +00:00
bors
ddca5343f2 Auto merge of #118705 - WaffleLapkin:codegen-atomic-exhange-untuple, r=cjgillot
Change `rustc_codegen_ssa`'s `atomic_cmpxchg` interface to return a pair of values

Doesn't change much, but a little nicer that way.
2023-12-30 07:42:19 +00:00
Michael Goulet
fcb42b42d6 Remove movability from TyKind::Coroutine 2023-12-28 16:35:01 +00:00
Bernd Schmidt
6cf6139411 Change rustc_codegen_ssa's atomic_cmpxchg interface to return a pair of values 2023-12-28 09:40:47 +00:00
bors
2271c26e4a Auto merge of #119146 - nnethercote:rm-DiagCtxt-api-duplication, r=compiler-errors
Remove `DiagCtxt` API duplication

`DiagCtxt` defines the internal API for creating and emitting diagnostics: methods like `struct_err`, `struct_span_warn`, `note`, `create_fatal`, `emit_bug`. There are over 50 methods.

Some of these methods are then duplicated across several other types: `Session`, `ParseSess`, `Parser`, `ExtCtxt`, and `MirBorrowckCtxt`. `Session` duplicates the most, though half the ones it does are unused. Each duplicated method just calls forward to the corresponding method in `DiagCtxt`. So this duplication exists to (in the best case) shorten chains like `ecx.tcx.sess.parse_sess.dcx.emit_err()` to `ecx.emit_err()`.

This API duplication is ugly and has been bugging me for a while. And it's inconsistent: there's no real logic about which methods are duplicated, and the use of `#[rustc_lint_diagnostic]` and `#[track_caller]` attributes vary across the duplicates.

This PR removes the duplicated API methods and makes all diagnostic creation and emission go through `DiagCtxt`. It also adds `dcx` getter methods to several types to shorten chains. This approach scales *much* better than API duplication; indeed, the PR adds `dcx()` to numerous types that didn't have API duplication: `TyCtxt`, `LoweringCtxt`, `ConstCx`, `FnCtxt`, `TypeErrCtxt`, `InferCtxt`, `CrateLoader`, `CheckAttrVisitor`, and `Resolver`. These result in a lot of changes from `foo.tcx.sess.emit_err()` to `foo.dcx().emit_err()`. (You could do this with more types, but it gets into diminishing returns territory for types that don't emit many diagnostics.)

After all these changes, some call sites are more verbose, some are less verbose, and many are the same. The total number of lines is reduced, mostly because of the removed API duplication. And consistency is increased, because calls to `emit_err` and friends are always preceded with `.dcx()` or `.dcx`.

r? `@compiler-errors`
2023-12-26 02:24:39 +00:00
bors
bf8716f1cd Auto merge of #119139 - michaelwoerister:cleanup-stable-source-file-id, r=cjgillot
Unify SourceFile::name_hash and StableSourceFileId

This PR adapts the existing `StableSourceFileId` type so that it can be used instead of the `name_hash` field of `SourceFile`. This simplifies a few things that were kind of duplicated before.

The PR should also fix issues https://github.com/rust-lang/rust/issues/112700 and https://github.com/rust-lang/rust/issues/115835, but I was not able to reproduce these issues in a regression test. As far as I can tell, the root cause of these issues is that the id of the originating crate is not hashed in the `HashStable` impl of `Span` and thus cache entries that should have been considered invalidated were loaded. After this PR, the `stable_id` field of `SourceFile` includes information about the originating crate, so that ICE should not occur anymore.
2023-12-24 21:58:39 +00:00
Nicholas Nethercote
99472c7049 Remove Session methods that duplicate DiagCtxt methods.
Also add some `dcx` methods to types that wrap `TyCtxt`, for easier
access.
2023-12-24 08:05:28 +11:00
Michael Goulet
e0d7a72c46
Rollup merge of #119171 - nnethercote:cleanup-errors-4, r=compiler-errors
Cleanup error handlers: round 4

More `rustc_errors` cleanups. A sequel to #118933.

r? `@compiler-errors`
2023-12-22 21:41:03 -05:00
Nicholas Nethercote
824667f753 Improve some names.
Lots of vectors of messages called `message` or `msg`. This commit
pluralizes them.

Note that `emit_message_default` and `emit_messages_default` both
already existed, and both process a vector, so I renamed the former
`emit_messages_default_inner` because it's called by the latter.
2023-12-23 13:23:28 +11:00
Pietro Albini
f9f5840eb4
update cfg(bootstrap)s 2023-12-22 11:14:11 +01:00
bors
cee794ee98 Auto merge of #119097 - nnethercote:fix-EmissionGuarantee, r=compiler-errors
Fix `EmissionGuarantee`

There are some problems with the `DiagCtxt` API related to `EmissionGuarantee`. This PR fixes them.

r? `@compiler-errors`
2023-12-22 00:03:57 +00:00
Michael Woerister
fa8ef25372 Unify SourceFile::name_hash and StableSourceFileId 2023-12-19 22:34:26 +01:00
Nicholas Nethercote
e7724a2e31 Add level arg to into_diagnostic.
And make all hand-written `IntoDiagnostic` impls generic, by using
`DiagnosticBuilder::new(dcx, level, ...)` instead of e.g.
`dcx.struct_err(...)`.

This means the `create_*` functions are the source of the error level.
This change will let us remove `struct_diagnostic`.

Note: `#[rustc_lint_diagnostics]` is added to `DiagnosticBuilder::new`,
it's necessary to pass diagnostics tests now that it's used in
`into_diagnostic` functions.
2023-12-19 09:19:25 +11:00
bors
e004adb556 Auto merge of #119069 - matthiaskrgr:rollup-xxk4m30, r=matthiaskrgr
Rollup of 5 pull requests

Successful merges:

 - #118852 (coverage: Skip instrumenting a function if no spans were extracted from MIR)
 - #118905 ([AIX] Fix XCOFF metadata)
 - #118967 (Add better ICE messages for some undescriptive panics)
 - #119051 (Replace `FileAllocationInfo` with `FileEndOfFileInfo`)
 - #119059 (Deny `~const` trait bounds in inherent impl headers)

r? `@ghost`
`@rustbot` modify labels: rollup
2023-12-18 08:03:22 +00:00
Matthias Krüger
418ae3e9a0
Rollup merge of #118852 - Zalathar:no-spans, r=cjgillot
coverage: Skip instrumenting a function if no spans were extracted from MIR

The immediate symptoms of #118643 were fixed by #118666, but some users reported that their builds now encounter another coverage-related ICE:

```
error: internal compiler error: compiler/rustc_codegen_llvm/src/coverageinfo/mapgen.rs:98:17: A used function should have had coverage mapping data but did not: (...)
```

I was able to reproduce at least one cause of this error: if no relevant spans could be extracted from a function, but the function contains `CoverageKind::SpanMarker` statements, then codegen still thinks the function is instrumented and complains about the fact that it has no coverage spans.

This PR prevents that from happening in two ways:
- If we didn't extract any relevant spans from MIR, skip instrumenting the entire function and don't create a `FunctionCoverateInfo` for it.
- If coverage codegen sees a `CoverageKind::SpanMarker` statement, skip it early and avoid creating `func_coverage`.

---

Fixes #118850.
2023-12-18 08:08:22 +01:00
Nicholas Nethercote
f6aa418c9f Rename many DiagCtxt and EarlyDiagCtxt locals. 2023-12-18 16:06:22 +11:00
Nicholas Nethercote
f422dca3ae Rename many DiagCtxt arguments. 2023-12-18 16:06:22 +11:00
Nicholas Nethercote
7c656bc05b Rename CodegenContext::create_diag_handler as CodegenContext::create_dcx. 2023-12-18 16:06:21 +11:00
Nicholas Nethercote
09af8a667c Rename Session::span_diagnostic as Session::dcx. 2023-12-18 16:06:21 +11:00