about summary refs log tree commit diff
path: root/compiler/rustc_codegen_ssa
AgeCommit message (Collapse)AuthorLines
2023-10-02Add docs, remove code, change subtyper codeouz-a-1/+1
2023-10-02subtyping_projectionsouz-a-0/+1
2023-10-02Reapply: Mark drop calls in landing pads cold instead of noinlineErik Desjardins-8/+4
Co-authored-by: Max Fan <git@max.fan> Co-authored-by: Nikita Popov <npopov@redhat.com>
2023-09-30dont call mir.post_mono_checks in codegenRalf Jung-11/+0
2023-09-29Auto merge of #113301 - Be-ing:stabilize_bundle_whole-archive, r=petrochenkovbors-15/+1
stabilize combining +bundle and +whole-archive link modifiers Per discussion on https://github.com/rust-lang/rust/issues/108081 combining +bundle and +whole-archive already works and can be stabilized independently of other aspects of the packed_bundled_libs feature. There is no risk of regression because this was not previously allowed. r? `@petrochenkov`
2023-09-28Strip `OpaqueCast` during `RevealAll`.Oli Scherer-1/+3
2023-09-27fix clippy::{redundant_guards, useless_format}Matthias Krüger-1/+1
2023-09-26Auto merge of #116144 - lcnr:subst-less, r=oli-obkbors-1/+1
subst -> instantiate continues #110793, there are still quite a few uses of `subst` and `substitute`, but changing them all in the same PR was a bit too much, so I've stopped here for now.
2023-09-26Auto merge of #116102 - cjgillot:indirect-scalar, r=oli-obkbors-12/+11
Correct codegen of `ConstValue::Indirect` scalar and scalar pair This concerns 3 tricky cases with `ConstValue::Indirect`: - if we want a non-pointer scalar; - if we have non-zero offset; - if offset points to uninit memory => generate `poison` instead of an ICE. This case could happen in unreachable code, trying to extract a field from the wrong variant. Those cases are not currently emitted by the compiler, but are exercised by https://github.com/rust-lang/rust/pull/116012.
2023-09-26subst -> instantiatelcnr-1/+1
2023-09-25Pass name of object file to LLVM so it can correctly emit S_OBJNAMEFlorian Schmiderer-1/+8
2023-09-24Auto merge of #105861 - Ayush1325:uefi-std-minimial, r=workingjubileebors-6/+22
Add Minimal Std implementation for UEFI # Implemented modules: 1. alloc 2. os_str 3. env 4. math # Related Links Tracking Issue: https://github.com/rust-lang/rust/issues/100499 API Change Proposal: https://github.com/rust-lang/libs-team/issues/87 # Additional Information This was originally part of https://github.com/rust-lang/rust/pull/100316. Since that PR was becoming too unwieldy and cluttered, and with suggestion from `@dvdhrm,` I have extracted a minimal std implementation to this PR. The example in `src/doc/rustc/src/platform-support/unknown-uefi.md` has been tested for `x86_64-unknown-uefi` and `i686-unknown-uefi` in OVMF. It would be great if someone more familiar with AARCH64 can help with testing for that target. Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
2023-09-24Rollup merge of #116104 - cjgillot:calculate_debuginfo_offset, r=b-naberMatthias Krüger-33/+10
Reuse calculate_debuginfo_offset for fragments. This removes a little code duplication.
2023-09-23Use correct offset when codegening mir::Const::Indirect.Camille GILLOT-12/+11
2023-09-23Tolerate non-ptr indirect scalars in codegen.Camille GILLOT-1/+1
2023-09-23Reuse calculate_debuginfo_offset for fragments.Camille GILLOT-33/+10
2023-09-23Remove GeneratorWitness and rename GeneratorWitnessMIR.Camille GILLOT-1/+0
2023-09-22Merge `ExternProviders` into the general `Providers` structOli Scherer-13/+5
2023-09-22Have a single struct for queries and hookOli Scherer-3/+3
2023-09-22Rebase to masterAyush Singh-9/+4
- Update Example - Add thread_parking to sys::uefi - Fix unsafe in unsafe errors - Improve docs - Improve os/exit - Some asserts - Switch back to atomics Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
2023-09-22Add Minimal Std implementation for UEFIAyush Singh-7/+28
Implemented modules: 1. alloc 2. os_str 3. env 4. math Tracking Issue: https://github.com/rust-lang/rust/issues/100499 API Change Proposal: https://github.com/rust-lang/libs-team/issues/87 This was originally part of https://github.com/rust-lang/rust/pull/100316. Since that PR was becoming too unwieldy and cluttered, and with suggestion from @dvdhrm, I have extracted a minimal std implementation to this PR. Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
2023-09-22Add a way to decouple the implementation and the declaration of a TyCtxt method.Oli Scherer-1/+2
2023-09-21Rollup merge of #115972 - RalfJung:const-consistency, r=oli-obkGuillaume Gomez-14/+14
rename mir::Constant -> mir::ConstOperand, mir::ConstKind -> mir::Const Also, be more consistent with the `to/eval_bits` methods... we had some that take a type and some that take a size, and then sometimes the one that takes a type is called `bits_for_ty`. Turns out that `ty::Const`/`mir::ConstKind` carry their type with them, so we don't need to even pass the type to those `eval_bits` functions at all. However this is not properly consistent yet: in `ty` we have most of the methods on `ty::Const`, but in `mir` we have them on `mir::ConstKind`. And indeed those two types are the ones that correspond to each other. So `mir::ConstantKind` should actually be renamed to `mir::Const`. But what to do with `mir::Constant`? It carries around a span, that's really more like a constant operand that appears as a MIR operand... it's more suited for `syntax.rs` than `consts.rs`, but the bigger question is, which name should it get if we want to align the `mir` and `ty` types? `ConstOperand`? `ConstOp`? `Literal`? It's not a literal but it has a field called `literal` so it would at least be consistently wrong-ish... ``@oli-obk`` any ideas?
2023-09-21rename mir::Constant -> mir::ConstOperand, mir::ConstKind -> mir::ConstRalf Jung-12/+12
2023-09-20the Const::eval_bits methods don't need to be given the TyRalf Jung-2/+2
2023-09-19adjust constValue::Slice to work for arbitrary slice typesRalf Jung-6/+3
2023-09-19move ConstValue into mirRalf Jung-8/+8
this way we have mir::ConstValue and ty::ValTree as reasonably parallel
2023-09-18Auto merge of #115748 - RalfJung:post-mono, r=oli-obkbors-85/+21
move required_consts check to general post-mono-check function This factors some code that is common between the interpreter and the codegen backends into shared helper functions. Also as a side-effect the interpreter now uses the same `eval` functions as everyone else to get the evaluated MIR constants. Also this is in preparation for another post-mono check that will be needed for (the current hackfix for) https://github.com/rust-lang/rust/issues/115709: ensuring that all locals are dynamically sized. I didn't expect this to change diagnostics, but it's just cycle errors that change. r? `@oli-obk`
2023-09-15clarify PassMode::Indirect as wellRalf Jung-1/+1
2023-09-15explain PassMode::CastRalf Jung-8/+8
2023-09-14don't point at const usage site for resolution-time errorsRalf Jung-34/+8
also share the code that emits the actual error
2023-09-14move required_consts check to general post-mono-check functionRalf Jung-65/+27
2023-09-14Auto merge of #115817 - fee1-dead-contrib:fix-codegen, r=oli-obkbors-15/+27
treat host effect params as erased in codegen This fixes the changes brought to codegen tests when effect params are added to libcore, by not attempting to monomorphize functions that get the host param by being `const fn`. r? `@oli-obk`
2023-09-14treat host effect params as erased generics in codegenDeadbeef-15/+27
This fixes the changes brought to codegen tests when effect params are added to libcore, by not attempting to monomorphize functions that get the host param by being `const fn`.
2023-09-14make it more clear which functions create fresh AllocIdRalf Jung-2/+6
2023-09-14cleanup op_to_const a bit; rename ConstValue::ByRef → IndirectRalf Jung-1/+1
2023-09-14use AllocId instead of Allocation in ConstValue::ByRefRalf Jung-1/+3
2023-09-14Auto merge of #114656 - bossmc:rework-no-coverage-attr, r=oli-obkbors-2/+28
Rework `no_coverage` to `coverage(off)` As discussed at the tail of https://github.com/rust-lang/rust/issues/84605 this replaces the `no_coverage` attribute with a `coverage` attribute that takes sub-parameters (currently `off` and `on`) to control the coverage instrumentation. Allows future-proofing for things like `coverage(off, reason="Tested live", issue="#12345")` or similar.
2023-09-13Rollup merge of #115798 - RalfJung:non_1zst_field, r=wesleywiserMatthias Krüger-31/+10
add helper method for finding the one non-1-ZST field
2023-09-13make the eval() functions on our const types return the resulting valueRalf Jung-36/+22
2023-09-12add helper method for finding the one non-1-ZST fieldRalf Jung-31/+10
2023-09-11Remove assert that checks type equalityouz-a-4/+4
2023-09-08Auto merge of #115417 - dpaoliello:fixdi, r=wesleywiserbors-4/+9
Use the same DISubprogram for each instance of the same inlined function within a caller # Issue Details: The call to `panic` within a function like `Option::unwrap` is translated to LLVM as a `tail call` (as it will never return), when multiple calls to the same function like this are inlined LLVM will notice the common `tail call` block (i.e., loading the same panic string + location info and then calling `panic`) and merge them together. When merging these instructions together, LLVM will also attempt to merge the debug locations as well, but this fails (i.e., debug info is dropped) as Rust emits a new `DISubprogram` at each inline site thus LLVM doesn't recognize that these are actually the same function and so thinks that there isn't a common debug location. As an example of this, consider the following program: ```rust #[no_mangle] fn add_numbers(x: &Option<i32>, y: &Option<i32>) -> i32 { let x1 = x.unwrap(); let y1 = y.unwrap(); x1 + y1 } ``` When building for x86_64 Windows using 1.72 it generates (note the lack of `.cv_loc` before the call to `panic`, thus it will be attributed to the same line at the `addq` instruction): ```llvm .cv_loc 0 1 3 0 # src\lib.rs:3:0 addq $40, %rsp retq leaq .Lalloc_f570dea0a53168780ce9a91e67646421(%rip), %rcx leaq .Lalloc_629ace53b7e5b76aaa810d549cc84ea3(%rip), %r8 movl $43, %edx callq _ZN4core9panicking5panic17h12e60b9063f6dee8E int3 ``` # Fix Details: Cache the `DISubprogram` emitted for each inlined function instance within a caller so that this can be reused if that instance is encountered again. Ideally, we would also deduplicate child scopes and variables, however my attempt to do that with #114643 resulted in asserts when building for Linux (#115156) which would require some deep changes to Rust to fix (#115455). Instead, when using an inlined function as a debug scope, we will also create a new child scope such that subsequent child scopes and variables do not collide (from LLVM's perspective). After this change the above assembly now (with <https://reviews.llvm.org/D159226> as well) shows the `panic!` was inlined from `unwrap` in `option.rs` at line 935 into the current function in `lib.rs` at line 0 (line 0 is emitted since it is ambiguous which line to use as there were two inline sites that lead to this same code): ```llvm .cv_loc 0 1 3 0 # src\lib.rs:3:0 addq $40, %rsp retq .cv_inline_site_id 6 within 0 inlined_at 1 0 0 .cv_loc 6 2 935 0 # library\core\src\option.rs:935:0 leaq .Lalloc_5f55955de67e57c79064b537689facea(%rip), %rcx leaq .Lalloc_e741d4de8cb5801e1fd7a6c6795c1559(%rip), %r8 movl $43, %edx callq _ZN4core9panicking5panic17hde1558f32d5b1c04E int3 ```
2023-09-08Correct typoAndy Caldwell-1/+1
2023-09-08Rework no_coverage to coverage(off)Andy Caldwell-2/+28
2023-09-08Auto merge of #113492 - nebulark:pr_96475, r=petrochenkovbors-0/+7
Add CL and CMD into to pdb debug info Partial fix for https://github.com/rust-lang/rust/issues/96475 The Arg0 and CommandLineArgs of the MCTargetOptions cpp class are not set within https://github.com/rust-lang/rust/blob/bb548f964572f7fe652716f5897d9050a31c936e/compiler/rustc_llvm/llvm-wrapper/PassWrapper.cpp#L378 This causes LLVM to not neither output any compiler path (cl) nor the arguments that were used when invoking it (cmd) in the PDB file. This fix adds the missing information to the target machine so LLVM can use it.
2023-09-08Add missing Debuginfo to PDB debug file on windows.Florian Schmiderer-0/+7
Set Arg0 and CommandLineArgs in MCTargetoptions so LLVM outputs correct CL and CMD in LF_DEBUGINFO instead of empty/invalid values.
2023-09-05Refactor how MIR represents composite debuginfo.Camille GILLOT-78/+77
2023-09-01Deduplicate inlined function debug info, but create a new lexical scope to ↵Daniel Paoliello-4/+9
child subsequent scopes and variables from colliding
2023-08-29Auto merge of #114114 - ↵bors-17/+12
keith:ks/always-add-lc_build_version-for-metadata-object-files, r=wesleywiser Always add LC_BUILD_VERSION for metadata object files As of Xcode 15 Apple's linker has become a bit more strict about the warnings it produces. One of those new warnings requires all valid Mach-O object files in an archive to have a LC_BUILD_VERSION load command: ``` ld: warning: no platform load command found in 'ARCHIVE[arm64][2106](lib.rmeta)', assuming: iOS-simulator ``` This was already being done for Mac Catalyst so this change expands this logic to include it for all Apple platforms. I filed this behavior change as FB12546320 and was told it was the new intentional behavior.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-27 17:09:39 +0000