Commit Graph

961 Commits

Author SHA1 Message Date
Gary Guo
1af3e0a65e Ensure #[used] symbols are preserved in LTO 2022-04-24 22:32:05 +01:00
Michael Woerister
8b230086fa debuginfo: Emit ZST struct debuginfo for unit type when CPP-like debuginfo is enabled (instead of custom basic type). 2022-04-22 14:59:35 +02:00
Nikita Popov
6dc0bcc5db Stub out more PassManagerBuilder functions 2022-04-20 09:36:02 +02:00
Nikita Popov
890cabac8a Stub out various legacy PM functions with LLVM 15 2022-04-20 09:25:47 +02:00
Nikita Popov
25286dda2b Drop support for -Znew-llvm-pass-manager=no with LLVM 15 2022-04-20 09:25:47 +02:00
Dylan DPC
69e45d73b9
Rollup merge of #95740 - Amanieu:kreg0, r=nagisa
asm: Add a kreg0 register class on x86 which includes k0

Previously we only exposed a kreg register class which excludes the k0
register since it can't be used in many instructions. However k0 is a
valid register and we need to have a way of marking it as clobbered for
clobber_abi.

Fixes #94977
2022-04-19 22:57:39 +02:00
Amanieu d'Antras
b2bc46938c asm: Add a kreg0 register class on x86 which includes k0
Previously we only exposed a kreg register class which excludes the k0
register since it can't be used in many instructions. However k0 is a
valid register and we need to have a way of marking it as clobbered for
clobber_abi.

Fixes #94977
2022-04-19 17:14:23 +02:00
Gary Guo
49cc6d1f84 Add SymbolExportInfo
This is currently a wrapper to `SymbolExportLevel` but it allows
later addition of extra information.
2022-04-18 20:50:56 +01:00
bors
d9b3ff7d34 Auto merge of #96117 - Dylan-DPC:rollup-5traczf, r=Dylan-DPC
Rollup of 7 pull requests

Successful merges:

 - #95887 (resolve: Create dummy bindings for all unresolved imports)
 - #96023 (couple of clippy::perf fixes)
 - #96035 (Update GitHub Actions actions/checkout Version v2 -> v3)
 - #96038 (docs: add link from zip to unzip)
 - #96047 (⬆️ rust-analyzer)
 - #96059 (clarify doc(cfg) wording)
 - #96081 (Make some `usize`-typed masks definitions agnostic to the size of `usize`)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2022-04-16 14:24:14 +00:00
Dylan DPC
91847c43cc
Rollup merge of #96023 - matthiaskrgr:clippyper1304, r=lcnr
couple of clippy::perf fixes
2022-04-16 14:25:56 +02:00
bors
febce1fc31 Auto merge of #95689 - lqd:self-profiler, r=wesleywiser
Allow self-profiler to only record potentially costly arguments when argument recording is turned on

As discussed [on zulip](https://rust-lang.zulipchat.com/#narrow/stream/247081-t-compiler.2Fperformance/topic/Identifying.20proc-macro.20slowdowns/near/277304909) with `@wesleywiser,` I'd like to record proc-macro expansions in the self-profiler, with some detailed data (per-expansion spans for example, to follow #95473).

At the same time, I'd also like to avoid doing expensive things when tracking a generic activity's arguments, if they were not specifically opted into the event filter mask, to allow the self-profiler to be used in hotter contexts.

This PR tries to offer:
- a way to ensure a closure to record arguments will only be called in that situation, so that potentially costly arguments can still be recorded when needed. With the additional requirement that, if possible, it would offer a way to record non-owned data without adding many `generic_activity_with_arg_{...}`-style methods. This lead to the `generic_activity_with_arg_recorder` single entry-point, and the closure parameter would offer the new methods, able to be executed in a context where costly argument could be created without disturbing the profiled piece of code.
- some facilities/patterns allowing to record more rustc specific data in this situation, without making `rustc_data_structures`  where the self-profiler is defined, depend on other rustc crates (causing circular dependencies): in particular, spans. They are quite tricky to turn into strings (if the default `Debug` impl output does not match the context one needs them for), and since I'd also like to avoid the allocation there when arg recording is turned off today, that has turned into another flexibility requirement for the API in this PR (separating the span-specific recording into an extension trait). **edit**: I've removed this from the PR so that it's easier to review, and opened https://github.com/rust-lang/rust/pull/95739.
- allow for extensibility in the future: other ways to record arguments, or additional data attached to them could be added in the future (e.g. recording the argument's name as well as its data).

Some areas where I'd love feedback:
- the API and names: the `EventArgRecorder` and its method for example. As well as the verbosity that comes from the increased flexibility.
- if I should convert the existing `generic_activity_with_arg{s}` to just forward to `generic_activity_with_arg_recorder` + `recorder.record_arg` (or remove them altogether ? Probably not): I've used the new API in the simple case I could find of allocating for an arg that may not be recorded, and the rest don't seem costly.
- [x] whether this API should panic if no arguments were recorded by the user-provided closure (like this PR currently does: it seems like an error to use an API dedicated to record arguments but not call the methods to then do so) or if this should just record a generic activity without arguments ?
- whether the `record_arg` function should be `#[inline(always)]`, like the `generic_activity_*` functions ?

As mentioned, r? `@wesleywiser` following our recent discussion.
2022-04-16 11:43:28 +00:00
bors
c8422403f7 Auto merge of #96108 - Dylan-DPC:rollup-t5f2fc9, r=Dylan-DPC
Rollup of 9 pull requests

Successful merges:

 - #93969 (Only add codegen backend to dep info if -Zbinary-dep-depinfo is used)
 - #94605 (Add missing links in platform support docs)
 - #95372 (make unaligned_references lint deny-by-default)
 - #95859 (Improve diagnostics for unterminated nested block comment)
 - #95961 (implement SIMD gather/scatter via vector getelementptr)
 - #96004 (Consider lifetimes when comparing types for equality in MIR validator)
 - #96050 (Remove some now-dead code that was only relevant before deaggregation.)
 - #96070 ([test] Add test cases for untested functions for BTreeMap)
 - #96099 (MaybeUninit array cleanup)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2022-04-16 09:19:26 +00:00
Dylan DPC
ea131bca17
Rollup merge of #95961 - RalfJung:gather-scatter, r=workingjubilee
implement SIMD gather/scatter via vector getelementptr

Fixes https://github.com/rust-lang/portable-simd/issues/271

However, I don't *really* know what I am doing here... Cc ``@workingjubilee`` ``@calebzulawski``

I didn't do anything for cranelift -- ``@bjorn3`` not sure if it's okay for that backend to temporarily break. I'm happy to cherry-pick a patch that adds cranelift support. :)
2022-04-16 07:12:45 +02:00
Amanieu d'Antras
547405e801 Add codegen for global_asm! sym operands 2022-04-15 14:36:30 +01:00
Matthias Krüger
bbd7ce6904 couple of clippy::perf fixes 2022-04-13 22:18:28 +02:00
bors
f38c5c8e5d Auto merge of #95656 - cjgillot:no-id-hashing-mode, r=Aaron1011
Remove NodeIdHashingMode.

r? `@ghost`
2022-04-13 11:27:17 +00:00
Camille GILLOT
443333dc1f Remove NodeIdHashingMode. 2022-04-12 19:59:32 +02:00
Ralf Jung
7f945b2b5b add simd_arith_offset intrinsics 2022-04-12 11:09:26 -04:00
Luqman Aden
bf3ef0da0c Switch to the 'normal' basic block for writing asm outputs if needed.
We may sometimes emit an `invoke` instead of a `call` for inline
assembly during the MIR -> LLVM IR lowering. But we failed to update
the IR builder's current basic block before writing the results to the
outputs. This would result in invalid IR because the basic block would
end in a `store` instruction, which isn't a valid terminator.
2022-04-09 15:25:46 -04:00
Rémy Rakic
1906b7e967 port codegen_module activity to arg recorder API 2022-04-07 15:47:20 +02:00
Rémy Rakic
b6a7b5accd remove allocation from a self-profiling call in the LLVM backend 2022-04-07 15:47:20 +02:00
Rémy Rakic
3a8006714b simplify a self-profiling activity call in the LLVM backend
and so that it doesn't allocate unless event argument recording is turned on
2022-04-07 15:47:20 +02:00
Cliff L. Biffle
98190b7168 Revert "Work around invalid DWARF bugs for fat LTO"
Since September, the toolchain has not been generating reliable DWARF
information for static variables when LTO is on. This has affected
projects in the embedded space where the use of LTO is typical. In our
case, it has kept us from bumping past the 2021-09-22 nightly toolchain
lest our debugger break. This has been a pretty dramatic regression for
people using debuggers and static variables. See #90357 for more info
and a repro case.

This commit is a mechanical revert of
d5de680e20 from PR #89041, which caused
the issue. (Note on that PR that the commit's author has requested it be
reverted.)

I have locally verified that this fixes #90357 by restoring the
functionality of both the repro case I posted on that bug, and debugger
behavior on real programs. There do not appear to be test cases for this
in the toolchain; if I've missed them, point me at 'em and I'll update
them.
2022-04-05 10:38:13 -07:00
Oli Scherer
d57b755909 Use WrappingRange::full instead of hand-rolling it 2022-04-05 13:18:22 +00:00
Oli Scherer
d32ce37a17 Mark scalar layout unions so that backends that do not support partially initialized scalars can special case them. 2022-04-05 13:18:21 +00:00
Loïc BRANSTETT
ccff48f97b Replace every String in Target(Options) with Cow<'static, str> 2022-04-03 21:29:57 +02:00
David Morrison
aa67016624 make memcmp return a value of c_int_width instead of i32 2022-04-02 17:21:08 -07:00
Dylan DPC
03b3993ae8
Rollup merge of #95461 - nyurik:spelling, r=lcnr
Spellchecking some comments

This PR attempts to clean up some minor spelling mistakes in comments
2022-03-30 09:10:07 +02:00
Yuri Astrakhan
a9cc3f6564 Spellchecking compiler code
Address some spelling mistakes in strings, private function names, and function params.
2022-03-30 01:42:10 -04:00
Yuri Astrakhan
7e8201ae0a Spellchecking some comments
This PR attempts to clean up some minor spelling mistakes in comments
2022-03-30 01:39:38 -04:00
bors
13c9fc38c9 Auto merge of #95300 - workingjubilee:less-bitsets, r=eddyb
Skip needless bitset for debuginfo

Found this while digging around looking at the inlining logic.
Seemed obvious enough so I decided to try to take care of it.
Is this what you had in mind, `@eddyb?`
2022-03-28 05:48:25 +00:00
Jubilee Young
f5f0e6d551 Skip needless bitset for debuginfo 2022-03-25 03:55:18 -07:00
Michael Woerister
e169261a6f debuginfo: Fix debuginfo for Box<T> where T is unsized.
Before this fix, the debuginfo for the fields was generated from the
struct defintion of Box<T>, but (at least at the moment) the compiler
pretends that Box<T> is just a (fat) pointer, so the fields need to be
`pointer` and `vtable` instead of `__0: Unique<T>` and `__1: Allocator`.

This is meant as a temporary mitigation until we can make sure that
simply treating Box as a regular struct in debuginfo does not cause too
much breakage in the ecosystem.
2022-03-24 11:12:41 +01:00
Dylan DPC
67d6cc6ef3
Rollup merge of #91608 - workingjubilee:fold-neon-fp, r=nagisa,Amanieu
Fold aarch64 feature +fp into +neon

Arm's FEAT_FP and Feat_AdvSIMD describe the same thing on AArch64:
The Neon unit, which handles both floating point and SIMD instructions.
Moreover, a configuration for AArch64 must include both or neither.
Arm says "entirely proprietary" toolchains may omit floating point:
https://developer.arm.com/documentation/102374/0101/Data-processing---floating-point
In the Programmer's Guide for Armv8-A, Arm says AArch64 can have
both FP and Neon or neither in custom implementations:
https://developer.arm.com/documentation/den0024/a/AArch64-Floating-point-and-NEON

In "Bare metal boot code for Armv8-A", enabling Neon and FP
is just disabling the same trap flag:
https://developer.arm.com/documentation/dai0527/a

In an unlikely future where "Neon and FP" become unrelated,
we can add "[+-]fp" as its own feature flag.
Until then, we can simplify programming with Rust on AArch64 by
folding both into "[+-]neon", which is valid as it supersets both.

"[+-]neon" is retained for niche uses such as firmware, kernels,
"I just hate floats", and so on.

I am... pretty sure no one is relying on this.

An argument could be made that, as we are not an "entirely proprietary" toolchain, we should not support AArch64 without floats at all. I think that's a bit excessive. However, I want to recognize the intent: programming for AArch64 should be simplified where possible. For x86-64, programmers regularly set up illegal feature configurations because it's hard to understand them, see https://github.com/rust-lang/rust/issues/89586. And per the above notes, plus the discussion in https://github.com/rust-lang/rust/issues/86941, there should be no real use cases for leaving these features split: the two should in fact always go together.

- Fixes rust-lang/rust#95002.
- Fixes rust-lang/rust#95064.
- Fixes rust-lang/rust#95122.
2022-03-23 03:05:28 +01:00
Jubilee Young
990c297ffb Filter for all features instead of any
Adds regression tests for feature logic
Co-authored-by: bjorn3 <bjorn3@users.noreply.github.com>
Co-authored-by: Simonas Kazlauskas <git@kazlauskas.me>
2022-03-22 15:20:01 -07:00
Jubilee Young
b807d5970b Fold aarch64 feature +fp into +neon
Arm's FEAT_FP and Feat_AdvSIMD describe the same thing on AArch64:
The Neon unit, which handles both floating point and SIMD instructions.
Moreover, a configuration for AArch64 must include both or neither.
Arm says "entirely proprietary" toolchains may omit floating point:
https://developer.arm.com/documentation/102374/0101/Data-processing---floating-point
In the Programmer's Guide for Armv8-A, Arm says AArch64 can have
both FP and Neon or neither in custom implementations:
https://developer.arm.com/documentation/den0024/a/AArch64-Floating-point-and-NEON

In "Bare metal boot code for Armv8-A", enabling Neon and FP
is just disabling the same trap flag:
https://developer.arm.com/documentation/dai0527/a

In an unlikely future where "Neon and FP" become unrelated,
we can add "[+-]fp" as its own feature flag.
Until then, we can simplify programming with Rust on AArch64 by
folding both into "[+-]neon", which is valid as it supersets both.

"[+-]neon" is retained for niche uses such as firmware, kernels,
"I just hate floats", and so on.
2022-03-22 15:14:33 -07:00
bors
d6f3a4ecb4 Auto merge of #88098 - Amanieu:oom_panic, r=nagisa
Implement -Z oom=panic

This PR removes the `#[rustc_allocator_nounwind]` attribute on `alloc_error_handler` which allows it to unwind with a panic instead of always aborting. This is then used to implement `-Z oom=panic` as per RFC 2116 (tracking issue #43596).

Perf and binary size tests show negligible impact.
2022-03-18 03:01:46 +00:00
bors
040703018c Auto merge of #94261 - michaelwoerister:debuginfo-types-refactor, r=wesleywiser
debuginfo: Refactor debuginfo generation for types

This PR implements the refactoring of the `rustc_codegen_llvm::debuginfo::metadata` module as described in MCP https://github.com/rust-lang/compiler-team/issues/482.

In particular it
- changes names to use `di_node` instead of `metadata`
- uniformly names all functions that build new debuginfo nodes `build_xyz_di_node`
- renames `CrateDebugContext` to `CodegenUnitDebugContext` (which is more accurate)
- removes outdated parts from `compiler/rustc_codegen_llvm/src/debuginfo/doc.md`
- moves `TypeMap` and functions that work directly work with it to a new `type_map` module
- moves enum related builder functions to a new `enums` module
- splits enum debuginfo building for the native and cpp-like cases, since they are mostly separate
- uses `SmallVec` instead of `Vec` in many places
- removes the old infrastructure for dealing with recursion cycles (`create_and_register_recursive_type_forward_declaration()`, `RecursiveTypeDescription`, `set_members_of_composite_type()`, `MemberDescription`, `MemberDescriptionFactory`, `prepare_xyz_metadata()`, etc)
- adds `type_map::build_type_with_children()` as a replacement for dealing with recursion cycles
- adds many (doc-)comments explaining what's going on
- changes cpp-like naming for C-Style enums so they don't get a `enum$<...>` name (because the NatVis visualizer does not apply to them)
- fixes detection of what is a C-style enum because some enums where classified as C-style even though they have fields
- changes cpp-like naming for generator enums so that NatVis works for them
- changes the position of discriminant debuginfo node so it is consistently nested inside the top-level union instead of, sometimes, next to it

The following could be done in subsequent PRs:
- add caching for `closure_saved_names_of_captured_variables`
- add caching for `generator_layout_and_saved_local_names`
- fix inconsistent handling of what is considered a C-style enum wrt to debuginfo
- rename `metadata` module to `types`
- move common generator fields to front instead of appending them

This PR is based on https://github.com/rust-lang/rust/pull/93644 which is not merged yet.

Right now, the changes are all done in one big commit. They could be split into smaller commits but hopefully the list of changes above makes it tractable to review them as a single commit too.

For now: r? `@ghost` (let's see if this affects compile times)
2022-03-15 10:52:32 +00:00
Michael Woerister
584855e03d debuginfo: Refactor debuginfo generation for types -- Rename DebugInfoMethods::create_vtable_metadata() to DebugInfoMethods::create_vtable_debuginfo() 2022-03-14 17:25:24 +01:00
Michael Woerister
9580a7115d debuginfo: Refactor debuginfo generation for types -- Address review comments. 2022-03-14 17:25:17 +01:00
Matthias Krüger
0e423932f8
Rollup merge of #90621 - adamgemmell:dev/stabilise-target-feature, r=Amanieu
Stabilise `aarch64_target_feature`

This PR stabilises `aarch64_target_feature` - see https://github.com/rust-lang/rust/issues/90620
2022-03-14 17:24:56 +01:00
Michael Woerister
19707b0ff2 debuginfo: Refactor debuginfo generation for types -- Address outstanding FIXMEs. 2022-03-14 16:55:01 +01:00
Michael Woerister
07a1194edf debuginfo: Refactor debuginfo generation for types -- Run x.py fmt 2022-03-14 16:52:47 +01:00
Michael Woerister
5144661d6b Remove out-dated information from rustc_codegen_llvm/src/debuginfo/doc.md 2022-03-14 16:52:47 +01:00
Michael Woerister
07ebc13d87 debuginfo: Refactor debuginfo generation for types
This commit
- changes names to use di_node instead of metadata
- uniformly names all functions that build new debuginfo nodes build_xyz_di_node
- renames CrateDebugContext to CodegenUnitDebugContext (which is more accurate)
- moves TypeMap and functions that work directly work with it to a new type_map module
- moves and reimplements enum related builder functions to a new enums module
- splits enum debuginfo building for the native and cpp-like cases, since they are mostly separate
- uses SmallVec instead of Vec in many places
- removes the old infrastructure for dealing with recursion cycles (create_and_register_recursive_type_forward_declaration(), RecursiveTypeDescription, set_members_of_composite_type(), MemberDescription, MemberDescriptionFactory, prepare_xyz_metadata(), etc)
- adds type_map::build_type_with_children() as a replacement for dealing with recursion cycles
- adds many (doc-)comments explaining what's going on
- changes cpp-like naming for C-Style enums so they don't get a enum$<...> name (because the NatVis visualizer does not apply to them)
- fixes detection of what is a C-style enum because some enums where classified as C-style even though they have fields
- changes the position of discriminant debuginfo node so it is consistently nested inside the top-level union instead of, sometimes, next to it
2022-03-14 16:49:06 +01:00
Adam Gemmell
39961390ad Tie fp and neon 2022-03-14 10:54:21 +00:00
bors
012720ffb0 Auto merge of #94733 - nnethercote:fix-AdtDef-interning, r=fee1-dead
Improve `AdtDef` interning.

This commit makes `AdtDef` use `Interned`. Much of the commit is tedious
changes to introduce getter functions. The interesting changes are in
`compiler/rustc_middle/src/ty/adt.rs`.

r? `@fee1-dead`
2022-03-12 07:02:05 +00:00
Nicholas Nethercote
ca5525d564 Improve AdtDef interning.
This commit makes `AdtDef` use `Interned`. Much the commit is tedious
changes to introduce getter functions. The interesting changes are in
`compiler/rustc_middle/src/ty/adt.rs`.
2022-03-11 13:31:24 +11:00
Dylan DPC
b18b2d1bcd
Rollup merge of #94728 - compiler-errors:box-allocator-zst-meta, r=michaelwoerister
Only emit pointer-like metadata for `Box<T, A>` when `A` is ZST

Basically copy the change in #94043, but for debuginfo.

r? ``@michaelwoerister``

Fixes #94725
2022-03-10 23:13:00 +01:00
bors
282778aee2 Auto merge of #94764 - nikic:update-llvm-3, r=nagisa
Update LLVM submodule

This merges upstream changes from the 14.x release branch.

Fixes #89609.
Fixes #93923.
Fixes #94032.
2022-03-10 08:56:02 +00:00
Nikita Popov
0c7d0a19dd Use new pass manager on s390x with LLVM 14
The problematic compile-time issue should be resolved with this
version.
2022-03-09 10:00:23 +01:00
lcnr
b8135fd5c8 add #[rustc_pass_by_value] to more types 2022-03-08 15:39:52 +01:00
Michael Goulet
307ee94a8a only emit pointer-like metadata for BZST-allocator Box 2022-03-07 23:06:59 -08:00
bors
ecb867ec3c Auto merge of #94690 - nnethercote:clarify-Layout-interning, r=fee1-dead
Clarify `Layout` interning.

`Layout` is another type that is sometimes interned, sometimes not, and
we always use references to refer to it so we can't take any advantage
of the uniqueness properties for hashing or equality checks.

This commit renames `Layout` as `LayoutS`, and then introduces a new
`Layout` that is a newtype around an `Interned<LayoutS>`. It also
interns more layouts than before. Previously layouts within layouts
(via the `variants` field) were never interned, but now they are. Hence
the lifetime on the new `Layout` type.

Unlike other interned types, these ones are in `rustc_target` instead of
`rustc_middle`. This reflects the existing structure of the code, which
does layout-specific stuff in `rustc_target` while `TyAndLayout` is
generic over the `Ty`, allowing the type-specific stuff to occur in
`rustc_middle`.

The commit also adds a `HashStable` impl for `Interned`, which was
needed. It hashes the contents, unlike the `Hash` impl which hashes the
pointer.

r? `@fee1-dead`
2022-03-07 15:25:42 +00:00
Nicholas Nethercote
4f008e06c3 Clarify Layout interning.
`Layout` is another type that is sometimes interned, sometimes not, and
we always use references to refer to it so we can't take any advantage
of the uniqueness properties for hashing or equality checks.

This commit renames `Layout` as `LayoutS`, and then introduces a new
`Layout` that is a newtype around an `Interned<LayoutS>`. It also
interns more layouts than before. Previously layouts within layouts
(via the `variants` field) were never interned, but now they are. Hence
the lifetime on the new `Layout` type.

Unlike other interned types, these ones are in `rustc_target` instead of
`rustc_middle`. This reflects the existing structure of the code, which
does layout-specific stuff in `rustc_target` while `TyAndLayout` is
generic over the `Ty`, allowing the type-specific stuff to occur in
`rustc_middle`.

The commit also adds a `HashStable` impl for `Interned`, which was
needed. It hashes the contents, unlike the `Hash` impl which hashes the
pointer.
2022-03-07 13:41:47 +11:00
bors
3d1eaf4b62 Auto merge of #94638 - erikdesjardins:noextranull, r=nagisa
cleanup: remove unused ability to have LLVM null-terminate const strings

(and the copied function in rustc_codegen_gcc)

Noticed this while writing https://github.com/rust-lang/rust/pull/94450#issuecomment-1059687348.

r? `@nagisa`
2022-03-07 02:07:36 +00:00
bors
8876ca3dd4 Auto merge of #94597 - nnethercote:ConstAllocation, r=fee1-dead
Introduce `ConstAllocation`.

Currently some `Allocation`s are interned, some are not, and it's very
hard to tell at a use point which is which.

This commit introduces `ConstAllocation` for the known-interned ones,
which makes the division much clearer. `ConstAllocation::inner()` is
used to get the underlying `Allocation`.

In some places it's natural to use an `Allocation`, in some it's natural
to use a `ConstAllocation`, and in some places there's no clear choice.
I've tried to make things look as nice as possible, while generally
favouring `ConstAllocation`, which is the type that embodies more
information. This does require quite a few calls to `inner()`.

The commit also tweaks how `PartialOrd` works for `Interned`. The
previous code was too clever by half, building on `T: Ord` to make the
code shorter. That caused problems with deriving `PartialOrd` and `Ord`
for `ConstAllocation`, so I changed it to build on `T: PartialOrd`,
which is slightly more verbose but much more standard and avoided the
problems.

r? `@fee1-dead`
2022-03-06 22:37:54 +00:00
Nicholas Nethercote
4852291417 Introduce ConstAllocation.
Currently some `Allocation`s are interned, some are not, and it's very
hard to tell at a use point which is which.

This commit introduces `ConstAllocation` for the known-interned ones,
which makes the division much clearer. `ConstAllocation::inner()` is
used to get the underlying `Allocation`.

In some places it's natural to use an `Allocation`, in some it's natural
to use a `ConstAllocation`, and in some places there's no clear choice.
I've tried to make things look as nice as possible, while generally
favouring `ConstAllocation`, which is the type that embodies more
information. This does require quite a few calls to `inner()`.

The commit also tweaks how `PartialOrd` works for `Interned`. The
previous code was too clever by half, building on `T: Ord` to make the
code shorter. That caused problems with deriving `PartialOrd` and `Ord`
for `ConstAllocation`, so I changed it to build on `T: PartialOrd`,
which is slightly more verbose but much more standard and avoided the
problems.
2022-03-07 08:25:50 +11:00
bors
38a0b81b1c Auto merge of #94679 - matthiaskrgr:rollup-9vd7w6a, r=matthiaskrgr
Rollup of 3 pull requests

Successful merges:

 - #94659 (explain why shift with signed offset works the way it does)
 - #94671 (fix pin doc typo)
 - #94672 (Improved error message for failed bitcode load)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2022-03-06 20:21:35 +00:00
Erik Desjardins
e1a4bf6492 cleanup: remove unused ability to have LLVM null-terminate const strings 2022-03-06 12:28:46 -05:00
Joe
65ec4dd904
Improved error message for failed bitcode load
"bc" is an unnecessary shorthand that obfuscates the compilation error
2022-03-06 15:25:05 +01:00
Tomasz Miąsko
095d818e0c Always include global target features in function attributes
This ensures that information about target features configured with
`-C target-feature=...` or detected with `-C target-cpu=native` is
retained for subsequent consumers of LLVM bitcode.

This is crucial for linker plugin LTO, since this information is not
conveyed to the plugin otherwise.
2022-03-04 16:57:34 +01:00
Tomasz Miąsko
b6f845f225 Use SmallStr when building target-features LLVM attribute 2022-03-04 16:57:34 +01:00
bors
047f9c4bc4 Auto merge of #94539 - tmiasko:string-attributes, r=nikic
Pass LLVM string attributes as string slices
2022-03-04 10:38:11 +00:00
bors
62ff2bcf94 Auto merge of #94159 - erikdesjardins:align-load, r=nikic
Add !align metadata on loads of &/&mut/Box

Note that this refers to the alignment of what the loaded value points
to, _not_ the alignment of the loaded value itself.

r? `@ghost` (blocked on #94158)
2022-03-04 08:14:31 +00:00
Amanieu d'Antras
aa36237e16 Add -Z oom={panic,abort} command-line option 2022-03-03 12:58:38 +00:00
cuishuang
00fffdddd2 all: fix some typos
Signed-off-by: cuishuang <imcusg@gmail.com>
2022-03-03 19:47:23 +08:00
Dylan DPC
878a4ff90e
Rollup merge of #94529 - GuillaumeGomez:unused-doc-comments-blocks, r=estebank
Unused doc comments blocks

Fixes #77030.
2022-03-03 01:09:15 +01:00
Tomasz Miąsko
926bf1a371 Pass LLVM string attributes as string slices 2022-03-03 00:28:50 +01:00
Guillaume Gomez
628fbdf9b7 Fix unused_doc_comments lint errors 2022-03-02 20:06:35 +01:00
mark
e489a94dee rename ErrorReported -> ErrorGuaranteed 2022-03-02 09:45:25 -06:00
bors
c42d846add Auto merge of #94229 - erikdesjardins:rem2, r=nikic
Remove LLVM attribute removal

This was necessary before, because `declare_raw_fn` would always apply
the default optimization attributes to every declared function.
Then `attributes::from_fn_attrs` would have to remove the default
attributes in the case of, e.g. `#[optimize(speed)]` in a `-Os` build.
(see [`src/test/codegen/optimize-attr-1.rs`](03a8cc7df1/src/test/codegen/optimize-attr-1.rs (L33)))

However, every relevant callsite of `declare_raw_fn` (i.e. where we
actually generate code for the function, and not e.g. a call to an
intrinsic, where optimization attributes don't [?] matter)
calls `from_fn_attrs`, so we can remove the attribute setting
from `declare_raw_fn`, and rely on `from_fn_attrs` to apply the correct
attributes all at once.

r? `@ghost` (blocked on #94221)
`@rustbot` label S-blocked
2022-03-02 08:48:33 +00:00
bors
39a3b52767 Auto merge of #87402 - nagisa:nagisa/request-feature-requests-for-features, r=estebank
Direct users towards using Rust target feature names in CLI

This PR consists of a couple of changes on how we handle target features.

In particular there is a bug-fix wherein we avoid passing through features that aren't prefixed by `+` or `-` to LLVM. These appear to be causing LLVM to assert, which is pretty poor a behaviour (and also makes it pretty clear we expect feature names to be prefixed).

The other commit, I anticipate to be somewhat more controversial is outputting a warning when users specify a LLVM-specific, or otherwise unknown, feature name on the CLI. In those situations we request users to either replace it with a known Rust feature name (e.g. `bmi` -> `bmi1`) or file a feature request. I've a couple motivations for this: first of all, if users are specifying these features on the command line, I'm pretty confident there is also a need for these features to be usable via `#[cfg(target_feature)]` machinery.  And second, we're growing a fair number of backends recently and having ability to provide some sort of unified-ish interface in this place seems pretty useful to me.

Sponsored by: standard.ai
2022-03-02 03:03:22 +00:00
bors
4a56cbec59 Auto merge of #94402 - erikdesjardins:revert-coldland, r=nagisa
Revert "Auto merge of #92419 - erikdesjardins:coldland, r=nagisa"

Should fix (untested) #94390

Reopens #46515, #87055

r? `@ehuss`
2022-03-01 08:57:46 +00:00
Erik Desjardins
69ae4233cf Add !align metadata on loads of &/&mut/Box
Note that this refers to the alignment of what the loaded value points
to, _not_ the alignment of the loaded value itself.
2022-02-28 20:04:36 -05:00
Simonas Kazlauskas
df701a292c Querify global_backend_features
At the very least this serves to deduplicate the diagnostics that are
output about unknown target features provided via CLI.
2022-03-01 01:57:25 +02:00
Simonas Kazlauskas
c97c216efd Direct users towards using Rust feature names in CLI
If they are trying to use features rustc doesn't yet know about,
request a feature request.

Additionally, also warn against using feature names without leading `+`
or `-` signs.
2022-03-01 01:57:10 +02:00
Matthias Krüger
ea39f46cad
Rollup merge of #94365 - mati865:fix-mingw-detection-for-rawdylib, r=michaelwoerister
Fix MinGW target detection in raw-dylib

LLVM target doesn't have to be the same as Rust target so relying on it is wrong.

It was one of concerns in https://github.com/rust-lang/rust/pull/88801 that was not fixed in https://github.com/rust-lang/rust/pull/90782.
2022-02-28 12:57:48 +01:00
Erik Desjardins
dce14cfacc Remove LLVM attribute removal
This was necessary before, because `declare_raw_fn` would always apply
the default optimization attributes to every declared function,
and then `attributes::from_fn_attrs` would have to remove the default
attributes in the case of, e.g. `#[optimize(speed)]` in a `-Os` build.

However, every relevant callsite of `declare_raw_fn` (i.e. where we
actually generate code for the function, and not e.g. a call to an
intrinsic, where optimization attributes don't [?] matter)
calls `from_fn_attrs`, so we can simply remove the attribute setting
from `declare_raw_fn`, and rely on `from_fn_attrs` to apply the correct
attributes all at once.
2022-02-28 00:02:11 -05:00
Erik Desjardins
851fcc7a54 Revert "Auto merge of #92419 - erikdesjardins:coldland, r=nagisa"
This reverts commit 4f49627c6f, reversing
changes made to 028c6f1454.
2022-02-27 23:11:03 -05:00
Simonas Kazlauskas
dfcfaa4ec1 Do not pass through features without +/- prefix
LLVM really dislikes this and will assert, saying something along the
lines of:

```
rustc: llvm/lib/MC/MCSubtargetInfo.cpp:60: void ApplyFeatureFlag(
  llvm::FeatureBitset&, llvm::StringRef, llvm::ArrayRef<llvm::SubtargetFeatureKV>
): Assertion
  `SubtargetFeatures::hasFlag(Feature) && "Feature flags should start with '+' or '-'"`
failed.
```
2022-02-27 21:21:38 +02:00
Erik Desjardins
fec4335407 Apply noundef metadata to loads of types that do not permit raw init
This matches the noundef attributes we apply on arguments/return types.
2022-02-27 12:16:16 -05:00
bors
2bd9656c80 Auto merge of #94221 - erikdesjardins:addattr, r=nikic
Add LLVM attributes in batches instead of individually

This should improve performance.

~r? `@ghost` (blocked on #94127)~
2022-02-27 09:23:24 +00:00
Erik Desjardins
91e7e8ddcb just put smallvec lengths in the signature 2022-02-26 16:58:17 -05:00
bors
761e888485 Auto merge of #93516 - nagisa:branch-protection, r=cjgillot
No branch protection metadata unless enabled

Even if we emit metadata disabling branch protection, this metadata may
conflict with other modules (e.g. during LTO) that have different branch
protection metadata set.

This is an unstable flag and feature, so ideally the flag not being
specified should act as if the feature wasn't implemented in the first
place.

Additionally this PR also ensures we emit an error if
`-Zbranch-protection` is set on targets other than the supported
aarch64. For now the error is being output from codegen, but ideally it
should be moved to earlier in the pipeline before stabilization.
2022-02-26 21:53:03 +00:00
Erik Desjardins
30d3ce0674 Add LLVM attributes in batches instead of individually
This should improve performance.
2022-02-26 13:14:55 -05:00
bors
8128e910c0 Auto merge of #94127 - erikdesjardins:debugattr, r=nikic
At opt-level=0, apply only ABI-affecting attributes to functions

This should provide a small perf improvement for debug builds,
and should more than cancel out the perf regression from adding noundef (https://github.com/rust-lang/rust/pull/93670#issuecomment-1038347581, #94106).

r? `@nikic`
2022-02-26 09:41:19 +00:00
bors
d981633ed6 Auto merge of #94290 - Mark-Simulacrum:bump-bootstrap, r=pietroalbini
Bump bootstrap to 1.60

This bumps the bootstrap compiler to 1.60 and cleans up cfgs and Span's rustc_pass_by_value (enabled by the bootstrap bump).
2022-02-25 18:34:02 +00:00
Mateusz Mikuła
c35a1d4028 Fix MinGW target detection in raw-dylib
LLVM target doesn't have to be the same as Rust target so relying on it is wrong.
2022-02-25 17:46:23 +01:00
Mark Rousskov
22c3a71de1 Switch bootstrap cfgs 2022-02-25 08:00:52 -05:00
bors
9b2a46591a Auto merge of #93644 - michaelwoerister:simpler-debuginfo-typemap, r=wesleywiser
debuginfo: Simplify TypeMap used during LLVM debuginfo generation.

This PR simplifies the TypeMap that is used in `rustc_codegen_llvm::debuginfo::metadata`. It was unnecessarily complicated because it was originally implemented when types were not yet normalized before codegen. So it did it's own normalization and kept track of multiple unnormalized types being mapped to a single unique id.

This PR is based on https://github.com/rust-lang/rust/pull/93503, which is not merged yet.

The PR also removes the arena used for allocating string ids and instead uses `InlinableString` from the [inlinable_string](https://crates.io/crates/inlinable_string) crate. That might not be the best choice, since that crate does not seem to be very actively maintained. The [flexible-string](https://crates.io/crates/flexible-string) crate would be an alternative.

r? `@ghost`
2022-02-25 11:00:32 +00:00
Michael Woerister
bb2059f959 debuginfo: Simplify TypeMap used during LLVM debuginfo generation -- address review comments. 2022-02-25 10:30:45 +01:00
bors
ece55d416e Auto merge of #94130 - erikdesjardins:partially, r=nikic
Use undef for (some) partially-uninit constants

There needs to be some limit to avoid perf regressions on large arrays
with undef in each element (see comment in the code).

Fixes: #84565
Original PR: #83698

Depends on LLVM 14: #93577
2022-02-25 05:44:33 +00:00
Dylan DPC
6b03a46f27
Rollup merge of #94242 - compiler-errors:fat-uninhabitable-pointer, r=michaelwoerister
properly handle fat pointers to uninhabitable types

Calculate the pointee metadata size by using `tcx.struct_tail_erasing_lifetimes` instead of duplicating the logic in `fat_pointer_kind`. Open to alternatively suggestions on how to fix this.

Fixes #94149

r? ````@michaelwoerister```` since you touched this code last, I think!
2022-02-24 21:42:15 +01:00
bors
3d127e2040 Auto merge of #94123 - bjorn3:cg_ssa_singleton_builder, r=tmiasko
Partially move cg_ssa towards using a single builder

Not all codegen backends can handle hopping between blocks well. For example Cranelift requires blocks to be terminated before switching to building a new block. Rust-gpu requires a `RefCell` to allow hopping between blocks and cg_gcc currently has a buggy implementation of hopping between blocks. This PR reduces the amount of cases where cg_ssa switches between blocks before they are finished and mostly fixes the block hopping in cg_gcc. (~~only `scalar_to_backend` doesn't handle it correctly yet in cg_gcc~~ fixed that one.)

`@antoyo` please review the cg_gcc changes.
2022-02-24 12:28:19 +00:00
bjorn3
96cf7999ab Introduce Bx::switch_to_block 2022-02-24 12:18:21 +01:00
Matthias Krüger
77a8e60dd7
Rollup merge of #89887 - arlosi:char-debug, r=wesleywiser
Change `char` type in debuginfo to DW_ATE_UTF

Rust previously encoded the `char` type as DW_ATE_unsigned_char. The more appropriate encoding is `DW_ATE_UTF`.

Clang also uses the DW_ATE_UTF for `char32_t` in C++.

This fixes the display of the `char` type in the Windows debuggers. Without this change, the variable did not show in the locals window.
![image](https://user-images.githubusercontent.com/704597/137368067-9b3e4dc8-a075-44ba-a687-bf3810a44e5a.png)

LLDB 13 is also able to display the char value, when before it failed with `need to add support for DW_TAG_base_type 'char' encoded with DW_ATE = 0x8, bit_size = 32`

r? `@wesleywiser`
2022-02-24 07:48:04 +01:00
Arlo Siemsen
be454f056f Change char type in debuginfo to DW_ATE_UTF
Rust previously encoded the `char` type as DW_ATE_unsigned_char. The more
appropriate encoding is DW_ATE_UTF.

Clang uses this same debug encoding for char32_t.

This fixes the display of `char` types in Windows debuggers as well as LLDB.
2022-02-23 08:31:10 -08:00
Michael Goulet
c73a2f8a65 properly handle fat pointers to uninhabitable types 2022-02-23 08:20:12 -08:00
David Wood
4e41a46f6a Reapply cg_llvm: fewer_names in uncached_llvm_type
Co-authored-by: Erik Desjardins <erikdesjardins@users.noreply.github.com>
Co-authored-by: Tomasz Miąsko <tomasz.miasko@gmail.com>
2022-02-22 08:23:53 +01:00
Michael Woerister
e72e6399b1 debuginfo: Simplify TypeMap used during LLVM debuginfo generation.
The previous implementation was written before types were properly
normalized for code generation and had to assume a more complicated
relationship between types and their debuginfo -- generating separate
identifiers for debuginfo nodes that were based on normalized types.

Since types are now already normalized, we can use them as identifiers
for debuginfo nodes.
2022-02-21 13:03:36 +01:00
lcnr
1245131a11 use List<Ty<'tcx>> for tuples 2022-02-21 07:09:11 +01:00
bors
45e2c2881d Auto merge of #93678 - steffahn:better_unsafe_diagnostics, r=nagisa
Improve `unused_unsafe` lint

I’m going to add some motivation and explanation below, particularly pointing the changes in behavior from this PR.

_Edit:_ Looking for existing issues, looks like this PR fixes #88260.

_Edit2:_ Now also contains code that closes #90776.
2022-02-20 21:15:11 +00:00
Frank Steffahn
8f8689fb31 Improve unused_unsafe lint
Main motivation: Fixes some issues with the current behavior. This PR is
more-or-less completely re-implementing the unused_unsafe lint; it’s also only
done in the MIR-version of the lint, the set of tests for the `-Zthir-unsafeck`
version no longer succeeds (and is thus disabled, see `lint-unused-unsafe.rs`).

On current nightly,
```rs
unsafe fn unsf() {}

fn inner_ignored() {
    unsafe {
        #[allow(unused_unsafe)]
        unsafe {
            unsf()
        }
    }
}
```

doesn’t create any warnings. This situation is not unrealistic to come by, the
inner `unsafe` block could e.g. come from a macro. Actually, this PR even
includes removal of one unused `unsafe` in the standard library that was missed
in a similar situation. (The inner `unsafe` coming from an external macro hides
    the warning, too.)

The reason behind this problem is how the check currently works:
* While generating MIR, it already skips nested unsafe blocks (i.e. unsafe
  nested in other unsafe) so that the inner one is always the one considered
  unused
* To differentiate the cases of no unsafe operations inside the `unsafe` vs.
  a surrounding `unsafe` block, there’s some ad-hoc magic walking up the HIR to
  look for surrounding used `unsafe` blocks.

There’s a lot of problems with this approach besides the one presented above.
E.g. the MIR-building uses checks for `unsafe_op_in_unsafe_fn` lint to decide
early whether or not `unsafe` blocks in an `unsafe fn` are redundant and ought
to be removed.
```rs
unsafe fn granular_disallow_op_in_unsafe_fn() {
    unsafe {
        #[deny(unsafe_op_in_unsafe_fn)]
        {
            unsf();
        }
    }
}
```
```
error: call to unsafe function is unsafe and requires unsafe block (error E0133)
  --> src/main.rs:13:13
   |
13 |             unsf();
   |             ^^^^^^ call to unsafe function
   |
note: the lint level is defined here
  --> src/main.rs:11:16
   |
11 |         #[deny(unsafe_op_in_unsafe_fn)]
   |                ^^^^^^^^^^^^^^^^^^^^^^
   = note: consult the function's documentation for information on how to avoid undefined behavior

warning: unnecessary `unsafe` block
  --> src/main.rs:10:5
   |
9  | unsafe fn granular_disallow_op_in_unsafe_fn() {
   | --------------------------------------------- because it's nested under this `unsafe` fn
10 |     unsafe {
   |     ^^^^^^ unnecessary `unsafe` block
   |
   = note: `#[warn(unused_unsafe)]` on by default

```
Here, the intermediate `unsafe` was ignored, even though it contains a unsafe
operation that is not allowed to happen in an `unsafe fn` without an additional `unsafe` block.

Also closures were problematic and the workaround/algorithms used on current
nightly didn’t work properly. (I skipped trying to fully understand what it was
supposed to do, because this PR uses a completely different approach.)
```rs
fn nested() {
    unsafe {
        unsafe { unsf() }
    }
}
```
```
warning: unnecessary `unsafe` block
  --> src/main.rs:10:9
   |
9  |     unsafe {
   |     ------ because it's nested under this `unsafe` block
10 |         unsafe { unsf() }
   |         ^^^^^^ unnecessary `unsafe` block
   |
   = note: `#[warn(unused_unsafe)]` on by default
```

vs

```rs
fn nested() {
    let _ = || unsafe {
        let _ = || unsafe { unsf() };
    };
}
```
```
warning: unnecessary `unsafe` block
 --> src/main.rs:9:16
  |
9 |     let _ = || unsafe {
  |                ^^^^^^ unnecessary `unsafe` block
  |
  = note: `#[warn(unused_unsafe)]` on by default

warning: unnecessary `unsafe` block
  --> src/main.rs:10:20
   |
10 |         let _ = || unsafe { unsf() };
   |                    ^^^^^^ unnecessary `unsafe` block
```

*note that this warning kind-of suggests that **both** unsafe blocks are redundant*

--------------------------------------------------------------------------------

I also dislike the fact that it always suggests keeping the outermost `unsafe`.
E.g. for
```rs
fn granularity() {
    unsafe {
        unsafe { unsf() }
        unsafe { unsf() }
        unsafe { unsf() }
    }
}
```
I prefer if `rustc` suggests removing the more-course outer-level `unsafe`
instead of the fine-grained inner `unsafe` blocks, which it currently does on nightly:
```
warning: unnecessary `unsafe` block
  --> src/main.rs:10:9
   |
9  |     unsafe {
   |     ------ because it's nested under this `unsafe` block
10 |         unsafe { unsf() }
   |         ^^^^^^ unnecessary `unsafe` block
   |
   = note: `#[warn(unused_unsafe)]` on by default

warning: unnecessary `unsafe` block
  --> src/main.rs:11:9
   |
9  |     unsafe {
   |     ------ because it's nested under this `unsafe` block
10 |         unsafe { unsf() }
11 |         unsafe { unsf() }
   |         ^^^^^^ unnecessary `unsafe` block

warning: unnecessary `unsafe` block
  --> src/main.rs:12:9
   |
9  |     unsafe {
   |     ------ because it's nested under this `unsafe` block
...
12 |         unsafe { unsf() }
   |         ^^^^^^ unnecessary `unsafe` block
```

--------------------------------------------------------------------------------

Needless to say, this PR addresses all these points. For context, as far as my
understanding goes, the main advantage of skipping inner unsafe blocks was that
a test case like
```rs
fn top_level_used() {
    unsafe {
        unsf();
        unsafe { unsf() }
        unsafe { unsf() }
        unsafe { unsf() }
    }
}
```
should generate some warning because there’s redundant nested `unsafe`, however
every single `unsafe` block _does_ contain some statement that uses it. Of course
this PR doesn’t aim change the warnings on this kind of code example, because
the current behavior, warning on all the inner `unsafe` blocks, makes sense in this case.

As mentioned, during MIR building all the unsafe blocks *are* kept now, and usage
is attributed to them. The way to still generate a warning like
```
warning: unnecessary `unsafe` block
  --> src/main.rs:11:9
   |
9  |     unsafe {
   |     ------ because it's nested under this `unsafe` block
10 |         unsf();
11 |         unsafe { unsf() }
   |         ^^^^^^ unnecessary `unsafe` block
   |
   = note: `#[warn(unused_unsafe)]` on by default

warning: unnecessary `unsafe` block
  --> src/main.rs:12:9
   |
9  |     unsafe {
   |     ------ because it's nested under this `unsafe` block
...
12 |         unsafe { unsf() }
   |         ^^^^^^ unnecessary `unsafe` block

warning: unnecessary `unsafe` block
  --> src/main.rs:13:9
   |
9  |     unsafe {
   |     ------ because it's nested under this `unsafe` block
...
13 |         unsafe { unsf() }
   |         ^^^^^^ unnecessary `unsafe` block
```

in this case is by emitting a `unused_unsafe` warning for all of the `unsafe`
blocks that are _within a **used** unsafe block_.

The previous code had a little HIR traversal already anyways to collect a set of
all the unsafe blocks (in order to afterwards determine which ones are unused
afterwards). This PR uses such a traversal to do additional things including logic
like _always_ warn for an `unsafe` block that’s inside of another **used**
unsafe block. The traversal is expanded to include nested closures in the same go,
this simplifies a lot of things.

The whole logic around `unsafe_op_in_unsafe_fn` is a little complicated, there’s
some test cases of corner-cases in this PR. (The implementation involves
differentiating between whether a used unsafe block was used exclusively by
operations where `allow(unsafe_op_in_unsafe_fn)` was active.) The main goal was
to make sure that code should compile successfully if all the `unused_unsafe`-warnings
are addressed _simultaneously_ (by removing the respective `unsafe` blocks)
no matter how complicated the patterns of `unsafe_op_in_unsafe_fn` being
disallowed and allowed throughout the function are.

--------------------------------------------------------------------------------

One noteworthy design decision I took here: An `unsafe` block
with `allow(unused_unsafe)` **is considered used** for the purposes of
linting about redundant contained unsafe blocks. So while
```rs

fn granularity() {
    unsafe { //~ ERROR: unnecessary `unsafe` block
        unsafe { unsf() }
        unsafe { unsf() }
        unsafe { unsf() }
    }
}
```
warns for the outer `unsafe` block,
```rs

fn top_level_ignored() {
    #[allow(unused_unsafe)]
    unsafe {
        #[deny(unused_unsafe)]
        {
            unsafe { unsf() } //~ ERROR: unnecessary `unsafe` block
            unsafe { unsf() } //~ ERROR: unnecessary `unsafe` block
            unsafe { unsf() } //~ ERROR: unnecessary `unsafe` block
        }
    }
}
```
warns on the inner ones.
2022-02-20 21:00:12 +01:00
bors
523a1b1d38 Auto merge of #94062 - Mark-Simulacrum:drop-print-cfg, r=oli-obk
Move ty::print methods to Drop-based scope guards

Primary goal is reducing codegen of the TLS access for each closure, which shaves ~3 seconds of bootstrap time over rustc as a whole.
2022-02-20 18:12:59 +00:00
Erik Desjardins
067f628286 add check for llvm 14 2022-02-20 11:37:22 -05:00
bjorn3
e6d7a8d7d4 Remove build_sibling_block 2022-02-20 13:38:15 +01:00
Matthias Krüger
f2d6770f77
Rollup merge of #94146 - est31:let_else, r=cjgillot
Adopt let else in more places

Continuation of #89933, #91018, #91481, #93046, #93590, #94011.

I have extended my clippy lint to also recognize tuple passing and match statements. The diff caused by fixing it is way above 1 thousand lines. Thus, I split it up into multiple pull requests to make reviewing easier. This is the biggest of these PRs and handles the changes outside of rustdoc, rustc_typeck, rustc_const_eval, rustc_trait_selection, which were handled in PRs #94139, #94142, #94143, #94144.
2022-02-20 00:37:34 +01:00
est31
2ef8af6619 Adopt let else in more places 2022-02-19 17:27:43 +01:00
Simonas Kazlauskas
b995dc944c No branch protection metadata unless enabled
Even if we emit metadata disabling branch protection, this metadata may
conflict with other modules (e.g. during LTO) that have different branch
protection metadata set.

This is an unstable flag and feature, so ideally the flag not being
specified should act as if the feature wasn't implemented in the first
place.

Additionally this PR also ensures we emit an error if
`-Zbranch-protection` is set on targets other than the supported
aarch64. For now the error is being output from codegen, but ideally it
should be moved to earlier in the pipeline before stabilization.
2022-02-19 17:31:40 +02:00
Erik Desjardins
6e740ae934 always add align attributes 2022-02-19 09:59:36 -05:00
Erik Desjardins
d5769e9843 switch to limiting the number of init/uninit chunks 2022-02-19 01:29:17 -05:00
bors
1882597991 Auto merge of #94134 - matthiaskrgr:rollup-b132kjz, r=matthiaskrgr
Rollup of 10 pull requests

Successful merges:

 - #89892 (Suggest `impl Trait` return type when incorrectly using a generic return type)
 - #91675 (Add MemTagSanitizer Support)
 - #92806 (Add more information to `impl Trait` error)
 - #93497 (Pass `--test` flag through rustdoc to rustc so `#[test]` functions can be scraped)
 - #93814 (mips64-openwrt-linux-musl: correct soft-foat)
 - #93847 (kmc-solid: Use the filesystem thread-safety wrapper)
 - #93877 (asm: Allow the use of r8-r14 as clobbers on Thumb1)
 - #93892 (Only mark projection as ambiguous if GAT substs are constrained)
 - #93915 (Implement --check-cfg option (RFC 3013), take 2)
 - #93953 (Add the `known-bug` test directive, use it, and do some cleanup)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2022-02-19 02:07:43 +00:00
bors
5a1a3707ff Auto merge of #94050 - michaelwoerister:fix-unsized-tuple-debuginfo, r=pnkfelix
debuginfo: Support fat pointers to unsized tuples.

This PR makes fat pointer debuginfo generation handle the case of unsized tuples.

Fixes #93871
2022-02-18 23:18:12 +00:00
Matthias Krüger
0bb72a2c66
Rollup merge of #91675 - ivanloz:memtagsan, r=nagisa
Add MemTagSanitizer Support

Add support for the LLVM [MemTagSanitizer](https://llvm.org/docs/MemTagSanitizer.html).

On hardware which supports it (see caveats below), the MemTagSanitizer can catch bugs similar to AddressSanitizer and HardwareAddressSanitizer, but with lower overhead.

On a tag mismatch, a SIGSEGV is signaled with code SEGV_MTESERR / SEGV_MTEAERR.

# Usage

`-Zsanitizer=memtag -C target-feature="+mte"`

# Comments/Caveats

* MemTagSanitizer is only supported on AArch64 targets with hardware support
* Requires `-C target-feature="+mte"`
* LLVM MemTagSanitizer currently only performs stack tagging.

# TODO

* Tests
* Example
2022-02-18 23:23:03 +01:00
Erik Desjardins
b7e5597491 Use undef for partially-uninit constants up to 1024 bytes
There needs to be some limit to avoid perf regressions on large arrays
with undef in each element (see comment in the code).
2022-02-18 15:57:10 -05:00
Erik Desjardins
dcbdc8c19b At opt-level=0, apply only ABI-affecting attributes to functions
This should provide a small perf improvement for debug builds,
and should more than cancel out the regression from adding noundef,
which was only significant in debug builds.
2022-02-18 14:36:12 -05:00
Matthias Krüger
a144ea1c4b
Rollup merge of #93634 - matthiaskrgr:clippy_complexity_jan_2022, r=oli-obk
compiler: clippy::complexity fixes

useless_format
map_flatten
useless_conversion
needless_bool
filter_next
clone_on_copy
needless_option_as_deref
2022-02-18 16:23:33 +01:00
Matthias Krüger
6dc62f421d
Rollup merge of #94043 - DrMeepster:box_alloc_ice, r=oli-obk
Fix ICE when using Box<T, A> with pointer sized A

Fixes #78459

Note that using `Box<T, A>` with a more than pointer sized `A` or using a pointer sized `A` with a Box of a DST will produce a different ICE (#92054) which is not fixed by this PR.
2022-02-17 23:01:01 +01:00
bors
30b3f35c42 Auto merge of #93577 - nikic:llvm-14, r=nagisa
Upgrade to LLVM 14

LLVM patch state:
 * [x] a55727f334 Backported.
 * [x] c3c82dc124 Backported as 917c47b3bf.
 * [x] 6e8f9ab632 No plan to upstream.
 * [x] 319f4b2d52 Backported.
 * [x] 8b2c25d321 No plan to upstream.
 * [x] 75fef2efd4 No plan to upstream.
 * [ ] adef757547 Upstreamed as 2d2ef384b2. Needs backport.
 * [x] 4b7c1b4910 No plan to upstream.
 * [x] 3f5ab0c061 No plan to upstream.
 * [x] 514d05500e No plan to upstream.
 * [ ] 54c5869585 Under review at https://reviews.llvm.org/D119695 and https://reviews.llvm.org/D119856.

Release timeline:
 * LLVM 14.0.0 final planned for Mar 15.
 * Rust 1.60.0 planned for Apr 7.

Compile-time:
  * https://perf.rust-lang.org/compare.html?start=250384edc5d78533e993f38c60d64e42b21684b2&end=b87df8d2c7c5d9ac448c585de10927ab2ee1b864
  * A slight improvement on average, though no big changes either way.
  * There are some larger max-rss improvements.

r? `@ghost`
2022-02-17 13:08:46 +00:00
DrMeepster
d0b508e1a7
add comment explaining the check 2022-02-16 16:52:06 -08:00
Mark Rousskov
9763486034 Move ty::print methods to Drop-based scope guards 2022-02-16 17:24:23 -05:00
Nikita Popov
0605a4122f Expose unstable llvm14-builtins-abi target feature for cfg use 2022-02-16 21:15:31 +01:00
Nikita Popov
70ddd2ff1c Update data layout for wasm32 targets
New address spaces were added in https://reviews.llvm.org/D111154.
2022-02-16 21:15:31 +01:00
Nikita Popov
a380581ff8 Update data layout for 32-bit msvc targets
https://reviews.llvm.org/D115942 changed the alignment of f80.
2022-02-16 21:15:30 +01:00
Ivan Lozano
568aeda9e9 MemTagSanitizer Support
Adds support for the LLVM MemTagSanitizer.
2022-02-16 09:39:03 -05:00
Michael Woerister
28ca6b0f79 debuginfo: Support fat pointers to unsized tuples. 2022-02-16 13:29:00 +01:00
DrMeepster
ae32f43c50 fix assumption that ScalarPair Box is always a fat pointer 2022-02-15 20:04:43 -08:00
bors
09cb29c64c Auto merge of #93439 - abrown:cf-protection, r=nagisa
Add support for control-flow protection

This change adds a flag for configuring control-flow protection in the LLVM backend. In Clang, this flag is exposed as `-fcf-protection` with options `none|branch|return|full`. This convention is followed for `rustc`, though as a codegen option: `rustc -Z cf-protection=<none|branch|return|full>`. Tracking issue for future work is #93754.
2022-02-15 21:20:49 +00:00
Matthias Krüger
a87be980d8
Rollup merge of #94001 - durin42:llvm-15-uwtable, r=nikic
llvm: migrate to new parameter-bearing uwtable attr

In https://reviews.llvm.org/D114543 the uwtable attribute gained a flag
so that we can ask for sync uwtables instead of async, as the former are
much cheaper. The default is async, so that's what I've done here, but I
left a TODO that we might be able to do better.

While in here I went ahead and dropped support for removing uwtable
attributes in rustc: we never did it, so I didn't write the extra C++
bridge code to make it work. Maybe I should have done the same thing
with the `sync|async` parameter but we'll see.
2022-02-15 16:02:37 +01:00
Nicholas Nethercote
e9a0c429c5 Overhaul TyS and Ty.
Specifically, change `Ty` from this:
```
pub type Ty<'tcx> = &'tcx TyS<'tcx>;
```
to this
```
pub struct Ty<'tcx>(Interned<'tcx, TyS<'tcx>>);
```
There are two benefits to this.
- It's now a first class type, so we can define methods on it. This
  means we can move a lot of methods away from `TyS`, leaving `TyS` as a
  barely-used type, which is appropriate given that it's not meant to
  be used directly.
- The uniqueness requirement is now explicit, via the `Interned` type.
  E.g. the pointer-based `Eq` and `Hash` comes from `Interned`, rather
  than via `TyS`, which wasn't obvious at all.

Much of this commit is boring churn. The interesting changes are in
these files:
- compiler/rustc_middle/src/arena.rs
- compiler/rustc_middle/src/mir/visit.rs
- compiler/rustc_middle/src/ty/context.rs
- compiler/rustc_middle/src/ty/mod.rs

Specifically:
- Most mentions of `TyS` are removed. It's very much a dumb struct now;
  `Ty` has all the smarts.
- `TyS` now has `crate` visibility instead of `pub`.
- `TyS::make_for_test` is removed in favour of the static `BOOL_TY`,
  which just works better with the new structure.
- The `Eq`/`Ord`/`Hash` impls are removed from `TyS`. `Interned`s impls
  of `Eq`/`Hash` now suffice. `Ord` is now partly on `Interned`
  (pointer-based, for the `Equal` case) and partly on `TyS`
  (contents-based, for the other cases).
- There are many tedious sigil adjustments, i.e. adding or removing `*`
  or `&`. They seem to be unavoidable.
2022-02-15 16:03:24 +11:00
Augie Fackler
0958c8f4ca llvm: migrate to new parameter-bearing uwtable attr
In https://reviews.llvm.org/D114543 the uwtable attribute gained a flag
so that we can ask for sync uwtables instead of async, as the former are
much cheaper. The default is async, so that's what I've done here, but I
left a TODO that we might be able to do better.

While in here I went ahead and dropped support for removing uwtable
attributes in rustc: we never did it, so I didn't write the extra C++
bridge code to make it work. Maybe I should have done the same thing
with the `sync|async` parameter but we'll see.
2022-02-14 16:09:53 -05:00
Andrew Brown
8d6c973c7f Add support for control-flow protection
This change adds a flag for configuring control-flow protection in the
LLVM backend. In Clang, this flag is exposed as `-fcf-protection` with
options `none|branch|return|full`. This convention is followed for
`rustc`, though as a codegen option: `rustc -Z
cf-protection=<none|branch|return|full>`.

Co-authored-by: BlackHoleFox <blackholefoxdev@gmail.com>
2022-02-14 08:31:24 -08:00
bors
5c30d65683 Auto merge of #93670 - erikdesjardins:noundef, r=nikic
Apply noundef attribute to &T, &mut T, Box<T>, bool

This doesn't handle `char` because it's a bit awkward to distinguish it from `u32` at this point in codegen.

Note that this _does not_ change whether or not it is UB for `&`, `&mut`, or `Box` to point to undef. It only applies to the pointer itself, not the pointed-to memory.

Fixes (partially) #74378.

r? `@nikic` cc `@RalfJung`
2022-02-13 00:14:52 +00:00
Matthias Krüger
13d636dff2
Rollup merge of #93782 - adamgemmell:dev/adagem01/split-pauth, r=Amanieu
Split `pauth` target feature

Per discussion on https://github.com/rust-lang/rust/issues/86941 we'd like to split `pauth` into `paca` and `pacg` in order to better support possible future environments that only have the keys available for address or generic authentication. At the moment LLVM has the one `pauth` target_feature while Linux presents separate `paca` and `pacg` flags for feature detection.

Because the use of [target_feature](https://rust-lang.github.io/rfcs/2045-target-feature.html) will "allow the compiler to generate code under the assumption that this code will only be reached in hosts that support the feature", it does not make sense to simply translate `paca` into the LLVM feature `pauth`, as it will generate code as if `pacg` is available.

To accommodate this we error if only one of the two features is present. If LLVM splits them in the future we can remove this restriction without making a breaking change.

r? ```@Amanieu```
2022-02-11 21:48:48 +01:00
bjorn3
609784711a Unconditionally update symbols
All paths to an ArchiveBuilder::build call update_symbols first.
2022-02-10 18:27:18 +01:00
Adam Gemmell
d39a6377e9 Split PAuth target feature 2022-02-10 15:10:33 +00:00
Matthias Krüger
6d40850e09
Rollup merge of #93503 - michaelwoerister:fix-vtable-holder-debuginfo-regression, r=wesleywiser
debuginfo: Fix DW_AT_containing_type vtable debuginfo regression

This PR brings back the `DW_AT_containing_type` attribute for vtables after it has accidentally been removed in #89597.

It also implements a more accurate description of vtables. Instead of describing them as an array of void pointers, the compiler will now emit a struct type description with a field for each entry of the vtable.

r? ``@wesleywiser``

This PR should fix issue https://github.com/rust-lang/rust/issues/93164.
~~The PR is blocked on https://github.com/rust-lang/rust/pull/93154 because both of them modify the `codegen/debug-vtable.rs` test case.~~
2022-02-09 23:29:56 +01:00
Michael Woerister
ed21805aee debuginfo: Bring back DW_AT_containing_type for vtables -- address review comments 2022-02-08 15:31:09 +01:00
Erik Desjardins
75ed7def5d apply noundef explicitly in all cases instead of relying on dereferenceable implying it 2022-02-06 21:11:11 -05:00
cynecx
03733ca65a #[used(linker)] attribute (https://github.com/dtolnay/linkme/issues/41) 2022-02-06 20:23:23 +01:00
Erik Desjardins
8cb0b6ca5b Apply noundef attribute to &T, &mut T, Box<T>, bool
This doesn't handle `char` because it's a bit awkward to distinguish it
from u32 at this point in codegen.

Note that for some types (like `&Struct` and `&mut Struct`),
we already apply `dereferenceable`, which implies `noundef`,
so the IR does not change.
2022-02-05 01:09:52 -05:00
Matthias Krüger
2fe9a32ed2
Rollup merge of #90132 - joshtriplett:stabilize-instrument-coverage, r=wesleywiser
Stabilize `-Z instrument-coverage` as `-C instrument-coverage`

(Tracking issue for `instrument-coverage`: https://github.com/rust-lang/rust/issues/79121)

This PR stabilizes support for instrumentation-based code coverage, previously provided via the `-Z instrument-coverage` option. (Continue supporting `-Z instrument-coverage` for compatibility for now, but show a deprecation warning for it.)

Many, many people have tested this support, and there are numerous reports of it working as expected.

Move the documentation from the unstable book to stable rustc documentation. Update uses and documentation to use the `-C` option.

Addressing questions raised in the tracking issue:

> If/when stabilized, will the compiler flag be updated to -C instrument-coverage? (If so, the -Z variant could also be supported for some time, to ease migrations for existing users and scripts.)

This stabilization PR updates the option to `-C` and keeps the `-Z` variant to ease migration.

> The Rust coverage implementation depends on (and automatically turns on) -Z symbol-mangling-version=v0. Will stabilizing this feature depend on stabilizing v0 symbol-mangling first? If so, what is the current status and timeline?

This stabilization PR depends on https://github.com/rust-lang/rust/pull/90128 , which stabilizes `-C symbol-mangling-version=v0` (but does not change the default symbol-mangling-version).

> The Rust coverage implementation implements the latest version of LLVM's Coverage Mapping Format (version 4), which forces a dependency on LLVM 11 or later. A compiler error is generated if attempting to compile with coverage, and using an older version of LLVM.

Given that LLVM 13 has now been released, requiring LLVM 11 for coverage support seems like a reasonable requirement. If people don't have at least LLVM 11, nothing else breaks; they just can't use coverage support. Given that coverage support currently requires a nightly compiler and LLVM 11 or newer, allowing it on a stable compiler built with LLVM 11 or newer seems like an improvement.

The [tracking issue](https://github.com/rust-lang/rust/issues/79121) and the [issue label A-code-coverage](https://github.com/rust-lang/rust/labels/A-code-coverage) link to a few open issues related to `instrument-coverage`, but none of them seem like showstoppers. All of them seem like improvements and refinements we can make after stabilization.

The original `-Z instrument-coverage` support went through a compiler-team MCP at https://github.com/rust-lang/compiler-team/issues/278 . Based on that, `@pnkfelix` suggested that this needed a stabilization PR and a compiler-team FCP.
2022-02-04 18:42:13 +01:00
Matthias Krüger
03cad867a6
Rollup merge of #93630 - matthiaskrgr:clipperf, r=oli-obk
clippy::perf fixes

single_char_pattern and to_string_in_format_args
2022-02-04 14:59:05 +01:00
Matthias Krüger
f7e0f97631
Rollup merge of #93402 - ehuss:llvm-dialog, r=michaelwoerister
Windows: Disable LLVM crash dialog boxes.

This disables the crash dialog box on Windows. When LLVM hits an assertion, it will open a dialog box with Abort/Retry/Ignore. This is annoying on CI because CI will just hang until it times out (which can take hours).

Instead of opening a dialog box, it will print a message like this:

```
Assertion failed: isa<X>(Val) && "cast<Ty>() argument of incompatible type!", file D:\Proj\rust\rust\src\llvm-project\llvm\include\llvm/Support/Casting.h, line 255
```

Closes #92829
2022-02-04 14:58:57 +01:00
Matthias Krüger
b80057d08d compiler: clippy::complexity fixes
useless_format
map_flatten
useless_conversion
needless_bool
filter_next
clone_on_copy
needless_option_as_deref
2022-02-03 23:16:03 +01:00
Matthias Krüger
de2abc29e9 clippy::perf fixes
single_char_pattern and to_string_in_format_args
2022-02-03 21:45:51 +01:00
Eric Huss
c64d6bf5af Only disable dialogs on CI.
The "CI" environment var isn't universal (for example, I think Azure
uses TF_BUILD). However, we are mostly concerned with rust-lang/rust's
own CI which currently is GitHub Actions which does set "CI". And I
think most other providers use "CI" as well.
2022-02-03 07:03:44 -08:00
Michael Woerister
fc7f419a63 debuginfo: Bring back DW_AT_containing_type for vtables after it has accidentally been
removed in https://github.com/rust-lang/rust/pull/89597.

Also describe vtables as structs with a field for each entry.
2022-02-03 10:03:16 +01:00
Michael Woerister
f4799b8709 debuginfo: Make some helper functions in rustc_codegen_llvm::debuginfo::metadata more generally applicable. 2022-02-03 10:03:16 +01:00
bors
dca1e7aa5a Auto merge of #93154 - michaelwoerister:fix-generic-closure-and-generator-debuginfo, r=wesleywiser
debuginfo: Make sure that type names for closure and generator environments are unique in debuginfo.

Before this change, closure/generator environments coming from different instantiations of the same generic function were all assigned the same name even though they were distinct types with potentially different data layout. Now we append the generic arguments of the originating function to the type name.

This commit also emits `{closure_env#0}` as the name of these types in order to disambiguate them from the accompanying closure function (which keeps being called `{closure#0}`). Previously both were assigned the same name.

NOTE: Changing debuginfo names like this can break pretty printers and other debugger plugins. I think it's OK in this particular case because the names we are changing were ambiguous anyway. In general though it would be great to have a process for doing changes like these.
2022-02-02 12:37:28 +00:00
Michael Woerister
fd7557b7ee debuginfo: Make sure that type names for closure and generator environments are unique in debuginfo.
Before this change, closure/generator environments coming from different
instantiations of the same generic function were all assigned the same
name even though they were distinct types with potentially different data
layout. Now we append the generic arguments of the originating function
to the type name.

This commit also emits '{closure_env#0}' as the name of these types in
order to disambiguate them from the accompanying closure function
'{closure#0}'. Previously both were assigned the same name.
2022-02-01 10:39:40 +01:00
lcnr
a1a30f7548 add a rustc::query_stability lint 2022-02-01 10:15:59 +01:00
bors
6250d5a08c Auto merge of #93427 - matthiaskrgr:rollup-esd3ixl, r=matthiaskrgr
Rollup of 10 pull requests

Successful merges:

 - #92611 (Add links to the reference and rust by example for asm! docs and lints)
 - #93158 (wasi: implement `sock_accept` and enable networking)
 - #93239 (Add os::unix::net::SocketAddr::from_path)
 - #93261 (Some unwinding related cg_ssa cleanups)
 - #93295 (Avoid double panics when using `TempDir` in tests)
 - #93353 (Unimpl {Add,Sub,Mul,Div,Rem,BitXor,BitOr,BitAnd}<$t> for Saturating<$t>)
 - #93356 (Edit docs introduction for `std::cmp::PartialOrd`)
 - #93375 (fix typo `documenation`)
 - #93399 (rustbuild: Fix compiletest warning when building outside of root.)
 - #93404 (Fix a typo from #92899)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2022-01-28 23:20:38 +00:00
Matthias Krüger
ada77e94ab
Rollup merge of #93261 - bjorn3:cg_ssa_refactor6, r=cjgillot
Some unwinding related cg_ssa cleanups

These should make it a bit easier for alternative codegen backends to implement unwinding.
2022-01-28 15:20:24 +01:00
bors
427eba2f0b Auto merge of #93006 - michaelwoerister:fix-unsized-ptr-debuginfo, r=davidtwco,oli-obk
Fix debuginfo for pointers/references to unsized types

This PR makes the compiler emit fat pointer debuginfo in all cases. Before, we sometimes got thin-pointer debuginfo, making it impossible to fully interpret the pointed to memory in debuggers. The code is actually cleaner now, especially around generation of trait object pointer debuginfo.

Fixes https://github.com/rust-lang/rust/issues/92718

~~Blocked on https://github.com/rust-lang/rust/pull/92729.~~
2022-01-28 12:46:13 +00:00
Michael Woerister
c10f9e7d1d [debuginfo] Fix and unify handling of fat pointers in debuginfo: Don't mark fat pointer fields as artificial.
LLDB does not seem to see fields if they are marked with DW_AT_artificial
which breaks pretty printers that use these fields for decoding fat pointers.
2022-01-28 10:41:36 +01:00
Eric Huss
e1eff1b0e8 Windows: Disable LLVM crash dialog boxes. 2022-01-27 16:53:17 -08:00
Michael Woerister
d33e317a72 [debuginfo] Fix and unify handling of fat pointers in debuginfo: Change doc comment so it is not interpreted as doc-test. 2022-01-27 16:55:48 +01:00
Matthias Krüger
13b87d8cc7
Rollup merge of #93269 - jacobbramley:dev/pauth-option-1, r=petrochenkov
Use error-on-mismatch policy for PAuth module flags.

This agrees with Clang, and avoids an error when using LTO with mixed
C/Rust. LLVM considers different behaviour flags to be a mismatch,
even when the flag value itself is the same.

This also makes the flag setting explicit for all uses of
LLVMRustAddModuleFlag.

----

I believe that this fixes #92885, but have only reproduced it locally on Linux hosts so cannot confirm that it fixes the issue as reported.

I have not included a test for this because it is covered by an existing test (`src/test/run-make-fulldeps/cross-lang-lto-clang`). It is not without its problems, though:
* The test requires Clang and `--run-clang-based-tests-with=...` to run, and this is not the case on the CI.
   * Any test I add would have a similar requirement.
* With this patch applied, the test gets further, but it still fails (for other reasons). I don't think that affects #92885.
2022-01-25 05:51:14 +01:00
Matthias Krüger
8dddc86477
Rollup merge of #93144 - wesleywiser:uninhabited_type_code_cov2, r=tmandry
Work around missing code coverage data causing llvm-cov failures

If we do not add code coverage instrumentation to the `Body` of a
function, then when we go to generate the function record for it, we
won't write any data and this later causes llvm-cov to fail when
processing data for the entire coverage report.

I've identified two main cases where we do not currently add code
coverage instrumentation to the `Body` of a function:

  1. If the function has a single `BasicBlock` and it ends with a
     `TerminatorKind::Unreachable`.

  2. If the function is created using a proc macro of some kind.

For case 1, this is typically not important as this most often occurs as
a result of function definitions that take or return uninhabited
types. These kinds of functions, by definition, cannot even be called so
they logically should not be counted in code coverage statistics.

For case 2, I haven't looked into this very much but I've noticed while
testing this patch that (other than functions which are covered by case
1) the skipped function coverage debug message is occasionally triggered
in large crate graphs by functions generated from a proc macro. This may
have something to do with weird spans being generated by the proc macro
but this is just a guess.

I think it's reasonable to land this change since currently, we fail to
generate *any* results from llvm-cov when a function has no coverage
instrumentation applied to it. With this change, we get coverage data
for all functions other than the two cases discussed above.

Fixes #93054 which occurs because of uncallable functions which shouldn't
have code coverage anyway.

I will open an issue for missing code coverage of proc macro generated
functions and leave a link here once I have a more minimal repro.

r? ``@tmandry``
cc ``@richkadel``
2022-01-25 05:51:11 +01:00
Jacob Bramley
e02e9582d2 Use error-on-mismatch policy for PAuth module flags.
This agrees with Clang, and avoids an error when using LTO with mixed
C/Rust. LLVM considers different behaviour flags to be a mismatch,
even when the flag value itself is the same.

This also makes the flag setting explicit for all uses of
LLVMRustAddModuleFlag.
2022-01-24 16:50:10 +00:00
bjorn3
f6ce771172 Merge landing_pad and set_cleanup into cleanup_landing_pad 2022-01-24 14:10:05 +01:00
bjorn3
7a164509d3 Merge add_handler into catch_switch
Some codegen backends may require all handlers to be immediately known
2022-01-24 14:10:05 +01:00
bjorn3
e9646fa76b Remove unused return values from resume and cleanup_ret
Given that these instructions are diverging, not every codegen backend
may be able to produce a return value for them.
2022-01-24 13:48:09 +01:00
bjorn3
19dd2ecc2d Reorder unwinding related builder methods to differentiate between dwarf and msvc instructions 2022-01-24 13:45:34 +01:00
Michael Woerister
5e577f71a0 [debuginfo] Fix and unify handling of fat pointers in debuginfo: address review comments. 2022-01-24 13:42:41 +01:00
Michael Woerister
d253e6e473 [debuginfo] Fix and unify handling of fat pointers in debuginfo. 2022-01-24 13:41:32 +01:00
William D. Jones
19809ed76d Add preliminary support for inline assembly for msp430. 2022-01-22 23:42:46 -05:00
Matthias Krüger
ab19d4a515
Rollup merge of #93046 - est31:let_else, r=davidtwco
Use let_else in even more places

Followup of #89933, #91018, #91481.
2022-01-21 22:03:17 +01:00
Wesley Wiser
1a0278e1d1 Work around missing code coverage data causing llvm-cov failures
If we do not add code coverage instrumentation to the `Body` of a
function, then when we go to generate the function record for it, we
won't write any data and this later causes llvm-cov to fail when
processing data for the entire coverage report.

I've identified two main cases where we do not currently add code
coverage instrumentation to the `Body` of a function:

  1. If the function has a single `BasicBlock` and it ends with a
     `TerminatorKind::Unreachable`.

  2. If the function is created using a proc macro of some kind.

For case 1, this typically not important as this most often occurs as
the result of function definitions that take or return uninhabited
types. These kinds of functions, by definition, cannot even be called so
they logically should not be counted in code coverage statistics.

For case 2, I haven't looked into this very much but I've noticed while
testing this patch that (other than functions which are covered by case
1) the skipped function coverage debug message is occasionally triggered
in large crate graphs by functions generated from a proc macro. This may
have something to do with weird spans being generated by the proc macro
but this is just a guess.

I think it's reasonable to land this change since currently, we fail to
generate *any* results from llvm-cov when a function has no coverage
instrumentation applied to it. With this change, we get coverage data
for all functions other than the two cases discussed above.
2022-01-21 19:39:18 +00:00
Matthias Krüger
7889f96103
Rollup merge of #92425 - calebzulawski:simd-cast, r=workingjubilee
Improve SIMD casts

* Allows `simd_cast` intrinsic to take `usize` and `isize`
* Adds `simd_as` intrinsic, which is the same as `simd_cast` except for saturating float-to-int conversions (matching the behavior of `as`).

cc `@workingjubilee`
2022-01-18 22:00:45 +01:00
Matthias Krüger
dd621a4c5c
Rollup merge of #90782 - ricobbe:binutils-dlltool, r=michaelwoerister
Implement raw-dylib support for windows-gnu

Add support for `#[link(kind = "raw-dylib")]` on windows-gnu targets.  Work around binutils's linker's inability to read import libraries produced by LLVM by calling out to the binutils `dlltool` utility to create an import library from a temporary .DEF file; this approach is effectively a slightly refined version of `@mati865's` earlier attempt at this strategy in PR #88801.  (In particular, this attempt at this strategy adds support for `#[link_ordinal(...)]` as well.)

In support of #58713.
2022-01-18 22:00:42 +01:00
est31
b2dd1377c7 Use let_else in even more places 2022-01-18 21:37:57 +01:00
bors
9ad5d82f82 Auto merge of #92731 - bjorn3:asm_support_changes, r=nagisa
Avoid unnecessary monomorphization of inline asm related functions

This should reduce build time for codegen backends by avoiding duplicated monomorphization of certain inline asm related functions for each passed in closure type.
2022-01-18 14:32:52 +00:00
Caleb Zulawski
1d5bf6bc28
Update compiler/rustc_codegen_llvm/src/builder.rs
Co-authored-by: Jubilee <46493976+workingjubilee@users.noreply.github.com>
2022-01-17 22:29:12 -05:00
Matthias Krüger
7f02604f3d
Rollup merge of #92877 - Amanieu:remove_llvm_nounwind, r=Mark-Simulacrum
Remove LLVMRustMarkAllFunctionsNounwind

This was originally introduced in #10916 as a way to remove all landing
pads when performing LTO. However this is no longer necessary today
since rustc properly marks all functions and call-sites as nounwind
where appropriate.

In fact this is incorrect in the presence of `extern "C-unwind"` which
must create a landing pad when compiled with `-C panic=abort` so that
foreign exceptions are caught and properly turned into aborts.
2022-01-17 20:07:07 +01:00
bjorn3
991cbd1503 Use Symbol for target features in asm handling
This saves a couple of Symbol::intern calls
2022-01-17 18:06:27 +01:00
Michael Woerister
9a79ab6c0b rustc_codegen_llvm: Remove (almost) unused span parameter from many functions in metadata.rs. 2022-01-17 16:43:23 +01:00
bors
a34c079752 Auto merge of #92816 - tmiasko:rm-llvm-asm, r=Amanieu
Remove deprecated LLVM-style inline assembly

The `llvm_asm!` was deprecated back in #87590 1.56.0, with intention to remove
it once `asm!` was stabilized, which already happened in #91728 1.59.0. Now it
is time to remove `llvm_asm!` to avoid continued maintenance cost.

Closes #70173.
Closes #92794.
Closes #87612.
Closes #82065.

cc `@rust-lang/wg-inline-asm`

r? `@Amanieu`
2022-01-17 09:40:29 +00:00
Ellen
71bbb603f4 initial revert 2022-01-15 01:16:55 +00:00
Amanieu d'Antras
606d9c0c0e Remove LLVMRustMarkAllFunctionsNounwind
This was originally introduced in #10916 as a way to remove all landing
pads when performing LTO. However this is no longer necessary today
since rustc properly marks all functions and call-sites as nounwind
where appropriate.

In fact this is incorrect in the presence of `extern "C-unwind"` which
must create a landing pad when compiled with `-C panic=abort` so that
foreign exceptions are caught and properly turned into aborts.
2022-01-14 00:36:12 +00:00
Matthias Krüger
5e04f513cd
Rollup merge of #92142 - wesleywiser:fix_codecoverage_partitioning, r=tmandry
[code coverage] Fix missing dead code in modules that are never called

The issue here is that the logic used to determine which CGU to put the dead function stubs in doesn't handle cases where a module is never assigned to a CGU (which is what happens when all of the code in the module is dead).

The partitioning logic also caused issues in #85461 where inline functions were duplicated into multiple CGUs resulting in duplicate symbols.

This commit fixes the issue by removing the complex logic used to assign dead code stubs to CGUs and replaces it with a much simpler model: we pick one CGU to hold all the dead code stubs. We pick a CGU which has exported items which increases the likelihood the linker won't throw away our dead functions and we pick the smallest to minimize the impact on compilation times for crates with very large CGUs.

Fixes #91661
Fixes #86177
Fixes #85718
Fixes #79622

r? ```@tmandry```
cc ```@richkadel```

This PR is not urgent so please don't let it interrupt your holidays! 🎄 🎁
2022-01-13 08:11:20 +01:00
Richard Cobbe
0cf7fd1208 Call out to binutils' dlltool for raw-dylib on windows-gnu platforms. 2022-01-12 10:25:35 -08:00
Tomasz Miąsko
000b36c505 Remove deprecated LLVM-style inline assembly 2022-01-12 18:51:31 +01:00
bors
72e74d7b9c Auto merge of #92533 - Aaron1011:variant-symbol, r=petrochenkov
Store a `Symbol` instead of an `Ident` in `VariantDef`/`FieldDef`

The field is also renamed from `ident` to `name`. In most cases,
we don't actually need the `Span`. A new `ident` method is added
to `VariantDef` and `FieldDef`, which constructs the full `Ident`
using `tcx.def_ident_span()`. This method is used in the cases
where we actually need an `Ident`.

This makes incremental compilation properly track changes
to the `Span`, without all of the invalidations caused by storing
a `Span` directly via an `Ident`.
2022-01-11 21:02:01 +00:00
Aaron Hill
450ef8613c
Store a Symbol instead of an Ident in VariantDef/FieldDef
The field is also renamed from `ident` to `name. In most cases,
we don't actually need the `Span`. A new `ident` method is added
to `VariantDef` and `FieldDef`, which constructs the full `Ident`
using `tcx.def_ident_span()`. This method is used in the cases
where we actually need an `Ident`.

This makes incremental compilation properly track changes
to the `Span`, without all of the invalidations caused by storing
a `Span` directly via an `Ident`.
2022-01-11 10:16:22 -05:00
Lucas Kent
08829853d3 eplace usages of vec![].into_iter with [].into_iter 2022-01-09 14:09:25 +11:00
Eric Huss
5cddd24daa
Rollup merge of #92375 - wesleywiser:consolidate_debuginfo_msvc_check, r=michaelwoerister
Consolidate checking for msvc when generating debuginfo

If the target we're generating code for is msvc, then we do two main
things differently: we generate type names in a C++ style instead of a
Rust style and we generate debuginfo for enums differently.

I've refactored the code so that there is one function
(`cpp_like_debuginfo`) which determines if we should use the C++ style
of naming types and other debuginfo generation or the regular Rust one.

r? ``@michaelwoerister``

This PR is not urgent so please don't let it interrupt your holidays! 🎄 🎁
2022-01-07 20:20:58 -08:00
Wesley Wiser
836addcbc4 Consolidate checking for msvc when generating debuginfo
If the target we're generating code for is msvc, then we do two main
things differently: we generate type names in a C++ style instead of a
Rust style and we generate debuginfo for enums differently.

I've refactored the code so that there is one function
(`cpp_like_debuginfo`) which determines if we should use the C++ style
of naming types and other debuginfo generation or the regular Rust one.
2022-01-07 12:36:09 -05:00
David Wood
08ed338f56 sess/cg: re-introduce split dwarf kind
In #79570, `-Z split-dwarf-kind={none,single,split}` was replaced by `-C
split-debuginfo={off,packed,unpacked}`. `-C split-debuginfo`'s packed
and unpacked aren't exact parallels to single and split, respectively.

On Unix, `-C split-debuginfo=packed` will put debuginfo into object
files and package debuginfo into a DWARF package file (`.dwp`) and
`-C split-debuginfo=unpacked` will put debuginfo into dwarf object files
and won't package it.

In the initial implementation of Split DWARF, split mode wrote sections
which did not require relocation into a DWARF object (`.dwo`) file which
was ignored by the linker and then packaged those DWARF objects into
DWARF packages (`.dwp`). In single mode, sections which did not require
relocation were written into object files but ignored by the linker and
were not packaged. However, both split and single modes could be
packaged or not, the primary difference in behaviour was where the
debuginfo sections that did not require link-time relocation were
written (in a DWARF object or the object file).

This commit re-introduces a `-Z split-dwarf-kind` flag, which can be
used to pick between split and single modes when `-C split-debuginfo` is
used to enable Split DWARF (either packed or unpacked).

Signed-off-by: David Wood <david.wood@huawei.com>
2022-01-06 09:32:42 +00:00
Caleb Zulawski
8fae33d9b2 Add simd_as intrinsic 2022-01-04 01:45:41 +00:00
Caleb Zulawski
d32ca64692 Allow isize/usize in simd_cast 2022-01-04 01:44:26 +00:00
Krasimir Georgiev
4ce56b414d RustWrapper: adapt for an LLVM API change
No functional changes intended.

The LLVM commit
ec501f15a8
removed the signed version of `createExpression`. This adapts the Rust
LLVM wrappers accordingly.
2022-01-03 11:25:33 +01:00
Josh Triplett
34106f8935 Stabilize -Z instrument-coverage as -C instrument-coverage
Continue supporting -Z instrument-coverage for compatibility for now,
but show a deprecation warning for it.

Update uses and documentation to use the -C option.

Move the documentation from the unstable book to stable rustc
documentation.
2022-01-01 15:57:35 -08:00
bors
4f49627c6f Auto merge of #92419 - erikdesjardins:coldland, r=nagisa
Mark drop calls in landing pads `cold` instead of `noinline`

Now that deferred inlining has been disabled in LLVM (#92110), this shouldn't cause catastrophic size blowup.

I confirmed that the test cases from https://github.com/rust-lang/rust/issues/41696#issuecomment-298696944 still compile quickly (<1s) after this change. ~Although note that I wasn't able to reproduce the original issue using a recent rustc/llvm with deferred inlining enabled, so those tests may no longer be representative. I was also unable to create a modified test case that reproduced the original issue.~ (edit: I reproduced it on CI by accident--the first commit timed out on the LLVM 12 builder, because I forgot to make it conditional on LLVM version)

r? `@nagisa`
cc `@arielb1` (this effectively reverts #42771 "mark calls in the unwind path as !noinline")
cc `@RalfJung` (fixes #46515)

edit: also fixes #87055
2022-01-01 13:28:13 +00:00
Erik Desjardins
e4463b2453 keep noinline for system llvm < 14 2021-12-30 00:15:51 -05:00
bors
1b3a5f29dd Auto merge of #91125 - eskarn:llvm-passes-plugin-support, r=nagisa
Allow loading LLVM plugins with both legacy and new pass manager

Opening a draft PR to get feedback and start discussion on this feature. There is already a codegen option `passes` which allow giving a list of LLVM pass names, however we currently can't use a LLVM pass plugin (as described here : https://llvm.org/docs/WritingAnLLVMPass.html), the only available passes are the LLVM built-in ones.

The proposed modification would be to add another codegen option `pass-plugins`, which can be set with a list of paths to shared library files. These libraries are loaded using the LLVM function `PassPlugin::Load`, which calls the expected symbol `lvmGetPassPluginInfo`, and register the pipeline parsing and optimization callbacks.

An example usage with a single plugin and 3 passes would look like this in the `.cargo/config`:

```toml
rustflags = [
    "-C", "pass-plugins=/tmp/libLLVMPassPlugin",
    "-C", "passes=pass1 pass2 pass3",
]
```
This would give the same functionality as the opt LLVM tool directly integrated in rust build system.

Additionally, we can also not specify the `passes` option, and use a plugin which inserts passes in the optimization pipeline, as one could do using clang.
2021-12-30 02:53:09 +00:00
bors
d331cb710f Auto merge of #88354 - Jmc18134:hint-space-pauth-opt, r=nagisa
Add codegen option for branch protection and pointer authentication on AArch64

The branch-protection codegen option enables the use of hint-space pointer
authentication code for AArch64 targets.
2021-12-29 22:35:11 +00:00
Erik Desjardins
2b662217e7 Mark drop calls in landing pads cold instead of noinline
Now that deferred inlining has been disabled in LLVM,
this shouldn't cause catastrophic size blowup.
2021-12-29 15:47:49 -05:00