about summary refs log tree commit diff
path: root/compiler/rustc_feature/src
AgeCommit message (Collapse)AuthorLines
2021-07-16Auto merge of #87201 - GuillaumeGomez:rollup-4loi2q9, r=GuillaumeGomezbors-1/+1
Rollup of 7 pull requests Successful merges: - #87107 (Loop over all opaque types instead of looking at just the first one with the same DefId) - #87158 (Suggest full enum variant for local modules) - #87174 (Stabilize `[T; N]::map()`) - #87179 (Mark `const_trait_impl` as active) - #87180 (feat(rustdoc): open sidebar menu when links inside it are focused) - #87188 (Add GUI test for auto-hide-trait-implementations setting) - #87200 (TAIT: Infer all inference variables in opaque type substitutions via InferCx) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
2021-07-16Make GATs no longer incompleteJack Huey-1/+1
2021-07-16Mark `const_trait_impl` as activeDeadbeef-1/+1
2021-07-13expand: Support helper attributes for built-in derive macrosVadim Petrochenkov-1/+5
2021-07-13Auto merge of #86922 - joshtriplett:target-abi, r=oli-obkbors-0/+4
target abi Implement cfg(target_abi) (RFC 2992) Add an `abi` field to `TargetOptions`, defaulting to "". Support using `cfg(target_abi = "...")` for conditional compilation on that field. Gated by `feature(cfg_target_abi)`. Add a test for `target_abi`, and a test for the feature gate. Add `target_abi` to tidy as a platform-specific cfg. Update targets to use `target_abi` All eabi targets have `target_abi = "eabi".` All eabihf targets have `target_abi = "eabihf"`. `armv6_unknown_freebsd` and `armv7_unknown_freebsd` have `target_abi = "eabihf"`. All abi64 targets have `target_abi = "abi64"`. All ilp32 targets have `target_abi = "ilp32"`. All softfloat targets have `target_abi = "softfloat"`. All *-uwp-windows-* targets have `target_abi = "uwp"`. All spe targets have `target_abi = "spe"`. All macabi targets have `target_abi = "macabi"`. aarch64-apple-ios-sim has `target_abi = "sim"`. `x86_64-fortanix-unknown-sgx` has `target_abi = "fortanix"`. `x86_64-unknown-linux-gnux32` has `target_abi = "x32"`. Add FIXME entries for targets for which existing values need to change once `cfg_target_abi` becomes stable. (All of them are tier 3 targets.) Add a test for `target_abi` in `--print cfg`.
2021-07-13Auto merge of #86857 - fee1-dead:add-attr, r=oli-obkbors-0/+6
Add #[default_method_body_is_const] `@rustbot` label F-const_trait_impl
2021-07-10Applied suggestionsDeadbeef-5/+6
2021-07-10Add #[default_method_body_is_const]Deadbeef-0/+5
2021-07-10remove const_raw_ptr_to_usize_cast featureRalf Jung-3/+4
2021-07-07Implement cfg(target_abi) (RFC 2992)Josh Triplett-0/+4
Add an `abi` field to `TargetOptions`, defaulting to "". Support using `cfg(target_abi = "...")` for conditional compilation on that field. Gated by `feature(cfg_target_abi)`. Add a test for `target_abi`, and a test for the feature gate. Add `target_abi` to tidy as a platform-specific cfg. This does not add an abi to any existing target.
2021-07-07Change linked tracking issue for more qualified pathsRyan Levick-1/+1
2021-06-28Panic on trying to find non-feature incompletenessSmitty-1/+4
2021-06-28Make incomplete features part of delcarationSmitty-44/+38
This prevents mistakes where the feature is in the list of incomplete features but not actually a feature by making the incompleteness a part of the declaration.
2021-06-28Don't make `rustc_insignificant_dtor` feature gateSmitty-1/+0
This isn't a feature gate, it's an attribute that is feature gated behind the `rustc_attrs` attribute. Closes #85680.
2021-06-10Add support for using qualified paths with structs in expression and patternRyan Levick-0/+3
position.
2021-06-06Auto merge of #79608 - alessandrod:bpf, r=nagisabors-0/+1
BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none`, two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target, where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.
2021-06-04changeded bindings_after_at from active to acceptedmarcusdunn-1/+1
2021-06-04updated the feature-gate listingmarcusdunn-4/+3
2021-06-04Remove `doc(include)`Joshua Nelson-3/+4
2021-06-01Auto merge of #85331 - cjgillot:dirty-dancing, r=Aaron1011bors-4/+0
Make rustc_dirty/clean annotations exhaustive by default Fixes #45009
2021-05-30BPF: review fixesAlessandro Decina-1/+1
2021-05-29BPF: fix #[target_feature(enable = "alu32")]Alessandro Decina-0/+1
2021-05-26stabilize member constraintsNiko Matsakis-3/+2
2021-05-24remove native_link_modifiers from the list of incomplete features.12101111-5/+0
2021-05-22stabilize const_fn_unsizeRalf Jung-3/+2
2021-05-18Rollup merge of #83366 - jyn514:stabilize-key-value-attrs, r=petrochenkovJack Huey-3/+2
Stabilize extended_key_value_attributes Closes https://github.com/rust-lang/rust/issues/44732. Closes https://github.com/rust-lang/rust/issues/78835. Closes https://github.com/rust-lang/rust/issues/82768 (by making it irrelevant). # Stabilization report ## Summary This stabilizes using macro expansion in key-value attributes, like so: ```rust #[doc = include_str!("my_doc.md")] struct S; #[path = concat!(env!("OUT_DIR"), "/generated.rs")] mod m; ``` See Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455) for alternatives that were considered and rejected ("why accept no more and no less?") This has been available on nightly since 1.50 with no major issues. ## Notes ### Accepted syntax The parser accepts arbitrary Rust expressions in this position, but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g., `#[doc]`). Note that decorators and the like may be able to observe other expression forms. ### Expansion ordering Expansion of macro expressions in "inert" attributes occurs after decorators have executed, analogously to macro expressions appearing in the function body or other parts of decorator input. There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion, that can work). ## Test cases - https://github.com/rust-lang/rust/blob/master/src/test/ui/attributes/key-value-expansion-on-mac.rs - https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/external-doc.rs The feature has also been dogfooded extensively in the compiler and standard library: - https://github.com/rust-lang/rust/pull/83329 - https://github.com/rust-lang/rust/pull/83230 - https://github.com/rust-lang/rust/pull/82641 - https://github.com/rust-lang/rust/pull/80534 ## Implementation history - Initial proposal: https://github.com/rust-lang/rust/issues/55414#issuecomment-554005412 - Experiment to see how much code it would break: https://github.com/rust-lang/rust/pull/67121 - Preliminary work to restrict expansion that would conflict with this feature: https://github.com/rust-lang/rust/pull/77271 - Initial implementation: https://github.com/rust-lang/rust/pull/78837 - Fix for an ICE: https://github.com/rust-lang/rust/pull/80563 ## Unresolved Questions ~~https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738 listed some concerns, but they have been resolved as of this final report.~~ ## Additional Information There are two workarounds that have a similar effect for `#[doc]` attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons: ```rust macro_rules! forward_inner_docs { ($e:expr => $i:item) => { #[doc = $e] $i }; } forward_inner_docs!(include_str!("lib.rs") => struct S {}); ``` This also works for other attributes (like `#[path = concat!(...)]`). The other is to use `doc(include)`: ```rust #![feature(external_doc)] #[doc(include = "lib.rs")] struct S {} ``` The first works, but is non-trivial for people to discover, and difficult to read and maintain. The second is a strange special-case for a particular use of the macro. This generalizes it to work for any use case, not just including files. I plan to remove `doc(include)` when this is stabilized (https://github.com/rust-lang/rust/pull/82539). The `forward_inner_docs` workaround will still compile without warnings, but I expect it to be used less once it's no longer necessary.
2021-05-18Rollup merge of #85251 - BoxyUwU:constparamdefaultsany%, r=lcnrRalf Jung-1/+0
Make `const_generics_defaults` not an incomplete feature r? `@lcnr`
2021-05-18Stabilize extended_key_value_attributesJoshua Nelson-3/+2
# Stabilization report ## Summary This stabilizes using macro expansion in key-value attributes, like so: ```rust #[doc = include_str!("my_doc.md")] struct S; #[path = concat!(env!("OUT_DIR"), "/generated.rs")] mod m; ``` See the changes to the reference for details on what macros are allowed; see Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455) for alternatives that were considered and rejected ("why accept no more and no less?") This has been available on nightly since 1.50 with no major issues. ## Notes ### Accepted syntax The parser accepts arbitrary Rust expressions in this position, but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g., `#[doc]`). Note that decorators and the like may be able to observe other expression forms. ### Expansion ordering Expansion of macro expressions in "inert" attributes occurs after decorators have executed, analogously to macro expressions appearing in the function body or other parts of decorator input. There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion, that can work). ## Test cases - https://github.com/rust-lang/rust/blob/master/src/test/ui/attributes/key-value-expansion-on-mac.rs - https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/external-doc.rs The feature has also been dogfooded extensively in the compiler and standard library: - https://github.com/rust-lang/rust/pull/83329 - https://github.com/rust-lang/rust/pull/83230 - https://github.com/rust-lang/rust/pull/82641 - https://github.com/rust-lang/rust/pull/80534 ## Implementation history - Initial proposal: https://github.com/rust-lang/rust/issues/55414#issuecomment-554005412 - Experiment to see how much code it would break: https://github.com/rust-lang/rust/pull/67121 - Preliminary work to restrict expansion that would conflict with this feature: https://github.com/rust-lang/rust/pull/77271 - Initial implementation: https://github.com/rust-lang/rust/pull/78837 - Fix for an ICE: https://github.com/rust-lang/rust/pull/80563 ## Unresolved Questions ~~https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738 listed some concerns, but they have been resolved as of this final report.~~ ## Additional Information There are two workarounds that have a similar effect for `#[doc]` attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons: ```rust macro_rules! forward_inner_docs { ($e:expr => $i:item) => { #[doc = $e] $i }; } forward_inner_docs!(include_str!("lib.rs") => struct S {}); ``` This also works for other attributes (like `#[path = concat!(...)]`). The other is to use `doc(include)`: ```rust #![feature(external_doc)] #[doc(include = "lib.rs")] struct S {} ``` The first works, but is non-trivial for people to discover, and difficult to read and maintain. The second is a strange special-case for a particular use of the macro. This generalizes it to work for any use case, not just including files. I plan to remove `doc(include)` when this is stabilized. The `forward_inner_docs` workaround will still compile without warnings, but I expect it to be used less once it's no longer necessary.
2021-05-17Auto merge of #84571 - jedel1043:issue-49804-impl, r=petrochenkovbors-0/+4
Parse unnamed fields of struct and union type Added the `unnamed_fields` feature gate. This is a prototype of [RFC 2102](https://github.com/rust-lang/rust/issues/49804), so any suggestions are greatly appreciated. r? `@petrochenkov`
2021-05-16Add tracking issueJonas Schievink-1/+1
2021-05-16Implement Anonymous{Struct, Union} in the ASTjedel1043-0/+4
Add unnamed_fields feature gate and gate unnamed fields on parsing
2021-05-16Remove remains of rustc_dirty.Camille GILLOT-4/+0
2021-05-16Allow `async {}` expressions in const contextsJonas Schievink-0/+3
2021-05-14add new attribute rustc_insignificant_dtor and a query to check if a type ↵Dhruv Jauhar-0/+2
has a significant drop
2021-05-13Auto merge of #85186 - nikomatsakis:issue-83538-polluted-cache, r=jackh726bors-0/+1
have on_completion record subcycles have on_completion record subcycles Rework `on_completion` method so that it removes all provisional cache entries that are "below" a completed node (while leaving those entries that are not below the node). This corrects an imprecise result that could in turn lead to an incremental compilation failure. Under the old scheme, if you had: * A depends on... * B depends on A * C depends on... * D depends on C * T: 'static then the provisional results for A, B, C, and D would all be entangled. Thus, if A was `EvaluatedToOkModuloRegions` (because of that final condition), then the result for C and D would also be demoted to "ok modulo regions". In reality, though, the result for C depends only on C and itself, and is not dependent on regions. If we happen to evaluate the cycle starting from C, we would never reach A, and hence the result would be "ok". Under the new scheme, the provisional results for C and D are moved to the permanent cache immediately and are not affected by the result of A. Fixes #83538 r? `@Aaron1011`
2021-05-13completion uwuEllen-1/+0
2021-05-13introduce a unit testing feature `rustc_evaluate_where_clauses`Niko Matsakis-0/+1
This attribute will cause us to invoke evaluate on every where clause of an invoked function and to generate an error with the result. Without this, it is very difficult to observe the effects of invoking the trait evaluator.
2021-05-12entirely remove rustc_args_required_const attributeRalf Jung-1/+0
2021-05-09remove const_fn feature gateRalf Jung-3/+3
2021-05-07Rollup merge of #84871 - richkadel:no-coverage-unstable-only, r=nagisaDylan DPC-7/+1
Disallows `#![feature(no_coverage)]` on stable and beta (using standard crate-level gating) Fixes: #84836 Removes the function-level feature gating solution originally implemented, and solves the same problem using `allow_internal_unstable`, so normal crate-level feature gating mechanism can still be used (which disallows the feature on stable and beta). I tested this, building the compiler with and without `CFG_DISABLE_UNSTABLE_FEATURES=1` With unstable features disabled, I get the expected result as shown here: ```shell $ ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc src/test/run-make-fulldeps/coverage/no_cov_crate.rs error[E0554]: `#![feature]` may not be used on the dev release channel --> src/test/run-make-fulldeps/coverage/no_cov_crate.rs:2:1 | 2 | #![feature(no_coverage)] | ^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0554`. ``` r? ````@Mark-Simulacrum```` cc: ````@tmandry```` ````@wesleywiser````
2021-05-05Implement RFC 2951: Native link modifiersLuqman Aden-0/+20
This commit implements both the native linking modifiers infrastructure as well as an initial attempt at the individual modifiers from the RFC. It also introduces a feature flag for the general syntax along with individual feature flags for each modifier.
2021-05-05Disallows `#![feature(no_coverage)]` on stable and betaRich Kadel-7/+1
using allow_internal_unstable (as recommended) Fixes: #84836 ```shell $ ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc src/test/run-make-fulldeps/coverage/no_cov_crate.rs error[E0554]: `#![feature]` may not be used on the dev release channel --> src/test/run-make-fulldeps/coverage/no_cov_crate.rs:2:1 | 2 | #![feature(no_coverage)] | ^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0554`. ```
2021-04-30Auto merge of #84401 - crlf0710:impl_main_by_path, r=petrochenkovbors-0/+3
Implement RFC 1260 with feature_name `imported_main`. This is the second extraction part of #84062 plus additional adjustments. This (mostly) implements RFC 1260. However there's still one test case failure in the extern crate case. Maybe `LocalDefId` doesn't work here? I'm not sure. cc https://github.com/rust-lang/rust/issues/28937 r? `@petrochenkov`
2021-04-29Implement RFC 1260 with feature_name `imported_main`.Charles Lew-0/+3
2021-04-28Auto merge of #83386 - mark-i-m:stabilize-pat2015, r=nikomatsakisbors-3/+0
Stabilize `:pat_param` and remove `:pat2021` Blocked on #83384 cc `@rust-lang/lang` #79278 If I understand `@nikomatsakis` in https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/or.20patterns/near/231133873, another FCP is not needed. r? `@nikomatsakis`
2021-04-28Auto merge of #84562 - richkadel:issue-83601, r=tmandrybors-0/+11
Adds feature-gated `#[no_coverage]` function attribute, to fix derived Eq `0` coverage issue #83601 Derived Eq no longer shows uncovered The Eq trait has a special hidden function. MIR `InstrumentCoverage` would add this function to the coverage map, but it is never called, so the `Eq` trait would always appear uncovered. Fixes: #83601 The fix required creating a new function attribute `no_coverage` to mark functions that should be ignored by `InstrumentCoverage` and the coverage `mapgen` (during codegen). Adding a `no_coverage` feature gate with tracking issue #84605. r? `@tmandry` cc: `@wesleywiser`
2021-04-28Auto merge of #83713 - spastorino:revert-pub-macro-rules, r=nikomatsakisbors-3/+2
Revert "Rollup merge of #82296 - spastorino:pubrules, r=nikomatsakis" This reverts commit e2561c58a41023a14e0e583113dcf55e1ecb236a, reversing changes made to 2982ba50fc4bb629b8fe4108a81cb2f9b053510b. As discussed in #83641 this feature is not complete and in particular doesn't work cross macros and given that this is not going to be included in edition 2021 nobody seems to be trying to fix the underlying problem. When can add this again I guess, whenever somebody has the time to make it work cross crates. r? `@nikomatsakis`
2021-04-27remove pat2021mark-3/+0
2021-04-27adds feature gating of `no_coverage` at either crate- or function-levelRich Kadel-1/+11
2021-04-27Derived Eq no longer shows uncoveredRich Kadel-0/+1
The Eq trait has a special hidden function. MIR `InstrumentCoverage` would add this function to the coverage map, but it is never called, so the `Eq` trait would always appear uncovered. Fixes: #83601 The fix required creating a new function attribute `no_coverage` to mark functions that should be ignored by `InstrumentCoverage` and the coverage `mapgen` (during codegen). While testing, I also noticed two other issues: * spanview debug file output ICEd on a function with no body. The workaround for this is included in this PR. * `assert_*!()` macro coverage can appear covered if followed by another `assert_*!()` macro. Normally they appear uncovered. I submitted a new Issue #84561, and added a coverage test to demonstrate this issue.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-03-02 17:19:19 +0000