about summary refs log tree commit diff
path: root/compiler/rustc_session/src/config.rs
AgeCommit message (Collapse)AuthorLines
2023-03-09Honor current target when checking conditional compilation valuesUrgau-3/+4
This is fixed by simply using the currently registered target in the current session. We need to use it because of target json that are not by design included in the rustc list of targets.
2023-03-03Rollup merge of #108694 - est31:backticks_matchmaking_comments, r=NilstriebMatthias Krüger-1/+1
Match unmatched backticks in compiler/ comments r? ``@Nilstrieb`` as per [advice](https://github.com/rust-lang/rust/pull/108685#issuecomment-1453018499)
2023-03-03Match end user facing unmatched backticks in compiler/est31-1/+1
2023-03-03Match unmatched backticks in compiler/ that are part of rustdocest31-1/+1
2023-02-18Auto merge of #99679 - repnop:kernel-address-sanitizer, r=cuviperbors-1/+7
Add `kernel-address` sanitizer support for freestanding targets This PR adds support for KASan (kernel address sanitizer) instrumentation in freestanding targets. I included the minimal set of `x86_64-unknown-none`, `riscv64{imac, gc}-unknown-none-elf`, and `aarch64-unknown-none` but there's likely other targets it can be added to. (`linux_kernel_base.rs`?) KASan uses the address sanitizer attributes but has the `CompileKernel` parameter set to `true` in the pass creation.
2023-02-16Replace some `then`s with some `then_some`sMaybe Waffle-1/+1
2023-02-16`if $c:expr { Some($r:expr) } else { None }` =>> `$c.then(|| $r)`Maybe Waffle-1/+1
2023-02-14Add `kernel-address` sanitizer support for freestanding targetsWesley Norris-1/+7
2023-02-10Skip doc link resolution for some crate types and non-exported itemsVadim Petrochenkov-2/+27
2023-02-09Parse "-Z instrument-xray" codegen optionOleksii Lozovskyi-3/+23
Recognize all bells and whistles that LLVM's XRay pass is capable of. The always/never settings are a bit dumb without attributes but they're still there. The default instruction count is chosen by the compiler, not LLVM pass. We'll do it later.
2023-01-30session: impl `IntoDiagnosticArg` for `CrateType`David Wood-1/+7
Forward the `Display` implementation for `CrateType` to `IntoDiagnosticArg` so that it can be used in diagnostic structs. Signed-off-by: David Wood <david.wood@huawei.com>
2023-01-29Rollup merge of #107006 - b-naber:thir-tree, r=jackh726Matthias Krüger-3/+8
Output tree representation on thir-tree The current output of `-Zunpretty=thir-tree` is really cumbersome to work with, using an actual tree representation should make it easier to see what the thir looks like.
2023-01-27Rollup merge of #106856 - vadorovsky:fix-atomic-annotations, r=joshtriplettYuki Okushi-0/+8
core: Support variety of atomic widths in width-agnostic functions Before this change, the following functions and macros were annotated with `#[cfg(target_has_atomic = "8")]` or `#[cfg(target_has_atomic_load_store = "8")]`: * `atomic_int` * `strongest_failure_ordering` * `atomic_swap` * `atomic_add` * `atomic_sub` * `atomic_compare_exchange` * `atomic_compare_exchange_weak` * `atomic_and` * `atomic_nand` * `atomic_or` * `atomic_xor` * `atomic_max` * `atomic_min` * `atomic_umax` * `atomic_umin` However, none of those functions and macros actually depend on 8-bit width and they are needed for all atomic widths (16-bit, 32-bit, 64-bit etc.). Some targets might not support 8-bit atomics (i.e. BPF, if we would enable atomic CAS for it). This change fixes that by removing the `"8"` argument from annotations, which results in accepting the whole variety of widths. Fixes #106845 Fixes #106795 Signed-off-by: Michal Rostecki <vadorovsky@gmail.com>
2023-01-26previous thir unpretty output through thir-flatb-naber-3/+8
2023-01-26Rollup merge of #106904 - khuey:preserve_debuginfo_for_rlibs, r=davidtwcoMatthias Krüger-12/+0
Preserve split DWARF files when building archives. r? ```@davidtwco```
2023-01-25Add `target_has_atomic*` symbols if any atomic width is supportedMichal Rostecki-0/+8
Atomic operations for different widths (8-bit, 16-bit, 32-bit etc.) are guarded by `target_has_atomic = "value"` symbol (i.e. `target_has_atomic = "8"`) (and the other derivatives), but before this change, there was no width-agnostic symbol indicating a general availability of atomic operations. This change introduces: * `target_has_atomic_load_store` symbol when atomics for any integer width are supported by the target. * `target_has_atomic` symbol when also CAS is supported. Fixes #106845 Signed-off-by: Michal Rostecki <vadorovsky@gmail.com>
2023-01-19Auto merge of #106810 - oli-obk:resolver_reverse_plumbing, r=petrochenkovbors-4/+22
Various cleanups around pre-TyCtxt queries and functions part of #105462 based on https://github.com/rust-lang/rust/pull/106776 (everything starting at [0e2b39f](https://github.com/rust-lang/rust/pull/106810/commits/0e2b39fd1ffde51b50d45ccbe41de52b85136b8b) is new in this PR) r? `@petrochenkov` I think this should be most of the uncontroversial part of #105462.
2023-01-17Rollup merge of #104505 - WaffleLapkin:no-double-spaces-in-comments, r=jackh726Matthias Krüger-2/+2
Remove double spaces after dots in comments Most of the comments do not have double spaces, so I assume these are typos.
2023-01-17Remove double spaces after dots in commentsMaybe Waffle-2/+2
2023-01-16Avoid an unnecessary allocationOli Scherer-8/+8
2023-01-16check -Z query-dep-graph is enabled if -Z dump-dep-graph (#106736)gftea-0/+5
2023-01-16Remove redundant `input_path` field from `Config`Oli Scherer-0/+18
2023-01-15Preserve split DWARF files when building archives.Kyle Huey-12/+0
The optimization that removes artifacts when building libraries is correct from the compiler's perspective but not from a debugger's perspective. Unpacked split debuginfo is referred to by filename and debuggers need the artifact that contains debuginfo to continue to exist at that path. Ironically the test expects the correct behavior but it was not running.
2023-01-14Removed various double spaces in compiler source comments.André Vennberg-1/+1
2023-01-06Update compiler/rustc_session/src/config.rsMatthew E-1/+1
Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com>
2023-01-06Add default and latest stable edition to --edition in rustcMatthew Esposito-2/+8
2023-01-04Rename stock solver to classicMichael Goulet-2/+2
2023-01-04Split `-Zchalk` flag into `-Ztrait-solver=(stock|chalk|next)` flagMichael Goulet-1/+12
2023-01-04Rollup merge of #106274 - jyn514:dump-mono-stats, r=lqdMatthias Krüger-0/+18
Add JSON output to -Zdump-mono-stats Follow-up to https://github.com/rust-lang/rust/pull/105481 r? `@lqd` cc `@wesleywiser`
2023-01-02Add json output to `-Zdump-mono-stats`Joshua Nelson-0/+18
This allows analyzing the output programatically; for example, finding the item with the highest `total_estimate`. I also took the liberty of adding `untracked` tests to `rustc_session` and documentation to the unstable book for `dump-mono-items`.
2022-12-25Only enable relative span hashing on nightly.Camille GILLOT-0/+6
2022-12-15more clippy::complexity fixesMatthias Krüger-9/+3
2022-12-10compiler: remove unnecessary imports and qualified pathsKaDiWa-1/+1
2022-12-06Auto merge of #105175 - michaelwoerister:add-stable-ord-trait, r=nagisabors-1/+4
Add StableOrd trait as proposed in MCP 533. The `StableOrd` trait can be used to mark types as having a stable sort order across compilation sessions. Collections that sort their items in a stable way can safely implement HashStable by hashing items in sort order. See https://github.com/rust-lang/compiler-team/issues/533 for more information.
2022-12-02Add StableOrd trait as proposed in MCP 533.Michael Woerister-1/+4
The StableOrd trait can be used to mark types as having a stable sort order across compilation sessions. Collections that sort their items in a stable way can safely implement HashStable by hashing items in sort order.
2022-12-01Remove useless borrows and derefsMaybe Waffle-6/+6
2022-11-27Stabilize native library modifier `verbatim`Vadim Petrochenkov-4/+1
2022-11-24move things from rustc_target::abi to rustc_abihkalbasi-2/+2
2022-11-16Use `as_deref` in compiler (but only where it makes sense)Maybe Waffle-2/+2
2022-11-07Add --print=split-debuginfoKamil Koczurek-0/+2
This option prints all supported values for -Csplit-debuginfo=.., i.e. only stable ones on stable/beta and all of them on nightly/dev.
2022-11-05Rollup merge of #103660 - ozkanonur:master, r=jyn514Dylan DPC-1/+1
improve `filesearch::get_or_default_sysroot` `fn get_or_default_sysroot` is now improved and used in `miri` and `clippy`, and tests are still passing as they should. So we no longer need to implement custom workarounds/hacks to find sysroot in tools like miri/clippy. Resolves https://github.com/rust-lang/rust/issues/98832 re-opened from #103581
2022-11-04improve `filesearch::get_or_default_sysroot` r=ozkanonurOnur Özkan-1/+1
Signed-off-by: Onur Özkan <work@onurozkan.dev>
2022-11-02Rollup merge of #103610 - wesleywiser:thinlto_cgu1, r=michaelwoeristerMatthias Krüger-7/+7
Allow use of `-Clto=thin` with `-Ccodegen-units=1` in general The current logic to ignore ThinLTO when `-Ccodegen-units=1` makes sense for local ThinLTO but even in this scenario, a user may still want (non-local) ThinLTO for the purpose of optimizing dependencies into the final crate which is being compiled with 1 CGU. The previous behavior was even more confusing because if you were generating a binary (`--emit=link`), then you would get ThinLTO but if you asked for LLVM IR or bytecode, then it would silently change to using regular LTO. With this change, we only override the defaults for local ThinLTO if you ask for a single output such as LLVM IR or bytecode and in all other cases honor the requested LTO setting. r? `@michaelwoerister`
2022-11-01Rollup merge of #103839 - Nilstrieb:print-list, r=compiler-errorsManish Goregaokar-23/+38
Print valid `--print` requests if request is invalid When someone makes a typo, it can be useful to see the valid options. This is also useful if someone wants to find out about all the options.
2022-11-01Print valid `--print` requests if request is invalidnils-23/+38
When someone makes a typo, it can be useful to see the valid options. This is also useful if someone wants to find out about all the options.
2022-10-26Allow use of `-Clto=thin` with `-Ccodegen-units=1` in generalWesley Wiser-7/+7
The current logic to ignore ThinLTO when `-Ccodegen-units=1` makes sense for local ThinLTO but even in this scenario, a user may still want (non-local) ThinLTO for the purpose of optimizing dependencies into the final crate which is being compiled with 1 CGU. The previous behavior was even more confusing because if you were generating a binary (`--emit=link`), then you would get ThinLTO but if you asked for LLVM IR or bytecode, then it would silently change to using regular LTO. With this change, we only override the defaults for local ThinLTO if you ask for a single output such as LLVM IR or bytecode and in all other cases honor the requested LTO setting.
2022-10-19Implement -Ztrack-diagnosticsmejrs-0/+1
2022-10-12ADD - IntoDiagnostic conformance for TargetDataLayoutErrors in rustc_errorsJhonny Bill Mena-2/+1
This way we comply with the Coherence rule given that IntoDiagnostic trait is defined in rustc_errors, and almost all other crates depend on it.
2022-09-22Improve the help message for an invalid calling conventionkhyperia-2/+4
2022-09-21FIX - adopt new Diagnostic naming in newly migrated modulesJhonny Bill Mena-1/+2
FIX - ambiguous Diagnostic link in docs UPDATE - rename diagnostic_items to IntoDiagnostic and AddToDiagnostic [Gardening] FIX - formatting via `x fmt` FIX - rebase conflicts. NOTE: Confirm wheather or not we want to handle TargetDataLayoutErrorsWrapper this way DELETE - unneeded allow attributes in Handler method FIX - broken test FIX - Rebase conflict UPDATE - rename residual _SessionDiagnostic and fix LintDiag link
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-25 09:00:39 +0000