summary refs log tree commit diff
path: root/compiler/rustc_codegen_ssa/src
AgeCommit message (Collapse)AuthorLines
2022-02-18Rollup merge of #93634 - matthiaskrgr:clippy_complexity_jan_2022, r=oli-obkMatthias Krüger-1/+1
compiler: clippy::complexity fixes useless_format map_flatten useless_conversion needless_bool filter_next clone_on_copy needless_option_as_deref
2022-02-17Rollup merge of #94011 - est31:let_else, r=lcnrMatthias Krüger-16/+13
Even more let_else adoptions Continuation of #89933, #91018, #91481, #93046, #93590.
2022-02-16Adopt let_else in even more placesest31-16/+13
2022-02-15Overhaul `Const`.Nicholas Nethercote-12/+12
Specifically, rename the `Const` struct as `ConstS` and re-introduce `Const` as this: ``` pub struct Const<'tcx>(&'tcx Interned<ConstS>); ``` This now matches `Ty` and `Predicate` more closely, including using pointer-based `eq` and `hash`. Notable changes: - `mk_const` now takes a `ConstS`. - `Const` was copy, despite being 48 bytes. Now `ConstS` is not, so need a we need separate arena for it, because we can't use the `Dropless` one any more. - Many `&'tcx Const<'tcx>`/`&Const<'tcx>` to `Const<'tcx>` changes - Many `ct.ty` to `ct.ty()` and `ct.val` to `ct.val()` changes. - Lots of tedious sigil fiddling.
2022-02-15Overhaul `TyS` and `Ty`.Nicholas Nethercote-1/+1
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-11Rollup merge of #93782 - adamgemmell:dev/adagem01/split-pauth, r=AmanieuMatthias Krüger-2/+13
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-10Unconditionally update symbolsbjorn3-7/+0
All paths to an ArchiveBuilder::build call update_symbols first.
2022-02-10Remove unnecessary update_symbols callbjorn3-11/+5
For cg_llvm update_symbols merely sets a flag, so changing the position or removing an additional call doesn't have any effect.
2022-02-10Split PAuth target featureAdam Gemmell-2/+13
2022-02-10Auto merge of #93511 - cjgillot:query-copy, r=oli-obkbors-4/+4
Ensure that queries only return Copy types. This should pervent the perf footgun of returning a result with an expensive `Clone` impl (like a `Vec` of a hash map). I went for the stupid solution of allocating on an arena everything that was not `Copy`. Some query results could be made Copy easily, but I did not really investigate.
2022-02-09Rollup merge of #93503 - ↵Matthias Krüger-2/+19
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-09Ensure that queries only return Copy types.Camille GILLOT-4/+4
2022-02-08debuginfo: Bring back DW_AT_containing_type for vtables -- address review ↵Michael Woerister-1/+1
comments
2022-02-04Rollup merge of #90132 - joshtriplett:stabilize-instrument-coverage, ↵Matthias Krüger-4/+4
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-03compiler: clippy::complexity fixesMatthias Krüger-1/+1
useless_format map_flatten useless_conversion needless_bool filter_next clone_on_copy needless_option_as_deref
2022-02-03debuginfo: Bring back DW_AT_containing_type for vtables after it has ↵Michael Woerister-2/+19
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-02Auto merge of #93154 - ↵bors-36/+74
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-01debuginfo: Make sure that type names for closure and generator environments ↵Michael Woerister-36/+74
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-01add a rustc::query_stability lintlcnr-0/+1
2022-01-30Rollup merge of #93192 - theidexisted:patch-1, r=wesleywiserEric Huss-1/+1
Add VS 2022 into error message
2022-01-29Rollup merge of #92274 - woppopo:const_deallocate, r=oli-obkMatthias Krüger-0/+10
Add `intrinsics::const_deallocate` Tracking issue: #79597 Related: #91884 This allows deallocation of a memory allocated by `intrinsics::const_allocate`. At the moment, this can be only used to reduce memory usage, but in the future this may be useful to detect memory leaks (If an allocated memory remains after evaluation, raise an error...?).
2022-01-26`const_deallocate`: Don't deallocate memory allocated in an another const. ↵woppopo-0/+10
Does nothing at runtime. `const_allocate`: Returns a null pointer at runtime.
2022-01-24Merge landing_pad and set_cleanup into cleanup_landing_padbjorn3-9/+2
2022-01-24Merge add_handler into catch_switchbjorn3-4/+2
Some codegen backends may require all handlers to be immediately known
2022-01-24Remove unused return values from resume and cleanup_retbjorn3-6/+2
Given that these instructions are diverging, not every codegen backend may be able to produce a return value for them.
2022-01-24Reorder unwinding related builder methods to differentiate between dwarf and ↵bjorn3-1/+5
msvc instructions
2022-01-22Rollup merge of #92828 - Amanieu:unwind-abort, r=dtolnayMatthias Krüger-4/+23
Print a helpful message if unwinding aborts when it reaches a nounwind function This is implemented by routing `TerminatorKind::Abort` back through the panic handler, but with a special flag in the `PanicInfo` which indicates that the panic handler should *not* attempt to unwind the stack and should instead abort immediately. This is useful for the planned change in https://github.com/rust-lang/lang-team/issues/97 which would make `Drop` impls `nounwind` by default. ### Code ```rust #![feature(c_unwind)] fn panic() { panic!() } extern "C" fn nounwind() { panic(); } fn main() { nounwind(); } ``` ### Before ``` $ ./test thread 'main' panicked at 'explicit panic', test.rs:4:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace Illegal instruction (core dumped) ``` ### After ``` $ ./test thread 'main' panicked at 'explicit panic', test.rs:4:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace thread 'main' panicked at 'panic in a function that cannot unwind', test.rs:7:1 stack backtrace: 0: 0x556f8f86ec9b - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hdccefe11a6ac4396 1: 0x556f8f88ac6c - core::fmt::write::he152b28c41466ebb 2: 0x556f8f85d6e2 - std::io::Write::write_fmt::h0c261480ab86f3d3 3: 0x556f8f8654fa - std::panicking::default_hook::{{closure}}::h5d7346f3ff7f6c1b 4: 0x556f8f86512b - std::panicking::default_hook::hd85803a1376cac7f 5: 0x556f8f865a91 - std::panicking::rust_panic_with_hook::h4dc1c5a3036257ac 6: 0x556f8f86f079 - std::panicking::begin_panic_handler::{{closure}}::hdda1d83c7a9d34d2 7: 0x556f8f86edc4 - std::sys_common::backtrace::__rust_end_short_backtrace::h5b70ed0cce71e95f 8: 0x556f8f865592 - rust_begin_unwind 9: 0x556f8f85a764 - core::panicking::panic_no_unwind::h2606ab3d78c87899 10: 0x556f8f85b910 - test::nounwind::hade6c7ee65050347 11: 0x556f8f85b936 - test::main::hdc6e02cb36343525 12: 0x556f8f85b7e3 - core::ops::function::FnOnce::call_once::h4d02663acfc7597f 13: 0x556f8f85b739 - std::sys_common::backtrace::__rust_begin_short_backtrace::h071d40135adb0101 14: 0x556f8f85c149 - std::rt::lang_start::{{closure}}::h70dbfbf38b685e93 15: 0x556f8f85c791 - std::rt::lang_start_internal::h798f1c0268d525aa 16: 0x556f8f85c131 - std::rt::lang_start::h476a7ee0a0bb663f 17: 0x556f8f85b963 - main 18: 0x7f64c0822b25 - __libc_start_main 19: 0x556f8f85ae8e - _start 20: 0x0 - <unknown> thread panicked while panicking. aborting. Aborted (core dumped) ```
2022-01-22Add VS 2022 into error messagetheidexisted-1/+1
2022-01-21adapt L4Bender implementationBenjamin Lamowski-80/+62
- Fix style errors. - L4-bender does not yet support dynamic linking. - Stack unwinding is not yet supported for x86_64-unknown-l4re-uclibc. For now, just abort on panics. - Use GNU-style linker options where possible. As suggested by review: - Use standard GNU-style ld syntax for relro flags. - Use standard GNU-style optimization flags and logic. - Use standard GNU-style ld syntax for --subsystem. - Don't read environment variables in L4Bender linker. Thanks to CARGO_ENCODED_RUSTFLAGS introduced in #9601, l4-bender's arguments can now be passed from the L4Re build system without resorting to custom parsing of environment variables.
2022-01-21Add L4Bender as linker variantSebastian Humenda-1/+172
2022-01-20Rollup merge of #91606 - joshtriplett:stabilize-print-link-args, r=pnkfelixMatthias Krüger-1/+1
Stabilize `-Z print-link-args` as `--print link-args` We have stable options for adding linker arguments; we should have a stable option to help debug linker arguments. Add documentation for the new option. In the documentation, make it clear that the *exact* format of the output is not a stable guarantee.
2022-01-19Rollup merge of #91278 - SparrowLii:place, r=spastorinoMatthias Krüger-76/+67
Use iterator instead of recursion in `codegen_place` This PR fixes the FIXME in `codegen_place` about using iterator instead of recursion when processing the `projection` field in `mir::PlaceRef`. At the same time, it also reduces the right drift.
2022-01-18Rollup merge of #92425 - calebzulawski:simd-cast, r=workingjubileeMatthias Krüger-149/+181
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-18Auto merge of #87648 - JulianKnodt:const_eq_constrain, r=oli-obkbors-2/+3
allow eq constraints on associated constants Updates #70256 (cc `@varkor,` `@Centril)`
2022-01-18Improve documentation of splatted constantsCaleb Zulawski-26/+28
2022-01-17Add term to ExistentialProjectionkadmin-2/+3
Also prevent ICE when adding a const in associated const equality.
2022-01-17Rollup merge of #92877 - Amanieu:remove_llvm_nounwind, r=Mark-SimulacrumMatthias Krüger-3/+1
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-17Auto merge of #92816 - tmiasko:rm-llvm-asm, r=Amanieubors-58/+0
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-17Change TerminatorKind::Abort to call the panic handler instead ofAmanieu d'Antras-4/+23
aborting immediately. The panic handler is called with a special flag which forces it to abort after calling the panic hook.
2022-01-16Auto merge of #92805 - BoxyUwU:revert-lazy-anon-const-substs, r=lcnrbors-2/+2
partially revertish `lazily "compute" anon const default substs` reverts #87280 except for some of the changes around `ty::Unevaluated` having a visitor and a generic for promoted why revert: <https://github.com/rust-lang/rust/pull/92805#issuecomment-1010736049> r? `@lcnr`
2022-01-15Reduce use of local_def_id_to_hir_id.Camille GILLOT-1/+1
2022-01-15Rollup merge of #92873 - eholk:async-symbol-names, r=tmandryMatthias Krüger-2/+8
Generate more precise generator names Currently all generators are named with a `generator$N` suffix, regardless of where they come from. This means an `async fn` shows up as a generator in stack traces, which can be surprising to async programmers since they should not need to know that async functions are implementated using generators. This change generators a different name depending on the generator kind, allowing us to tell whether the generator is the result of an async block, an async closure, an async fn, or a plain generator. r? `@tmandry` cc `@michaelwoerister` `@wesleywiser` `@dpaoliello`
2022-01-15initial revertEllen-2/+2
2022-01-14Remove LLVMRustMarkAllFunctionsNounwindAmanieu d'Antras-3/+1
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-13Generate more precise generator namesEric Holk-2/+8
Currently all generators are named with a `generator$N` suffix, regardless of where they come from. This means an `async fn` shows up as a generator in stack traces, which can be surprising to async programmers since they should not need to know that async functions are implementated using generators. This change generators a different name depending on the generator kind, allowing us to tell whether the generator is the result of an async block, an async closure, an async fn, or a plain generator.
2022-01-13Rollup merge of #90001 - Fearyncess:master, r=alexcrichtonMatthias Krüger-3/+15
Make rlib metadata strip works with MIPSr6 architecture Because MIPSr6 has many differences with previous MIPSr2 arch, the previous rlib metadata stripping code in `rustc_codegen_ssa` is only for MIPSr2/r3/r5 (which share the same elf e_flags). This commit fixed this problem. It makes `rustc_codegen_ssa` happy when compiling rustc for MIPSr6 target or hosts. e_flags REF: https://github.com/llvm/llvm-project/blob/e356027016c6365b3d8924f54c33e2c63d931492/llvm/include/llvm/BinaryFormat/ELF.h#L562
2022-01-12Remove deprecated LLVM-style inline assemblyTomasz Miąsko-58/+0
2022-01-11Store a `Symbol` instead of an `Ident` in `VariantDef`/`FieldDef`Aaron Hill-2/+2
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-09Stabilize -Z print-link-args as --print link-argsJosh Triplett-1/+1
We have stable options for adding linker arguments; we should have a stable option to help debug linker arguments.
2022-01-07Rollup merge of #92375 - wesleywiser:consolidate_debuginfo_msvc_check, ↵Eric Huss-50/+51
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! 🎄 🎁