about summary refs log tree commit diff
path: root/compiler/rustc_codegen_ssa/src
AgeCommit message (Collapse)AuthorLines
2023-05-03Restrict `From<S>` for `{D,Subd}iagnosticMessage`.Nicholas Nethercote-9/+9
Currently a `{D,Subd}iagnosticMessage` can be created from any type that impls `Into<String>`. That includes `&str`, `String`, and `Cow<'static, str>`, which are reasonable. It also includes `&String`, which is pretty weird, and results in many places making unnecessary allocations for patterns like this: ``` self.fatal(&format!(...)) ``` This creates a string with `format!`, takes a reference, passes the reference to `fatal`, which does an `into()`, which clones the reference, doing a second allocation. Two allocations for a single string, bleh. This commit changes the `From` impls so that you can only create a `{D,Subd}iagnosticMessage` from `&str`, `String`, or `Cow<'static, str>`. This requires changing all the places that currently create one from a `&String`. Most of these are of the `&format!(...)` form described above; each one removes an unnecessary static `&`, plus an allocation when executed. There are also a few places where the existing use of `&String` was more reasonable; these now just use `clone()` at the call site. As well as making the code nicer and more efficient, this is a step towards possibly using `Cow<'static, str>` in `{D,Subd}iagnosticMessage::{Str,Eager}`. That would require changing the `From<&'a str>` impls to `From<&'static str>`, which is doable, but I'm not yet sure if it's worthwhile.
2023-05-02Rollup merge of #110955 - fee1-dead-contrib:sus-operation, r=compiler-errorsDylan DPC-4/+3
uplift `clippy::clone_double_ref` as `suspicious_double_ref_op` Split from #109842. r? ``@compiler-errors``
2023-05-01Change rlink serialization from `MemEncoder` to `FileEncoder`.Nicholas Nethercote-3/+7
Because we're writing to a file, so `FileEncoder` is better because we don't have to write all the data to memory first.
2023-04-30Rollup merge of #110586 - ChrisDenton:msvc-oem-output, r=workingjubileeMatthias Krüger-1/+78
Fix Unreadable non-UTF-8 output on localized MSVC Fixes #35785 by converting non UTF-8 linker output to Unicode using the OEM code page. Before: ```text = note: Non-UTF-8 output: LINK : fatal error LNK1181: cannot open input file \'m\x84rchenhaft.obj\'\r\n ``` After: ```text = note: LINK : fatal error LNK1181: cannot open input file 'märchenhaft.obj' ``` The difference is more dramatic if using a non-ascii language pack for Windows.
2023-04-29Make PlaceMention a non-mutating use.Camille GILLOT-1/+3
2023-04-28Rollup merge of #110917 - Be-ing:whole_archive_with_staticlib_fix, ↵Matthias Krüger-1/+4
r=petrochenkov only error combining +whole-archive and +bundle for rlibs Fixes https://github.com/rust-lang/rust/issues/110912 Checking `flavor == RlibFlavor::Normal` was accidentally lost in 601fc8b36b1962285e371cf3c54eeb3b1b9b3a74 https://github.com/rust-lang/rust/pull/105601 That caused combining +whole-archive and +bundle link modifiers on non-rlib crates to fail with a confusing error message saying that combination is unstable for rlibs. In particular, this caused the build to fail when +whole-archive was used on staticlib crates, even though +whole-archive effectively does nothing on non-bin crates because the final linker invocation is left to an external build system. cc ``@petrochenkov``
2023-04-28uplift `clippy::clone_double_ref` as `suspicious_double_ref_op`Deadbeef-4/+3
2023-04-28Auto merge of #110837 - scottmcm:offset-for-add, r=compiler-errorsbors-2/+9
Use MIR's `Offset` for pointer `add` too ~~Status: draft while waiting for #110822 to land, since this is built atop that.~~ ~~r? `@ghost~~` Canonical Rust code has mostly moved to `add`/`sub` on pointers, which take `usize`, instead of `offset` which takes `isize`. (And, relatedly, when `sub_ptr` was added it turned out it replaced every single in-tree use of `offset_from`, because `usize` is just so much more useful than `isize` in Rust.) Unfortunately, `intrinsics::offset` could only accept `*const` and `isize`, so there's a *huge* amount of type conversions back and forth being done. They're identity conversions in the backend, but still end up producing quite a lot of unhelpful MIR. This PR changes `intrinsics::offset` to accept `*const` *and* `*mut` along with `isize` *and* `usize`. Conveniently, the backends and CTFE already handle this, since MIR's `BinOp::Offset` [already supports all four combinations](https://github.com/rust-lang/rust/blob/adaac6b166df57ea5a20d56e4cce503b55aca927/compiler/rustc_const_eval/src/transform/validate.rs#L523-L528). To demonstrate the difference, I added some `mir-opt/pre-codegen/` tests around slice indexing. Here's the difference to `[T]::get_mut`, since it uses `<*mut _>::add` internally: ```diff `@@` -79,30 +70,21 `@@` fn slice_get_mut_usize(_1: &mut [u32], _2: usize) -> Option<&mut u32> { StorageLive(_12); // scope 3 at $SRC_DIR/core/src/slice/index.rs:LL:COL StorageLive(_9); // scope 6 at $SRC_DIR/core/src/slice/index.rs:LL:COL _9 = _8 as *mut u32 (PtrToPtr); // scope 11 at $SRC_DIR/core/src/ptr/mut_ptr.rs:LL:COL - StorageLive(_13); // scope 13 at $SRC_DIR/core/src/ptr/mut_ptr.rs:LL:COL - _13 = _2 as isize (IntToInt); // scope 13 at $SRC_DIR/core/src/ptr/mut_ptr.rs:LL:COL - StorageLive(_14); // scope 15 at $SRC_DIR/core/src/ptr/mut_ptr.rs:LL:COL - StorageLive(_15); // scope 15 at $SRC_DIR/core/src/ptr/mut_ptr.rs:LL:COL - _15 = _9 as *const u32 (Pointer(MutToConstPointer)); // scope 15 at $SRC_DIR/core/src/ptr/mut_ptr.rs:LL:COL - _14 = Offset(move _15, _13); // scope 15 at $SRC_DIR/core/src/ptr/mut_ptr.rs:LL:COL - StorageDead(_15); // scope 15 at $SRC_DIR/core/src/ptr/mut_ptr.rs:LL:COL - _7 = move _14 as *mut u32 (PtrToPtr); // scope 15 at $SRC_DIR/core/src/ptr/mut_ptr.rs:LL:COL - StorageDead(_14); // scope 15 at $SRC_DIR/core/src/ptr/mut_ptr.rs:LL:COL - StorageDead(_13); // scope 13 at $SRC_DIR/core/src/ptr/mut_ptr.rs:LL:COL + _7 = Offset(_9, _2); // scope 13 at $SRC_DIR/core/src/ptr/mut_ptr.rs:LL:COL StorageDead(_9); // scope 6 at $SRC_DIR/core/src/slice/index.rs:LL:COL StorageDead(_12); // scope 3 at $SRC_DIR/core/src/slice/index.rs:LL:COL StorageDead(_11); // scope 3 at $SRC_DIR/core/src/slice/index.rs:LL:COL ``` https://github.com/rust-lang/rust/pull/110837/commits/1c1c8e442add0f46905a57a25a6cba52b8b0c54d#diff-a841b6a4538657add3f39bc895744331453d0625e7aace128b1f604f0b63c8fdR80
2023-04-27Also use `mir::Offset` for pointer `add`Scott McMurray-2/+9
2023-04-27only error with +whole-archive,+bundle for rlibsBe Wilson-1/+4
Fixes https://github.com/rust-lang/rust/issues/110912 Checking `flavor == RlibFlavor::Normal` was accidentally lost in 601fc8b36b1962285e371cf3c54eeb3b1b9b3a74 https://github.com/rust-lang/rust/pull/105601 That caused combining +whole-archive and +bundle link modifiers on non-rlib crates to fail with a confusing error message saying that combination is unstable for rlibs. In particular, this caused the build to fail when +whole-archive was used on staticlib crates, even though +whole-archive effectively does nothing on non-bin crates because the final linker invocation is left to an external build system.
2023-04-27Rollup merge of #110872 - Jules-Bertholet:err-67981, r=wesleywiserMatthias Krüger-1/+11
Nicer ICE for #67981 Provides a slightly nicer ICE for #67981, documenting the problem. A proper fix will be necessary before `#![feature(unsized_fn_params)]` can be stabilized. The problem is that the design of the `"rust-call"` ABI is fundamentally not compatible with `unsized_fn_params`. `"rust-call"` functions need to collect their arguments into a tuple, but if the arguments are not `Sized`, said tuple is potentially not even a valid type—and if it is, it requires `alloca` to create. ``@rustbot`` label +A-abi +A-codegen +F-unboxed_closures +F-unsized_fn_params
2023-04-27Abstract `MultiByteToWideChar`Chris Denton-33/+57
2023-04-27Fix Unreadable non-UTF-8 output on localized MSVCChris Denton-1/+54
Fixes #35785 by converting non UTF-8 linker output to Unicode using the OEM code page. Before: ```text = note: Non-UTF-8 output: LINK : fatal error LNK1181: cannot open input file \'m\x84rchenhaft.obj\'\r\n ``` After: ```text = note: LINK : fatal error LNK1181: cannot open input file 'märchenhaft.obj' ``` The difference is more dramatic if using a non-ascii language pack for Visual Studio.
2023-04-27rename `needs_infer` to `has_infer`Boxy-1/+1
2023-04-27Support RISC-V unaligned-scalar-mem target featureKor Nielsen-0/+1
This adds `unaligned-scalar-mem` as an allowed RISC-V target feature. Some RISC-V cores support unaligned access to memory without trapping. On such cores, the compiler could significantly improve code-size and performance when using functions like core::ptr::read_unaligned<u32> by emitting a single load or store instruction with an unaligned address, rather than a long sequence of byte load/store/bitmanip instructions. Enabling the `unaligned-scalar-mem` target feature allows LLVM to do this optimization. Fixes #110883
2023-04-26Nicer ICE for #67981Jules Bertholet-1/+11
2023-04-26Auto merge of #110852 - matthiaskrgr:rollup-jz3eosr, r=matthiaskrgrbors-20/+43
Rollup of 10 pull requests Successful merges: - #108760 (Add lint to deny diagnostics composed of static strings) - #109444 (Change tidy error message for TODOs) - #110419 (Spelling library) - #110550 (Suggest deref on comparison binop RHS even if type is not Copy) - #110641 (Add new rustdoc book chapter to describe in-doc settings) - #110798 (pass `unused_extern_crates` in `librustdoc::doctest::make_test`) - #110819 (simplify TrustedLen impls) - #110825 (diagnostics: add test case for already-solved issue) - #110835 (Make some region folders a little stricter.) - #110847 (rustdoc-json: Time serialization.) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
2023-04-25Lower `intrinsics::offset` to `mir::BinOp::Offset`Scott McMurray-7/+0
They're semantically the same, so this means the backends don't need to handle the intrinsic and means fewer MIR basic blocks in pointer arithmetic code.
2023-04-25Fix static string lintsclubby789-20/+43
2023-04-25Revert "Remove #[alloc_error_handler] from the compiler and library"Matthias Krüger-4/+12
This reverts commit abc0660118cc95f47445fd33502a11dd448f5968.
2023-04-24Split `{Idx, IndexVec, IndexSlice}` into their own modulesMaybe Waffle-4/+4
2023-04-22Set debug location to debug operand spill.Camille GILLOT-0/+1
2023-04-22Auto merge of #109507 - Amanieu:panic-oom-payload, r=davidtwcobors-12/+4
Report allocation errors as panics OOM is now reported as a panic but with a custom payload type (`AllocErrorPanicPayload`) which holds the layout that was passed to `handle_alloc_error`. This should be review one commit at a time: - The first commit adds `AllocErrorPanicPayload` and changes allocation errors to always be reported as panics. - The second commit removes `#[alloc_error_handler]` and the `alloc_error_hook` API. ACP: https://github.com/rust-lang/libs-team/issues/192 Closes #51540 Closes #51245
2023-04-22Add GNU Property NoteCharisee-0/+42
2023-04-22Auto merge of #106934 - DrMeepster:offset_of, r=WaffleLapkinbors-1/+4
Add offset_of! macro (RFC 3308) Implements https://github.com/rust-lang/rfcs/pull/3308 (tracking issue #106655) by adding the built in macro `core::mem::offset_of`. Two of the future possibilities are also implemented: * Nested field accesses (without array indexing) * DST support (for `Sized` fields) I wrote this a few months ago, before the RFC merged. Now that it's merged, I decided to rebase and finish it. cc `@thomcc` (RFC author)
2023-04-21offset_ofDrMeepster-1/+4
2023-04-20Remove WithOptconstParam.Camille GILLOT-1/+1
2023-04-20Auto merge of #110598 - matthiaskrgr:rollup-0ybd9i3, r=matthiaskrgrbors-4/+4
Rollup of 5 pull requests Successful merges: - #110240 (Add `indent_style = tab` for `Makefile`s to `.editorconfig`) - #110545 (Add `GenericArgKind::as_{type,const,region}`) - #110574 ( fix out-of-date comment about rpath in bootstrap) - #110581 (Style fix for loongarch-linux.md) - #110584 (Allow overwriting the sysroot compile flag in compile tests) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
2023-04-20Rollup merge of #110545 - WaffleLapkin:generic_arg_as_x, r=cjgillotMatthias Krüger-4/+4
Add `GenericArgKind::as_{type,const,region}` This allows to make code nicer in some cases
2023-04-20Auto merge of #109993 - scottmcm:transmute-niches, r=oli-obkbors-5/+67
`assume` value ranges in `transmute` Fixes #109958
2023-04-19Add transmute optimization tests and some extra commentsScott McMurray-0/+9
2023-04-19Auto merge of #106704 - ecnelises:big_archive, r=bjorn3bors-0/+1
Support AIX-style archive type Reading facility of AIX big archive has been supported by `object` since 0.30.0. Writing facility of AIX big archive has already been supported by `ar_archive_writer`, but we need to bump the version to support the new archive type enum.
2023-04-19Support `--print native-static-libs` with rust dylibsbjorn3-5/+70
2023-04-19Add `GenericArgKind::as_{type,const,region}`Maybe Waffle-4/+4
2023-04-19Auto merge of #110407 - Nilstrieb:fluent-macro, r=davidtwcobors-1/+1
Add `rustc_fluent_macro` to decouple fluent from `rustc_macros` Fluent, with all the icu4x it brings in, takes quite some time to compile. `fluent_messages!` is only needed in further downstream rustc crates, but is blocking more upstream crates like `rustc_index`. By splitting it out, we allow `rustc_macros` to be compiled earlier, which speeds up `x check compiler` by about 5 seconds (and even more after the needless dependency on `serde_json` is removed from `rustc_data_structures`).
2023-04-19Recognize AIX style archive kindQiu Chaofan-0/+1
2023-04-18Auto merge of #110083 - saethlin:encode-hashes-as-bytes, r=cjgillotbors-3/+2
Encode hashes as bytes, not varint In a few places, we store hashes as `u64` or `u128` and then apply `derive(Decodable, Encodable)` to the enclosing struct/enum. It is more efficient to encode hashes directly than try to apply some varint encoding. This PR adds two new types `Hash64` and `Hash128` which are produced by `StableHasher` and replace every use of storing a `u64` or `u128` that represents a hash. Distribution of the byte lengths of leb128 encodings, from `x build --stage 2` with `incremental = true` Before: ``` ( 1) 373418203 (53.7%, 53.7%): 1 ( 2) 196240113 (28.2%, 81.9%): 3 ( 3) 108157958 (15.6%, 97.5%): 2 ( 4) 17213120 ( 2.5%, 99.9%): 4 ( 5) 223614 ( 0.0%,100.0%): 9 ( 6) 216262 ( 0.0%,100.0%): 10 ( 7) 15447 ( 0.0%,100.0%): 5 ( 8) 3633 ( 0.0%,100.0%): 19 ( 9) 3030 ( 0.0%,100.0%): 8 ( 10) 1167 ( 0.0%,100.0%): 18 ( 11) 1032 ( 0.0%,100.0%): 7 ( 12) 1003 ( 0.0%,100.0%): 6 ( 13) 10 ( 0.0%,100.0%): 16 ( 14) 10 ( 0.0%,100.0%): 17 ( 15) 5 ( 0.0%,100.0%): 12 ( 16) 4 ( 0.0%,100.0%): 14 ``` After: ``` ( 1) 372939136 (53.7%, 53.7%): 1 ( 2) 196240140 (28.3%, 82.0%): 3 ( 3) 108014969 (15.6%, 97.5%): 2 ( 4) 17192375 ( 2.5%,100.0%): 4 ( 5) 435 ( 0.0%,100.0%): 5 ( 6) 83 ( 0.0%,100.0%): 18 ( 7) 79 ( 0.0%,100.0%): 10 ( 8) 50 ( 0.0%,100.0%): 9 ( 9) 6 ( 0.0%,100.0%): 19 ``` The remaining 9 or 10 and 18 or 19 are `u64` and `u128` respectively that have the high bits set. As far as I can tell these are coming primarily from `SwitchTargets`.
2023-04-18Add `rustc_fluent_macro` to decouple fluent from `rustc_macros`Nilstrieb-1/+1
Fluent, with all the icu4x it brings in, takes quite some time to compile. `fluent_messages!` is only needed in further downstream rustc crates, but is blocking more upstream crates like `rustc_index`. By splitting it out, we allow `rustc_macros` to be compiled earlier, which speeds up `x check compiler` by about 5 seconds (and even more after the needless dependency on `serde_json` is removed from `rustc_data_structures`).
2023-04-18Stablize raw-dylib, link_ordinal and -CdlltoolDaniel Paoliello-9/+0
2023-04-18Store hashes in special types so they aren't accidentally encoded as numbersBen Kimock-3/+2
2023-04-17Spelling - compilerJosh Soref-3/+3
* account * achieved * advising * always * ambiguous * analysis * annotations * appropriate * build * candidates * cascading * category * character * clarification * compound * conceptually * constituent * consts * convenience * corresponds * debruijn * debug * debugable * debuggable * deterministic * discriminant * display * documentation * doesn't * ellipsis * erroneous * evaluability * evaluate * evaluation * explicitly * fallible * fulfill * getting * has * highlighting * illustrative * imported * incompatible * infringing * initialized * into * intrinsic * introduced * javascript * liveness * metadata * monomorphization * nonexistent * nontrivial * obligation * obligations * offset * opaque * opportunities * opt-in * outlive * overlapping * paragraph * parentheses * poisson * precisely * predecessors * predicates * preexisting * propagated * really * reentrant * referent * responsibility * rustonomicon * shortcircuit * simplifiable * simplifications * specify * stabilized * structurally * suggestibility * translatable * transmuting * two * unclosed * uninhabited * visibility * volatile * workaround Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
2023-04-16Remove #[alloc_error_handler] from the compiler and libraryAmanieu d'Antras-12/+4
2023-04-16Various minor Idx-related tweaksScott McMurray-2/+1
Nothing particularly exciting here, but a couple of things I noticed as I was looking for more index conversions to simplify.
2023-04-14Remove attempt to optimize codegen for discriminants.Camille GILLOT-92/+0
2023-04-13`assume` value ranges in `transmute`Scott McMurray-5/+58
Fixes #109958
2023-04-13Auto merge of #109466 - davidlattimore:inline-arg-via-var-debug-info, ↵bors-6/+4
r=wesleywiser Preserve argument indexes when inlining MIR We store argument indexes on VarDebugInfo. Unlike the previous method of relying on the variable index to know whether a variable is an argument, this survives MIR inlining. We also no longer check if var.source_info.scope is the outermost scope. When a function gets inlined, the arguments to the inner function will no longer be in the outermost scope. What we care about though is whether they were in the outermost scope prior to inlining, which we know by whether we assigned an argument index. Fixes #83217 I considered using `Option<NonZeroU16>` instead of `Option<u16>` to store the index. I didn't because `TypeFoldable` isn't implemented for `NonZeroU16` and because it looks like due to padding, it currently wouldn't make any difference. But I indexed from 1 anyway because (a) it'll make it easier if later it becomes worthwhile to use a `NonZeroU16` and because the arguments were previously indexed from 1, so it made for a smaller change. This is my first PR on rust-lang/rust, so apologies if I've gotten anything not quite right.
2023-04-12Rollup merge of #110153 - DaniPopes:compiler-typos, r=NilstriebMatthias Krüger-3/+3
Fix typos in compiler I ran [`typos -w compiler`](https://github.com/crate-ci/typos) to fix typos in the `compiler` directory. Refs #110150
2023-04-11Rollup merge of #96971 - zhaixiaojuan:master, r=wesleywiserMichael Goulet-0/+5
Initial support for loongarch64-unknown-linux-gnu Hi, We hope to add a new port in rust for LoongArch. LoongArch intro LoongArch is a RISC style ISA which is independently designed by Loongson Technology in China. It is divided into two versions, the 32-bit version (LA32) and the 64-bit version (LA64). LA64 applications have application-level backward binary compatibility with LA32 applications. LoongArch is composed of a basic part (Loongson Base) and an expanded part. The expansion part includes Loongson Binary Translation (LBT), Loongson VirtualiZation (LVZ), Loongson SIMD EXtension (LSX) and Loongson Advanced SIMD EXtension(LASX). Currently the LA464 processor core supports LoongArch ISA and the Loongson 3A5000 processor integrates 4 64-bit LA464 cores. LA464 is a four-issue 64-bit high-performance processor core. It can be used as a single core for high-end embedded and desktop applications, or as a basic processor core to form an on-chip multi-core system for server and high-performance machine applications. Documentations: ISA: https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html ABI: https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html More docs can be found at: https://loongson.github.io/LoongArch-Documentation/README-EN.html Since last year, we have locally adapted two versions of rust, rust1.41 and rust1.57, and completed the test locally. I'm not sure if I'm submitting all the patches at once, so I split up the patches and here's one of the commits
2023-04-11Rollup merge of #109860 - zyedidia:riscv-relax, r=petrochenkovYuki Okushi-0/+1
Add support for RISC-V relax target feature This adds `relax` as an allowed RISC-V target feature. The relax feature in LLVM enables [linker relaxation](https://www.sifive.com/blog/all-aboard-part-3-linker-relaxation-in-riscv-toolchain), an optimization specific to RISC-V that allows global variable accesses to be resolved by the linker by using the global pointer (`gp`) register (rather than constructing the addresses from scratch for each access). Enabling `relax` will cause LLVM to emit relocations in the object file that support this. The feature can be enabled in rustc with `-C target-feature=+relax`. Currently this feature is disabled by default, but maybe it should be enabled by default since it is an easy performance improvement (but requires the `gp` register to be set up properly). GCC/Clang enable this feature by default (for both hosted/bare-metal targets), and include the `-mno-relax` flag to disable it (see [here](https://github.com/llvm/llvm-project/blob/466d554dcab39c3d42fe0c5b588b795e0e4b9d0d/clang/lib/Driver/ToolChains/Arch/RISCV.cpp#L145) for the code that enables it in Clang). I think it would make sense to enable by default, at least for all hosted targets since the `gp` register should be automatically set up by the runtime. For bare-metal targets, `gp` must be set up manually, so it is probably best to leave off by default to avoid breaking existing applications that do not set up `gp`. Leaving it disabled by default for all targets is also reasonable though. Let me know your thoughts. Thanks! Fixes #109426.
2023-04-11Preserve argument indexes when inlining MIRDavid Lattimore-6/+4
We store argument indexes on VarDebugInfo. Unlike the previous method of relying on the variable index to know whether a variable is an argument, this survives MIR inlining. We also no longer check if var.source_info.scope is the outermost scope. When a function gets inlined, the arguments to the inner function will no longer be in the outermost scope. What we care about though is whether they were in the outermost scope prior to inlining, which we know by whether we assigned an argument index.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-23 18:03:45 +0000