summary refs log tree commit diff
path: root/compiler/rustc_session/src/config.rs
AgeCommit message (Collapse)AuthorLines
2022-07-31Rollup merge of #99519 - Urgau:check-cfg-implicit, r=petrochenkovMatthias Krüger-14/+0
Remove implicit names and values from `--cfg` in `--check-cfg` This PR remove the implicit names and values from `--cfg` in `--check-cfg` because the behavior is quite surprising but also because it's really easy to inadvertently really on the implicitness and when the `--cfg` is not set anymore to have an unexpected warning from an unexpected condition that pass with the implicitness. This change in behavior will also enable us to warn when an unexpected `--cfg` is passed, ex: the user wrote `--cfg=unstabl` instead of `--cfg=unstable`. The implementation of the warning will be done in a follow-up PR. cc `@petrochenkov`
2022-07-30Auto merge of #99123 - mystor:crossbeam_bridge, r=eddybbors-0/+10
proc_macro: use crossbeam channels for the proc_macro cross-thread bridge This is done by having the crossbeam dependency inserted into the `proc_macro` server code from the server side, to avoid adding a dependency to `proc_macro`. In addition, this introduces a -Z command-line option which will switch rustc to run proc-macros using this cross-thread executor. With the changes to the bridge in #98186, #98187, #98188 and #98189, the performance of the executor should be much closer to same-thread execution. In local testing, the crossbeam executor was substantially more performant than either of the two existing `CrossThread` strategies, so they have been removed to keep things simple. r? `@eddyb`
2022-07-29proc_macro: use crossbeam channels for the proc_macro cross-thread bridgeNika Layzell-0/+10
This is done by having the crossbeam dependency inserted into the proc_macro server code from the server side, to avoid adding a dependency to proc_macro. In addition, this introduces a -Z command-line option which will switch rustc to run proc-macros using this cross-thread executor. With the changes to the bridge in #98186, #98187, #98188 and #98189, the performance of the executor should be much closer to same-thread execution. In local testing, the crossbeam executor was substantially more performant than either of the two existing CrossThread strategies, so they have been removed to keep things simple.
2022-07-29Auto merge of #99467 - BelovDV:add_option_link_arg, r=petrochenkovbors-2/+15
flag '-l link-arg=___ was added #99427
2022-07-27lint: add bad opt access internal lintDavid Wood-0/+4
Some command-line options accessible through `sess.opts` are best accessed through wrapper functions on `Session`, `TyCtxt` or otherwise, rather than through field access on the option struct in the `Session`. Adds a new lint which triggers on those options that should be accessed through a wrapper function so that this is prohibited. Options are annotated with a new attribute `rustc_lint_opt_deny_field_access` which can specify the error message (i.e. "use this other function instead") to be emitted. A simpler alternative would be to simply rename the options in the option type so that it is clear they should not be used, however this doesn't prevent uses, just discourages them. Another alternative would be to make the option fields private, and adding accessor functions on the option types, however the wrapper functions sometimes rely on additional state from `Session` or `TyCtxt` which wouldn't be available in an function on the option type, so the accessor would simply make the field available and its use would be discouraged too. Signed-off-by: David Wood <david.wood@huawei.com>
2022-07-26Lib kind -l link-arg:Daniil Belov-2/+15
arbitrary link argument like -C link-arg, but respecting relative order to other `-l` options, unstable
2022-07-20Remove implicit names and values from --cfg in --check-cfgUrgau-14/+0
2022-07-16Do not ICE when we have -Zunpretty=expand with invalid ABIMichael Goulet-0/+8
2022-07-13Rename `debugging_opts` to `unstable_opts`Joshua Nelson-46/+46
This is no longer used only for debugging options (e.g. `-Zoutput-width`, `-Zallow-features`). Rename it to be more clear.
2022-07-06session: `output-width` -> `diagnostic-width`David Wood-6/+6
Rename the `--output-width` flag to `--diagnostic-width` as this appears to be the preferred name within the compiler team. Signed-off-by: David Wood <david.wood@huawei.com>
2022-07-06session: `terminal-width` -> `output-width`David Wood-6/+6
Rename the `--terminal-width` flag to `--output-width` as the behaviour doesn't just apply to terminals (and so is slightly less accurate). Signed-off-by: David Wood <david.wood@huawei.com>
2022-07-06sess: stabilize `--terminal-width`David Wood-0/+12
Formerly `-Zterminal-width`, `--terminal-width` allows the user or build tool to inform rustc of the width of the terminal so that diagnostics can be truncated. Signed-off-by: David Wood <david.wood@huawei.com>
2022-07-04incr.comp.: Make split-dwarf commandline options [TRACKED].Michael Woerister-2/+3
2022-07-01update cfg(bootstrap)sPietro Albini-43/+0
2022-06-21Auto merge of #97657 - Urgau:check-cfg-many-mut, r=oli-obkbors-34/+89
Use get_many_mut to reduce the cost of setting up check cfg values This PR use the newly added [`get_many_mut`](https://github.com/rust-lang/rust/issues/97601) function in [`HashMap`](https://doc.rust-lang.org/nightly/std/collections/hash_map/struct.HashMap.html#method.get_many_mut) to reduce the cost of setting up the initial check cfg values. cc `@petrochenkov`
2022-06-16Support lint expectations for `--force-warn` lints (RFC 2383)xFrednet-1/+1
2022-06-15Use get_many_mut to reduce the cost of setup ping check cfg valuesUrgau-34/+89
2022-06-09Stabilize the `bundle` native library modifierVadim Petrochenkov-19/+1
2022-06-08bye `BorrowckMode`lcnr-17/+0
2022-06-03Fully stabilize NLLJack Huey-12/+0
2022-05-20Remove `crate` visibility usage in compilerJacob Pratt-3/+3
2022-05-15rustc: Stricter checking for #[link] attributesVadim Petrochenkov-59/+45
2022-04-28Auto merge of #96085 - jsgf:deny-unused-deps, r=compiler-errorsbors-5/+33
Make sure `-Dunused-crate-dependencies --json unused-externs` makes rustc exit with error status This PR: - fixes compiletest to understand unused extern notifications - adds tests for `--json unused-externs` - makes sure that deny-level unused externs notifications are treated as compile errors - refactors the `emit_unused_externs` callstack to plumb through the level as an enum as a string, and adds `Level::is_error` Update: adds `--json unused-externs-silent` with the original behaviour since Cargo needs it. Should address `@est31's` concerns. Fixes: https://github.com/rust-lang/rust/issues/96068
2022-04-28Rollup merge of #96483 - Urgau:check-cfg-target_feature, r=petrochenkovDylan DPC-0/+5
Add missing `target_feature` to the list of well known cfg names This PR adds the missing `target_feature` cfg name to the list of well known cfg names. It was notice missing in https://github.com/rust-lang/rust/issues/96472 thanks to `@bjorn3,` the reason being that `--check-cfg=names()` automatically inherit the names passed by `--cfg` (or internal to `rustc`) and is seems that the vast majority of targets have at least one target feature leading to `target_feature` being a well known name in most target but it should always be a well known name so this PR add it unconditionally to list. r? `@petrochenkov`
2022-04-27Add missing `target_feature` to the list of well known cfg namesLoïc BRANSTETT-0/+5
2022-04-27Add --json unused-externs-silent with original behaviourJeremy Fitzhardinge-5/+33
Since Cargo wants to do its own fatal error handling for unused dependencies, add the option `--json unused-externs-silent` which has the original behaviour of not indicating non-zero exit status for `deny`/`forbid`-level unused dependencies.
2022-04-23Add support for `nounused` --extern flagJeremy Fitzhardinge-1/+10
This adds `nounused` to the set of extern flags: `--extern nounused:core=/path/to/core/libcore.rlib`. The effect of this flag is to suppress `unused-crate-dependencies` warnings relating to the crate.
2022-04-20Auto merge of #96082 - michaelwoerister:less_impl_stable_hash_via_hash, ↵bors-19/+16
r=compiler-errors incr. comp.: Don't export impl_stable_hash_via_hash!() and warn about using it. Fixes https://github.com/rust-lang/rust/issues/96013.
2022-04-19incr. comp.: Don't export impl_stable_hash_via_hash!() and warn about using it.Michael Woerister-19/+16
2022-04-15Remove `--extern-location` and all associated codeJeremy Fitzhardinge-116/+0
`--extern-location` was an experiment to investigate the best way to generate useful diagnostics for unused dependency warnings by enabling a build system to identify the corresponding build config. While I did successfully use this, I've since been convinced the alternative `--json unused-externs` mechanism is the way to go, and there's no point in having two mechanisms with basically the same functionality. This effectively reverts https://github.com/rust-lang/rust/pull/72603
2022-04-05errors: implement sysroot/testing bundle loadingDavid Wood-0/+2
Extend loading of Fluent bundles so that bundles can be loaded from the sysroot based on the language requested by the user, or using a nightly flag. Sysroot bundles are loaded from `$sysroot/share/locale/$locale/*.ftl`. Signed-off-by: David Wood <david.wood@huawei.com>
2022-04-03Cleanup after some refactoring in rustc_targetLoïc BRANSTETT-1/+1
2022-04-03Replace every Vec in Target(Options) with it's Cow equivalentLoïc BRANSTETT-1/+1
2022-03-30Stabilize native library modifier syntax and the `whole-archive` modifier ↵Vadim Petrochenkov-22/+41
specifically
2022-03-24Prettify rustc_session fmt with capturing args (nfc)Jubilee Young-42/+30
2022-03-18Auto merge of #88098 - Amanieu:oom_panic, r=nagisabors-3/+25
Implement -Z oom=panic This PR removes the `#[rustc_allocator_nounwind]` attribute on `alloc_error_handler` which allows it to unwind with a panic instead of always aborting. This is then used to implement `-Z oom=panic` as per RFC 2116 (tracking issue #43596). Perf and binary size tests show negligible impact.
2022-03-09Add miri to the well known conditional compilation names and valuesLoïc BRANSTETT-5/+10
2022-03-06Update -Z unpretty error messageAlex Macleod-4/+3
Adds `thir-tree`, removes `everybody_loops`
2022-03-04Rollup merge of #94362 - Urgau:check-cfg-values, r=petrochenkovDylan DPC-6/+110
Add well known values to `--check-cfg` implementation This pull-request adds well known values for the well known names via `--check-cfg=values()`. [RFC 3013: Checking conditional compilation at compile time](https://rust-lang.github.io/rfcs/3013-conditional-compilation-checking.html#checking-conditional-compilation-at-compile-time) doesn't define this at all, but this seems a nice improvement. The activation is done by a empty `values()` (new syntax) similar to `names()` except that `names(foo)` also activate well known names while `values(aa, "aa", "kk")` would not. As stated this use a different activation logic because well known values for the well known names are not always sufficient. In fact this is problematic for every `target_*` cfg because of non builtin targets, as the current implementation use those built-ins targets to create the list the well known values. The implementation is straight forward, first we gather (if necessary) all the values (lazily or not) and then we apply them. r? ```@petrochenkov```
2022-03-04Add well known values to --check-cfg implementationLoïc BRANSTETT-5/+102
2022-03-03Remove the everybody loops passbjorn3-5/+2
It isn't used anymore by rustdoc
2022-03-03Add -Z oom={panic,abort} command-line optionAmanieu d'Antras-3/+25
2022-03-03Add support for values() with --check-cfgLoïc BRANSTETT-1/+8
2022-02-23Continue improvements on the --check-cfg implementationLoïc BRANSTETT-11/+11
- Test the combinations of --check-cfg with partial values() and --cfg - Test that we detect unexpected value when none are expected
2022-02-22Improve CheckCfg internal representationLoïc BRANSTETT-23/+25
2022-02-18Rollup merge of #93915 - Urgau:rfc-3013, r=petrochenkovMatthias Krüger-1/+88
Implement --check-cfg option (RFC 3013), take 2 This pull-request implement RFC 3013: Checking conditional compilation at compile time (https://github.com/rust-lang/rfcs/pull/3013) and is based on the previous attempt https://github.com/rust-lang/rust/pull/89346 by `@mwkmwkmwk` that was closed due to inactivity. I have address all the review comments from the previous attempt and added some more tests. cc https://github.com/rust-lang/rust/issues/82450 r? `@petrochenkov`
2022-02-16Implement --check-cfg option (RFC 3013)Loïc BRANSTETT-1/+88
Co-authored-by: Urgau <lolo.branstett@numericable.fr> Co-authored-by: Marcelina Kościelnicka <mwk@0x04.net>
2022-02-14Add support for control-flow protectionAndrew Brown-4/+21
This change adds a flag for configuring control-flow protection in the LLVM backend. In Clang, this flag is exposed as `-fcf-protection` with options `none|branch|return|full`. This convention is followed for `rustc`, though as a codegen option: `rustc -Z cf-protection=<none|branch|return|full>`. Co-authored-by: BlackHoleFox <blackholefoxdev@gmail.com>
2022-02-11Remove the alt_std_name optionbjorn3-2/+0
This option introduced in #15820 allows a custom crate to be imported in the place of std, but with the name std. I don't think there is any value to this. At most it is confusing users of a driver that uses this option. There are no users of this option on github. If anyone still needs it, they can emulate it injecting #![no_core] in addition to their own prelude.
2022-02-04Rollup merge of #90132 - joshtriplett:stabilize-instrument-coverage, ↵Matthias Krüger-14/+40
r=wesleywiser Stabilize `-Z instrument-coverage` as `-C instrument-coverage` (Tracking issue for `instrument-coverage`: https://github.com/rust-lang/rust/issues/79121) This PR stabilizes support for instrumentation-based code coverage, previously provided via the `-Z instrument-coverage` option. (Continue supporting `-Z instrument-coverage` for compatibility for now, but show a deprecation warning for it.) Many, many people have tested this support, and there are numerous reports of it working as expected. Move the documentation from the unstable book to stable rustc documentation. Update uses and documentation to use the `-C` option. Addressing questions raised in the tracking issue: > If/when stabilized, will the compiler flag be updated to -C instrument-coverage? (If so, the -Z variant could also be supported for some time, to ease migrations for existing users and scripts.) This stabilization PR updates the option to `-C` and keeps the `-Z` variant to ease migration. > The Rust coverage implementation depends on (and automatically turns on) -Z symbol-mangling-version=v0. Will stabilizing this feature depend on stabilizing v0 symbol-mangling first? If so, what is the current status and timeline? This stabilization PR depends on https://github.com/rust-lang/rust/pull/90128 , which stabilizes `-C symbol-mangling-version=v0` (but does not change the default symbol-mangling-version). > The Rust coverage implementation implements the latest version of LLVM's Coverage Mapping Format (version 4), which forces a dependency on LLVM 11 or later. A compiler error is generated if attempting to compile with coverage, and using an older version of LLVM. Given that LLVM 13 has now been released, requiring LLVM 11 for coverage support seems like a reasonable requirement. If people don't have at least LLVM 11, nothing else breaks; they just can't use coverage support. Given that coverage support currently requires a nightly compiler and LLVM 11 or newer, allowing it on a stable compiler built with LLVM 11 or newer seems like an improvement. The [tracking issue](https://github.com/rust-lang/rust/issues/79121) and the [issue label A-code-coverage](https://github.com/rust-lang/rust/labels/A-code-coverage) link to a few open issues related to `instrument-coverage`, but none of them seem like showstoppers. All of them seem like improvements and refinements we can make after stabilization. The original `-Z instrument-coverage` support went through a compiler-team MCP at https://github.com/rust-lang/compiler-team/issues/278 . Based on that, `@pnkfelix` suggested that this needed a stabilization PR and a compiler-team FCP.