about summary refs log tree commit diff
path: root/compiler/rustc_session/src
AgeCommit message (Collapse)AuthorLines
2025-03-21Cache current_dll_path outputbjorn3-56/+66
Computing the current dll path is somewhat expensive relative to other work when compiling `fn main() {}` as `dladdr` needs to iterate over the symbol table of librustc_driver.so until it finds a match.
2025-03-20Rollup merge of #138700 - xizheyin:issue-138612, r=NadrierilMatthias Krüger-0/+6
Suggest `-Whelp` when pass `--print lints` to rustc Closes #138612
2025-03-19Only use the new node hashmap for anonymous nodes.Camille GILLOT-1/+2
2025-03-19Auto merge of #122156 - Zoxc:side-effect-dep-node, r=oli-obkbors-1/+1
Represent diagnostic side effects as dep nodes This changes diagnostic to be tracked as a special dep node (`SideEffect`) instead of having a list of side effects associated with each dep node. `SideEffect` is always red and when forced, it emits the diagnostic and marks itself green. Each emitted diagnostic generates a new `SideEffect` with an unique dep node index. Some implications of this: - Diagnostic may now be emitted more than once as they can be emitted once when the `SideEffect` gets marked green and again if the task it depends on needs to be re-executed due to another node being red. It relies on deduplicating of diagnostics to avoid that. - Anon tasks which emits diagnostics will no longer *incorrectly* be merged with other anon tasks. - Reusing a CGU will now emit diagnostics from the task generating it.
2025-03-19Suggest `-Whelp` when pass `--print lints` to rustcxizheyin-0/+6
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
2025-03-17modify config.toml->bootstrap.toml for new upstream changesbit-aloo-1/+1
2025-03-17Target modifiers fix for bool flags without valueAndrew Zhogin-24/+28
2025-03-16Rename `PrintKind::{AllTargetSpecs,TargetSpec}` to ↵Jieyou Xu-5/+5
`{AllTargetSpecsJson,TargetSpecJson}` To correspond to their actual print request names, `target-spec-json` and `all-target-specs-json`, and for consistency with other print name <-> print kind mappings.
2025-03-16Extract print request stability gating and unknown print request help into ↵Jieyou Xu-43/+35
helpers To avoid duplicating stability check logic and make the print request collection logic more straightforward.
2025-03-16Alphabetically sort `PrintKind` and enforce with tidyJieyou Xu-15/+17
2025-03-14Rename `QuerySideEffects` to `QuerySideEffect`John Kåre Alsaker-1/+1
2025-03-14Show valid crate types when the user passes unknown `--crate-type` valuemalezjaa-1/+6
Co-authored-by: Jieyou Xu <jieyouxu@outlook.com>
2025-03-13Rollup merge of #138404 - bjorn3:sysroot_handling_cleanup, ↵Matthias Krüger-32/+25
r=petrochenkov,jieyouxu Cleanup sysroot locating a bit All commits should preserve existing behavior.
2025-03-12Remove unused host_tlib_path fieldbjorn3-2/+1
2025-03-12Don't return an error from get_or_default_sysrootbjorn3-27/+21
All callers unwrap the result.
2025-03-12Make opts.maybe_sysroot non-optionalbjorn3-3/+3
build_session_options always uses materialize_sysroot anyway.
2025-03-11Remove `#![warn(unreachable_pub)]` from all `compiler/` crates.Nicholas Nethercote-1/+0
It's no longer necessary now that `-Wunreachable_pub` is being passed.
2025-03-10Revert "Use workspace lints for crates in `compiler/` #138084"许杰友 Jieyou Xu (Joe)-0/+1
Revert <https://github.com/rust-lang/rust/pull/138084> to buy time to consider options that avoids breaking downstream usages of cargo on distributed `rustc-src` artifacts, where such cargo invocations fail due to inability to inherit `lints` from workspace root manifest's `workspace.lints` (this is only valid for the source rust-lang/rust workspace, but not really the distributed `rustc-src` artifacts). This breakage was reported in <https://github.com/rust-lang/rust/issues/138304>. This reverts commit 48caf81484b50dca5a5cebb614899a3df81ca898, reversing changes made to c6662879b27f5161e95f39395e3c9513a7b97028.
2025-03-09Rollup merge of #138084 - nnethercote:workspace-lints, r=jieyouxuMatthias Krüger-1/+0
Use workspace lints for crates in `compiler/` This is nicer and hopefully less error prone than specifying lints via bootstrap. r? ``@jieyouxu``
2025-03-09Rollup merge of #138040 - thaliaarchi:use-prelude-size-of.compiler, ↵Matthias Krüger-1/+1
r=compiler-errors compiler: Use `size_of` from the prelude instead of imported Use `std::mem::{size_of, size_of_val, align_of, align_of_val}` from the prelude instead of importing or qualifying them. Apply this change across the compiler. These functions were added to all preludes in Rust 1.80. r? ``@compiler-errors``
2025-03-08Remove `#![warn(unreachable_pub)]` from all `compiler/` crates.Nicholas Nethercote-1/+0
(Except for `rustc_codegen_cranelift`.) It's no longer necessary now that `unreachable_pub` is in the workspace lints.
2025-03-07compiler: Use size_of from the prelude instead of importedThalia Archibald-1/+1
Use `std::mem::{size_of, size_of_val, align_of, align_of_val}` from the prelude instead of importing or qualifying them. These functions were added to all preludes in Rust 1.80.
2025-03-07Remove highlighting of spans on `-Zteach`Esteban Küber-1/+0
`-Zteach` is perma-unstable, barely used, the highlighting logic buggy and the flag being passed around is tech-debt. We should likely remove `-Zteach` in its entirely.
2025-03-07Rollup merge of #138111 - estebank:use-dfv, r=nnethercoteMatthias Krüger-34/+27
Use `default_field_values` for `rustc_errors::Context`, `rustc_session::config::NextSolverConfig` and `rustc_session::config::ErrorOutputType` Wanted to see where `#![feature(default_field_values)]` could be used in the codebase. These three seemed like no-brainers. There are a bunch of more places where we could remove manual `Default` impls, but they `derive` other traits that rely on `syn`, which [doesn't yet support `default_field_values`](https://github.com/dtolnay/syn/issues/1774).
2025-03-04Rollup merge of #137975 - Zalathar:needs-hir, r=compiler-errorsJubilee-8/+0
Remove unused `PpMode::needs_hir` This method was added in #99360 to avoid an overzealous `span_delayed_bug` ICE in specific circumstances, but the only caller was subsequently removed in #136603, which presumably avoids the problem in a more principled way.
2025-03-04Auto merge of #135695 - Noratrieb:elf-raw-dylib, r=bjorn3bors-0/+1
Support raw-dylib link kind on ELF raw-dylib is a link kind that allows rustc to link against a library without having any library files present. This currently only exists on Windows. rustc will take all the symbols from raw-dylib link blocks and put them in an import library, where they can then be resolved by the linker. While import libraries don't exist on ELF, it would still be convenient to have this same functionality. Not having the libraries present at build-time can be convenient for several reasons, especially cross-compilation. With raw-dylib, code linking against a library can be cross-compiled without needing to have these libraries available on the build machine. If the libc crate makes use of this, it would allow cross-compilation without having any libc available on the build machine. This is not yet possible with this implementation, at least against libc's like glibc that use symbol versioning. The raw-dylib kind could be extended with support for symbol versioning in the future. This implementation is very experimental and I have not tested it very well. I have tested it for a toy example and the lz4-sys crate, where it was able to successfully link a binary despite not having a corresponding library at build-time. I was inspired by Björn's comments in https://internals.rust-lang.org/t/bundle-zig-cc-in-rustup-by-default/22096/27 Tracking issue: #135694 r? bjorn3 try-job: aarch64-apple try-job: x86_64-msvc-1 try-job: x86_64-msvc-2 try-job: test-various
2025-03-04Remove unused `PpMode::needs_hir`Zalathar-8/+0
2025-03-03Use default field values for `ErrorOutputType`Esteban Küber-26/+23
Remove manual `Default` impl from `config::ErrorOutputType`.
2025-03-03Use default field values for `config::NextSolverConfig`Esteban Küber-8/+4
Use default field values to avoid manual `Default` impl.
2025-03-01ensure we always print all --print options in helpMichael Toner-30/+34
2025-03-01Auto merge of #133250 - DianQK:embed-bitcode-pgo, r=nikicbors-0/+3
The embedded bitcode should always be prepared for LTO/ThinLTO Fixes #115344. Fixes #117220. There are currently two methods for generating bitcode that used for LTO. One method involves using `-C linker-plugin-lto` to emit object files as bitcode, which is the typical setting used by cargo. The other method is through `-C embed-bitcode=yes`. When using with `-C embed-bitcode=yes -C lto=no`, we run a complete non-LTO LLVM pipeline to obtain bitcode, then the bitcode is used for LTO. We run the Call Graph Profile Pass twice on the same module. This PR is doing something similar to LLVM's `buildFatLTODefaultPipeline`, obtaining the bitcode for embedding after running `buildThinLTOPreLinkDefaultPipeline`. r? nikic
2025-02-26Support raw-dylib link kind on ELFNoratrieb-0/+1
raw-dylib is a link kind that allows rustc to link against a library without having any library files present. This currently only exists on Windows. rustc will take all the symbols from raw-dylib link blocks and put them in an import library, where they can then be resolved by the linker. While import libraries don't exist on ELF, it would still be convenient to have this same functionality. Not having the libraries present at build-time can be convenient for several reasons, especially cross-compilation. With raw-dylib, code linking against a library can be cross-compiled without needing to have these libraries available on the build machine. If the libc crate makes use of this, it would allow cross-compilation without having any libc available on the build machine. This is not yet possible with this implementation, at least against libc's like glibc that use symbol versioning. The raw-dylib kind could be extended with support for symbol versioning in the future. This implementation is very experimental and I have not tested it very well. I have tested it for a toy example and the lz4-sys crate, where it was able to successfully link a binary despite not having a corresponding library at build-time.
2025-02-25Teach structured errors to display short `Ty`Esteban Küber-4/+4
Make it so that every structured error annotated with `#[derive(Diagnostic)]` that has a field of type `Ty<'_>`, the printing of that value into a `String` will look at the thread-local storage `TyCtxt` in order to shorten to a length appropriate with the terminal width. When this happen, the resulting error will have a note with the file where the full type name was written to. ``` error[E0618]: expected function, found `((..., ..., ..., ...), ..., ..., ...)`` --> long.rs:7:5 | 6 | fn foo(x: D) { //~ `x` has type `(... | - `x` has type `((..., ..., ..., ...), ..., ..., ...)` 7 | x(); //~ ERROR expected function, found `(... | ^-- | | | call expression requires function | = note: the full name for the type has been written to 'long.long-type-14182675702747116984.txt' = note: consider using `--verbose` to print the full type name to the console ```
2025-02-23Remove unused `OutputType::ThinLinkBitcode`DianQK-12/+1
2025-02-23Document bitcode in `OutputType`DianQK-0/+5
2025-02-23The embedded bitcode should always be prepared for LTO/ThinLTODianQK-1/+10
2025-02-22Greatly simplify lifetime captures in edition 2024Michael Goulet-7/+6
2025-02-22Auto merge of #137420 - matthiaskrgr:rollup-rr0q37f, r=matthiaskrgrbors-17/+17
Rollup of 9 pull requests Successful merges: - #136910 (Implement feature `isolate_most_least_significant_one` for integer types) - #137183 (Prune dead regionck code) - #137333 (Use `edition = "2024"` in the compiler (redux)) - #137356 (Ferris 🦀 Identifier naming conventions) - #137362 (Add build step log for `run-make-support`) - #137377 (Always allow reusing cratenum in CrateLoader::load) - #137388 (Fix(lib/fs/tests): Disable rename POSIX semantics FS tests under Windows 7) - #137410 (Use StableHasher + Hash64 for dep_tracking_hash) - #137413 (jubilee cleared out the review queue) r? `@ghost` `@rustbot` modify labels: rollup
2025-02-22Rollup merge of #137410 - saethlin:stable-dep-tracking-hash, r=workingjubileeMatthias Krüger-15/+16
Use StableHasher + Hash64 for dep_tracking_hash This is similar to https://github.com/rust-lang/rust/pull/137095. We currently have a +/- 1 byte jitter in the size of dep graphs reported on perf.rust-lang.org. I think this fixes that jitter. When I introduced `Hash64`, I wired it through most of the compiler by making it an output of `StableHasher::finalize` then fixing the compile errors. I missed this case because the `u64` hash in this function is being produced by `DefaultHasher` instead. That seems pretty sketchy because the code seems confident that the hash needs to be stable, and we have a mechanism for stable hashing that we weren't using here.
2025-02-21update autodiff flagsManuel Drehwald-38/+26
2025-02-21Use StableHasher + Hash64 for dep_tracking_hashBen Kimock-15/+16
2025-02-22Fix binding mode problemsMichael Goulet-2/+1
2025-02-17Auto merge of #137164 - matthiaskrgr:rollup-dj5826k, r=matthiaskrgrbors-2/+2
Rollup of 7 pull requests Successful merges: - #137095 (Replace some u64 hashes with Hash64) - #137100 (HIR analysis: Remove unnecessary abstraction over list of clauses) - #137105 (Restrict DerefPure for Cow<T> impl to T = impl Clone, [impl Clone], str.) - #137120 (Enable `relative-path-include-bytes-132203` rustdoc-ui test on Windows) - #137125 (Re-add missing empty lines in the releases notes) - #137145 (use add-core-stubs / minicore for a few more tests) - #137149 (Remove SSE ABI from i586-pc-windows-msvc) r? `@ghost` `@rustbot` modify labels: rollup
2025-02-17Rollup merge of #137095 - saethlin:use-hash64-for-hashes, r=workingjubileeMatthias Krüger-2/+2
Replace some u64 hashes with Hash64 I introduced the Hash64 and Hash128 types in https://github.com/rust-lang/rust/pull/110083, essentially as a mechanism to prevent hashes from landing in our leb128 encoding paths. If you just have a u64 or u128 field in a struct then derive Encodable/Decodable, that number gets leb128 encoding. So if you need to store a hash or some other value which behaves very close to a hash, don't store it as a u64. This reverts part of https://github.com/rust-lang/rust/pull/117603, which turned an encoded Hash64 into a u64. Based on https://github.com/rust-lang/rust/pull/110083, I don't expect this to be perf-sensitive on its own, though I expect that it may help stabilize some of the small rmeta size fluctuations we currently see in perf reports.
2025-02-17Rollup merge of #136671 - nnethercote:middle-limits, r=NadrierilMatthias Krüger-0/+7
Overhaul `rustc_middle::limits` In particular, to make `pattern_complexity` work more like other limits, which then enables some other simplifications. r? ``@Nadrieril``
2025-02-17Add `pattern_complexity_limit` to `Limits`.Nicholas Nethercote-0/+7
It's similar to the other limits, e.g. obtained via `get_limit`. So it makes sense to handle it consistently with the other limits. We now use `Limit`/`usize` in most places instead of `Option<usize>`, so we use `Limit::new(usize::MAX)`/`usize::MAX` to emulate how `None` used to work. The commit also adds `Limit::unlimited`.
2025-02-16Move hashes from rustc_data_structure to rustc_hashes so they can be shared ↵Ben Kimock-2/+2
with rust-analyzer
2025-02-16Rollup merge of #137072 - Urgau:check-cfg-load-builtins-at-once, r=NoratriebMatthias Krüger-6/+2
Load all builtin targets at once instead of one by one in check-cfg This PR adds a method on `rustc_target::Target` to load all the builtin targets at once, and then uses that method when constructing the `target_*` values in check-cfg instead of load loading each target one by one by their name, which requires a lookup and was more of a hack anyway. This may give us some performance improvements as we won't need to do the lookup for the _currently_ 287 targets we have.
2025-02-15Load all builtin targets at once instead of one by oneUrgau-6/+2
This should give us some performance improvements as we won't need to do the lookup for the _currently_ 287 targets we have.
2025-02-15Reject macro calls inside of `#![crate_name]`León Orell Valerian Liehr-68/+3
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-09 05:34:37 +0000