about summary refs log tree commit diff
path: root/compiler/rustc_codegen_ssa
AgeCommit message (Collapse)AuthorLines
2021-07-19Auto merge of #87153 - ↵bors-71/+140
michaelwoerister:debuginfo-names-dyn-trait-projection-bounds, r=wesleywiser [debuginfo] Emit associated type bindings in trait object type names. This PR updates debuginfo type name generation for trait objects to include associated type bindings and auto trait bounds -- so that, for example, the debuginfo type name of `&dyn Iterator<Item=Foo>` and `&dyn Iterator<Item=Bar>` don't both map to just `&dyn Iterator` anymore. The following table shows examples of debuginfo type names before and after the PR: | type | before | after | |------|---------|-------| | `&dyn Iterator<Item=u32>>` | `&dyn Iterator` | `&dyn Iterator<Item=u32>` | | `&(dyn Iterator<Item=u32>> + Sync)` | `&dyn Iterator` | `&(dyn Iterator<Item=u32> + Sync)` | | `&(dyn SomeTrait<bool, i8, Bar=u32>> + Send)` | `&dyn SomeTrait<bool, i8>` | `&(dyn SomeTrait<bool, i8, Bar=u32>> + Send)` | For targets that need C++-like type names, we use `assoc$<Item,u32>` instead of `Item=u32`: | type | before | after | |------|---------|-------| | `&dyn Iterator<Item=u32>>` | `ref$<dyn$<Iterator> >` | `ref$<dyn$<Iterator<assoc$<Item,u32> > > >` | | `&(dyn Iterator<Item=u32>> + Sync)` | `ref$<dyn$<Iterator> >` | `ref$<dyn$<Iterator<assoc$<Item,u32> >,Sync> >` | | `&(dyn SomeTrait<bool, i8, Bar=u32>> + Send)` | `ref$<dyn$<SomeTrait<bool, i8> > >` | `ref$<dyn$<SomeTrait<bool,i8,assoc$<Bar,u32> > >,Send> >` | The PR also adds self-profiling measurements for debuginfo type name generation (re. https://github.com/rust-lang/rust/issues/86431). It looks like the compiler spends up to 0.5% of its time in that task, so the potential for optimizing it via caching seems limited. However, the perf run also shows [the biggest regression](https://perf.rust-lang.org/detailed-query.html?commit=585e91c718b0b2c5319e1fffd0ff1e62aaf7ccc2&base_commit=b9197978a90be6f7570741eabe2da175fec75375&benchmark=tokio-webpush-simple-debug&run_name=incr-unchanged) in a test case that does not even invoke the code in question. This suggests that the length of the names we generate here can affect performance by influencing how much data the linker has to copy around. Fixes https://github.com/rust-lang/rust/issues/86134.
2021-07-18Auto merge of #87004 - JamieCunliffe:pgo-gc-sections, r=Mark-Simulacrumbors-1/+6
Don't use gc-sections with profile-generate. When building with profile-generate don't call gc_sections as this can can sometimes strip out profile data. This missing information in the prof files can then result in missing functions when using the profile information. #78226 r? `@Mark-Simulacrum`
2021-07-18Rollup merge of #87092 - ricobbe:fix-raw-dylib-multiple-definitions, ↵Yuki Okushi-65/+49
r=petrochenkov Remove nondeterminism in multiple-definitions test Compare all fields in `DllImport` when sorting to avoid nondeterminism in the error for multiple inconsistent definitions of an extern function. Restore the multiple-definitions test. Resolves #87084.
2021-07-17Auto merge of #87123 - RalfJung:miri-provenance-overhaul, r=oli-obkbors-4/+4
CTFE/Miri engine Pointer type overhaul This fixes the long-standing problem that we are using `Scalar` as a type to represent pointers that might be integer values (since they point to a ZST). The main problem is that with int-to-ptr casts, there are multiple ways to represent the same pointer as a `Scalar` and it is unclear if "normalization" (i.e., the cast) already happened or not. This leads to ugly methods like `force_mplace_ptr` and `force_op_ptr`. Another problem this solves is that in Miri, it would make a lot more sense to have the `Pointer::offset` field represent the full absolute address (instead of being relative to the `AllocId`). This means we can do ptr-to-int casts without access to any machine state, and it means that the overflow checks on pointer arithmetic are (finally!) accurate. To solve this, the `Pointer` type is made entirely parametric over the provenance, so that we can use `Pointer<AllocId>` inside `Scalar` but use `Pointer<Option<AllocId>>` when accessing memory (where `None` represents the case that we could not figure out an `AllocId`; in that case the `offset` is an absolute address). Moreover, the `Provenance` trait determines if a pointer with a given provenance can be cast to an integer by simply dropping the provenance. I hope this can be read commit-by-commit, but the first commit does the bulk of the work. It introduces some FIXMEs that are resolved later. Fixes https://github.com/rust-lang/miri/issues/841 Miri PR: https://github.com/rust-lang/miri/pull/1851 r? `@oli-obk`
2021-07-16Consider all fields when comparing DllImports, to remove nondetermininsm in ↵Richard Cobbe-65/+49
multiple-definitions test
2021-07-15Add self-profiling to debuginfo name generationMichael Woerister-1/+4
2021-07-15[debuginfo] Make use of spaces and separators in debuginfo names more uniform.Michael Woerister-48/+67
2021-07-15[debuginfo] Emit associated type bindings in trait object type names.Michael Woerister-37/+84
2021-07-14consistently treat None-tagged pointers as ints; get rid of some deprecated ↵Ralf Jung-4/+4
Scalar methods
2021-07-14Auto merge of #87082 - michaelwoerister:const-in-debuginfo-type-names-fix, ↵bors-18/+63
r=oli-obk,wesleywiser Handle non-integer const generic parameters in debuginfo type names. This PR fixes an ICE introduced by https://github.com/rust-lang/rust/pull/85269 which started emitting const generic arguments for debuginfo names but did not cover the case where such an argument could not be evaluated to a flat string of bits. The fix implemented in this PR is very basic: If `try_eval_bits()` fails for the constant in question, we fall back to generating a stable hash of the constant and emit that instead. This way we get a (virtually) unique name and side step the problem of generating a string representation of a potentially complex value. The downside is that the generated name will be rather opaque. E.g. the regression test adds a function `const_generic_fn_non_int<()>` which is then rendered as `const_generic_fn_non_int<{CONST#fe3cfa0214ac55c7}>`. I think it's an open question how to deal with this more gracefully. I'd be interested in ideas on how to do this better. r? `@wesleywiser` cc `@dpaoliello` (do you see any problems with this approach?) cc `@Mark-Simulacrum` & `@nagisa` (who I've seen comment on debuginfo issues recently -- anyone else?) Fixes https://github.com/rust-lang/rust/issues/86893
2021-07-14Handle non-integer const generic parameters in debuginfo type names.Michael Woerister-18/+63
2021-07-14Keep metadata when using gc-sections with profile-generate.Jamie Cunliffe-1/+6
When building with profile-generate request that metadata is kept during the gc_sections call, as this can sometimes strip out profile data. This missing information in the prof files can then result in missing functions when using the profile information.
2021-07-13Upgrade `cc` crate to 1.0.69Yuki Okushi-1/+1
2021-07-10Auto merge of #86873 - nikic:opaque-ptrs, r=nagisabors-31/+36
Improve opaque pointers support Opaque pointers are coming, and rustc is not ready. This adds partial support by passing an explicit load type to LLVM. Two issues I've encountered: * The necessary type was not available at the point where non-temporal copies were generated. I've pushed the code for that upwards out of the memcpy implementation and moved the position of a cast to make do with the types we have available. (I'm not sure that cast is needed at all, but have retained it in the interest of conservativeness.) * The `PlaceRef::project_deref()` function used during debuginfo generation seems to be buggy in some way -- though I haven't figured out specifically what it does wrong. Replacing it with `load_operand().deref()` did the trick, but I don't really know what I'm doing here.
2021-07-09Don't access pointer element type for nontemporal storeNikita Popov-5/+4
Simply shift the bitcast from the store to the load, so that we can use the destination type. I'm not sure the bitcast is really necessary, but keeping it for now.
2021-07-09Fix project_deref() implementationNikita Popov-13/+1
I'm not really sure what is wrong here, but I was getting load type mismatches in the debuginfo code (which is the only place using this function). Replacing the project_deref() implementation with a generic load_operand + deref did the trick.
2021-07-09Pass type when creating loadNikita Popov-13/+26
This makes load generation compatible with opaque pointers. The generation of nontemporal copies still accesses the pointer element type, as fixing this requires more movement.
2021-07-09Pass type when creating atomic loadNikita Popov-6/+11
Instead of determining it from the pointer type, explicitly pass the type to load.
2021-07-09Add support for raw-dylib with stdcall, fastcall functions on ↵Richard Cobbe-25/+44
i686-pc-windows-msvc.
2021-07-07Auto merge of #86105 - bjorn3:link_info_refactor, r=petrochenkovbors-2/+18
Refactor the generation of the metadata for linking
2021-07-07Remove a sorting operation from used_cratesbjorn3-2/+18
2021-07-06Auto merge of #86911 - bjorn3:crate_info_refactor, r=petrochenkovbors-187/+162
Refactor linker code This merges `LinkerInfo` into `CrateInfo` as there is no reason to keep them separate. `LinkerInfo::to_linker` is merged into `get_linker` as both have different logic for each linker type and `to_linker` is directly called after `get_linker`. Also contains a couple of small cleanups. See the individual commits for all changes.
2021-07-06Auto merge of #86636 - wesleywiser:misc_enum_improvements, r=michaelwoeristerbors-10/+14
[msvc] Consistently show active variant and fix visualization for single variant enums Prior to this change, there were a few cases where inspecting an enum in either WinDbg or Visual Studio would not show the active variant name. After these changes, we now consistently show the active variant name as `[variant]` in the debugger. We also didn't handle single variant enums very well. That is now also resolved. Before: ![image](https://user-images.githubusercontent.com/831192/123480097-dc8b5f00-d5cf-11eb-93a8-9fc05a97029b.png) After: ![image](https://user-images.githubusercontent.com/831192/123479966-aa79fd00-d5cf-11eb-955e-9798616a8829.png) r? `@michaelwoerister`
2021-07-06Fold LinkerInfo into CrateInfobjorn3-86/+48
2021-07-06Don't store the full LinkerInfo inside Linker implsbjorn3-27/+44
2021-07-06Merge LinkerInfo::to_linker into get_linkerbjorn3-44/+40
2021-07-06Move get_linker to linker.rsbjorn3-93/+96
2021-07-06Don't pass local_crate_name to link_binary separatelybjorn3-2/+6
It is already part of CodegenResults
2021-07-06Remove unused panic_runtime field from CrateInfobjorn3-5/+0
2021-07-06Move LinkerInfo into CrateInfobjorn3-12/+10
2021-07-05Deduplicate info.used_crate_source indexingbjorn3-2/+3
2021-07-05Remove LibSourcebjorn3-39/+42
The information is stored in used_crate_source too anyway
2021-07-02Refactor `msvc_enum_fallbck()` a bitWesley Wiser-19/+12
2021-07-02Show the variant name for univariant enumsWesley Wiser-0/+11
Previously, only the fields would be displayed with no indication of the variant name. If you already knew the enum was univariant, this was ok but if the enum was univariant because of layout, for example, a `Result<T, !>` then it could be very confusing which variant was the active one.
2021-07-02Auto merge of #85269 - dpaoliello:dpaoliello/DebugSymbols, r=michaelwoeristerbors-88/+272
Improve debug symbol names to avoid ambiguity and work better with MSVC's debugger There are several cases where names of types and functions in the debug info are either ambiguous, or not helpful, such as including ambiguous placeholders (e.g., `{{impl}}`, `{{closure}}` or `dyn _'`) or dropping qualifications (e.g., for dynamic types). Instead, each debug symbol name should be unique and useful: * Include disambiguators for anonymous `DefPathDataName` (closures and generators), and unify their formatting when used as a path-qualifier vs item being qualified. * Qualify the principal trait for dynamic types. * If there is no principal trait for a dynamic type, emit all other traits instead. * Respect the `qualified` argument when emitting ref and pointer types. * For implementations, emit the disambiguator. * Print const generics when emitting generic parameters or arguments. Additionally, when targeting MSVC, its debugger treats many command arguments as C++ expressions, even when the argument is defined to be a symbol name. As such names in the debug info need to be more C++-like to be parsed correctly: * Avoid characters with special meaning (`#`, `[`, `"`, `+`). * Never start a name with `<` or `{` as this is treated as an operator. * `>>` is always treated as a right-shift, even when parsing generic arguments (so add a space to avoid this). * Emit function declarations using C/C++ style syntax (e.g., leading return type). * Emit arrays as a synthetic `array$<type, size>` type. * Include a `$` in all synthetic types as this is a legal character for C++, but not Rust (thus we avoid collisions with user types).
2021-07-01Auto merge of #86749 - bjorn3:link_info_refactor_part1, r=petrochenkovbors-3/+3
Rename all_crate_nums query to crates and remove useless wrapper Split out of https://github.com/rust-lang/rust/pull/86105 r? `@petrochenkov`
2021-07-01Update cdb tests for expected outputWesley Wiser-2/+12
Also an fix issue with tuple type names where we can't cast to them in natvis (required by the visualizer for `HashMap`) because of peculiarities with the natvis expression evaluator.
2021-07-01Rename all_crate_nums query to crates and remove useless wrapperbjorn3-3/+3
2021-07-01Rollup merge of #86652 - nagisa:nagisa/non-leaf-fp, r=petrochenkovGuillaume Gomez-2/+2
Add support for leaf function frame pointer elimination This PR adds ability for the target specifications to specify frame pointer emission type that's not just “always” or “whatever cg decides”. In particular there's a new mode that allows omission of the frame pointer for leaf functions (those that don't call any other functions). We then set this new mode for Aarch64-based Apple targets. Fixes #86196
2021-07-01Rollup merge of #86558 - Smittyvb:link-error-sugg, r=petrochenkovGuillaume Gomez-5/+14
Add suggestions for "undefined reference" link errors This adds a suggestion for "undefined reference to ..." linking errors to install or specify the location to an external library. Since there is no defined error format for linkers, we just check if there was a failure and if that failure contains the string `undefined reference to`. This also makes it impossible to test this, since the output depends on the system linker. The output now looks like: ``` error: linking with `cc` failed: exit status: 1 | = note: "cc" "-m64" "linking_failure.linking_failure.7rcbfp3g-cgu.0.rcgu.o" "linking_failure.linking_failure.7rcbfp3g-cgu.1.rcgu.o" "linking_failure.linking_failure.7rcbfp3g-cgu.2.rcgu.o" "linking_failure.linking_failure.7rcbfp3g-cgu.3.rcgu.o" "linking_failure.linking_failure.7rcbfp3g-cgu.4.rcgu.o" "linking_failure.linking_failure.7rcbfp3g-cgu.5.rcgu.o" "linking_failure.linking_failure.7rcbfp3g-cgu.6.rcgu.o" "linking_failure.linking_failure.7rcbfp3g-cgu.7.rcgu.o" "linking_failure.linking_failure.7rcbfp3g-cgu.8.rcgu.o" "linking_failure.53u64zklswtfazes.rcgu.o" "-Wl,--as-needed" "-L" "/home/smit/rustc-dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,--start-group" "-Wl,-Bstatic" "/home/smit/rustc-dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-01ce3ba5c629d02f.rlib" "/home/smit/rustc-dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-f1f2102409186354.rlib" "/home/smit/rustc-dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/libminiz_oxide-1e8b6b56a999f838.rlib" "/home/smit/rustc-dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/libadler-d0e93eb4e14f1d19.rlib" "/home/smit/rustc-dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/libobject-1d7e39d75d082b43.rlib" "/home/smit/rustc-dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/libaddr2line-ade42e945045b261.rlib" "/home/smit/rustc-dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/libgimli-1a65064fccf4ebc1.rlib" "/home/smit/rustc-dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd_detect-4d699c310fdfe72d.rlib" "/home/smit/rustc-dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_demangle-1cafa68a696ec800.rlib" "/home/smit/rustc-dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/libhashbrown-e9f1c8c4dab2f046.rlib" "/home/smit/rustc-dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_alloc-ecc1a743be25c7f7.rlib" "/home/smit/rustc-dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-e074031c4b66b6b6.rlib" "/home/smit/rustc-dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcfg_if-9aa6ed9f1d3bfd53.rlib" "/home/smit/rustc-dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-7862bf96c2250ca0.rlib" "/home/smit/rustc-dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-f02ce0dc7895b5fd.rlib" "/home/smit/rustc-dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_core-3af9c60917570521.rlib" "/home/smit/rustc-dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-ca16fc7bb3645684.rlib" "-Wl,--end-group" "/home/smit/rustc-dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-d8e1a5b7299604cc.rlib" "-Wl,-Bdynamic" "-lgcc_s" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl" "-lc" "-Wl,--eh-frame-hdr" "-Wl,-znoexecstack" "-L" "/home/smit/rustc-dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-o" "linking_failure" "-Wl,--gc-sections" "-pie" "-Wl,-zrelro" "-Wl,-znow" "-nodefaultlibs" = note: /usr/bin/ld: linking_failure.linking_failure.7rcbfp3g-cgu.3.rcgu.o: in function `linking_failure::main': linking_failure.7rcbfp3g-cgu.3:(.text._ZN15linking_failure4main17h52b6e3052e444479E+0x3): undefined reference to `doesnt_exist_thiwthwfyl' clang: error: linker command failed with exit code 1 (use -v to see invocation) = help: some `extern` functions couldn't be found; you may need to install or specify the path to some dependencies = note: use the -L flag to specify the library lookup path = note: use the cargo:rustc-link-search directive to specify the library lookup path with Cargo (see https://doc.rust-lang.org/cargo/reference/build-scripts.html#rustc-link-search) error: aborting due to previous error ```
2021-06-30Add suggestions for "undefined reference" link errorsSmitty-5/+14
2021-06-30Improve debug symbol names to avoid ambiguity and work better with MSVC's ↵Daniel Paoliello-86/+260
debugger There are several cases where names of types and functions in the debug info are either ambiguous, or not helpful, such as including ambiguous placeholders (e.g., `{{impl}}`, `{{closure}}` or `dyn _'`) or dropping qualifications (e.g., for dynamic types). Instead, each debug symbol name should be unique and useful: * Include disambiguators for anonymous `DefPathDataName` (closures and generators), and unify their formatting when used as a path-qualifier vs item being qualified. * Qualify the principal trait for dynamic types. * If there is no principal trait for a dynamic type, emit all other traits instead. * Respect the `qualified` argument when emitting ref and pointer types. * For implementations, emit the disambiguator. * Print const generics when emitting generic parameters or arguments. Additionally, when targeting MSVC, its debugger treats many command arguments as C++ expressions, even when the argument is defined to be a symbol name. As such names in the debug info need to be more C++-like to be parsed correctly: * Avoid characters with special meaning (`#`, `[`, `"`, `+`). * Never start a name with `<` or `{` as this is treated as an operator. * `>>` is always treated as a right-shift, even when parsing generic arguments (so add a space to avoid this). * Emit function declarations using C/C++ style syntax (e.g., leading return type). * Emit arrays as a synthetic `array$<type, size>` type. * Include a `$` in all synthetic types as this is a legal character for C++, but not Rust (thus we avoid collisions with user types).
2021-06-30Add support for leaf fn frame pointer eliminationSimonas Kazlauskas-2/+2
This PR adds ability for the target specifications to specify frame pointer emission type that's not just “always” or “whatever cg decides”. In particular there's a new mode that allows omission of the frame pointer for leaf functions (those that don't call any other functions). We then set this new mode for Aarch64-based Apple targets. Fixes #86196
2021-06-29Auto merge of #86475 - crlf0710:miri_vtable_refactor, r=bjorn3bors-39/+6
Change vtable memory representation to use tcx allocated allocations. This fixes https://github.com/rust-lang/rust/issues/86324. However i suspect there's more to change before it can land. r? `@bjorn3` cc `@rust-lang/miri`
2021-06-28Update other codegens to use tcx managed vtable allocations.Charles Lew-39/+6
2021-06-28Auto merge of #85909 - cjgillot:alloc-kind-query, r=Aaron1011bors-2/+2
Make allocator_kind a query. Part of #85153 r? `@Aaron1011`
2021-06-21Auto merge of #86166 - tmiasko:no-alloca-for-zsts, r=nagisabors-93/+74
Do not emit alloca for ZST locals with multiple assignments This extends 35566bfd7dd2e316d190078703de54a4dadda062 to additionally stop emitting unnecessary allocas for zero sized locals that are assigned multiple times. When rebuilding the standard library with `-Zbuild-std` this reduces the number of locals that require an allocation from 62315 to 61767.
2021-06-20Make allocator_kind a query.Camille GILLOT-2/+2
2021-06-15Refactor to make interpreter and codegen backend neutral to vtable internal ↵Charles Lew-34/+34
representation.
2021-06-11Auto merge of #86204 - alexcrichton:wasm-simd-stable, r=Amanieubors-1/+1
std: Stabilize wasm simd intrinsics This commit performs two changes to stabilize Rust support for WebAssembly simd intrinsics: * The stdarch submodule is updated to pull in rust-lang/stdarch#1179. * The `wasm_target_feature` feature gate requirement for the `simd128` feature has been removed, stabilizing the name `simd128`. This should conclude the FCP started on #74372 and... Closes #74372
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-27 01:11:59 +0000