about summary refs log tree commit diff
path: root/compiler/rustc_codegen_ssa
AgeCommit message (Collapse)AuthorLines
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.
2023-08-29Rollup merge of #111580 - atsuzaki:layout-ice, r=oli-obkMatthias Krüger-0/+12
Don't ICE on layout computation failure Fixes #111176 regression. r? `@oli-obk`
2023-08-29const_eval and codegen: audit uses of is_zstRalf Jung-12/+18
2023-08-28Don't ICE on layout computation failureKatherine Philip-0/+12
2023-08-27Auto merge of #115139 - cjgillot:llvm-fragment, r=nikicbors-9/+28
Do not forget to pass DWARF fragment information to LLVM. Fixes https://github.com/rust-lang/rust/issues/115113 for the rustc part
2023-08-26Do not produce fragment for ZST.Camille GILLOT-7/+12
2023-08-26Do not forget to pass DWARF fragment information to LLVM.Camille GILLOT-2/+16
2023-08-25Revert "Use the same DISubprogram for each instance of the same inlined ↵Wesley Wiser-14/+4
function within the caller" This reverts commit 687bffa49375aa00bacc51f5d9adfb84a9453e17. Reverting to resolve ICEs reported on nightly.
2023-08-24cache the terminate block with the last reason that we sawRalf Jung-8/+7
2023-08-24when terminating during unwinding, show the reason whyRalf Jung-78/+83
2023-08-22Auto merge of #114643 - dpaoliello:inlinedebuginfo, r=wesleywiserbors-4/+14
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 is 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 when building for x86_64 Windows (note the lack of `.cv_loc` before the call to `panic`, thus it will be attributed to the same line at the `addq` instruction): ``` .cv_loc 0 1 23 0 # src\lib.rs:23: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, this also requires caching the `DILexicalBlock` and `DIVariable` objects to avoid creating duplicates. After this change the above assembly now looks like: ``` .cv_loc 0 1 23 0 # src\lib.rs:23:0 addq $40, %rsp retq .cv_inline_site_id 5 within 0 inlined_at 1 0 0 .cv_inline_site_id 6 within 5 inlined_at 1 12 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-08-21Always add LC_BUILD_VERSION for metadata object filesKeith Smiley-17/+12
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.
2023-08-20give some unwind-related terminators a more clear nameRalf Jung-4/+4
2023-08-18Fix ELF flag for RISC-V targets without explicit ABIGary Guo-1/+1
2023-08-18Add comment explanining unstable_target_featuresGary Guo-0/+1
2023-08-18Fix ABI flags in RISC-V/LoongArch ELF file generated by rustcGary Guo-17/+20
2023-08-17Revert "Implement references VarDebugInfo."Camille GILLOT-42/+12
This reverts commit 2ec007191348ef7cc13eb55e44e007b02cf75cf3.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-24 23:25:43 +0000