summary refs log tree commit diff
path: root/compiler/rustc_feature/src/active.rs
AgeCommit message (Collapse)AuthorLines
2023-10-02Bump version placeholdersMark Rousskov-3/+3
2023-09-29Auto merge of #113301 - Be-ing:stabilize_bundle_whole-archive, r=petrochenkovbors-2/+0
stabilize combining +bundle and +whole-archive link modifiers Per discussion on https://github.com/rust-lang/rust/issues/108081 combining +bundle and +whole-archive already works and can be stabilized independently of other aspects of the packed_bundled_libs feature. There is no risk of regression because this was not previously allowed. r? `@petrochenkov`
2023-09-28Auto merge of #115659 - compiler-errors:itp, r=cjgillotbors-2/+0
Stabilize `impl_trait_projections` Closes #115659 ## TL;DR: This allows us to mention `Self` and `T::Assoc` in async fn and return-position `impl Trait`, as you would expect you'd be able to. Some examples: ```rust #![feature(return_position_impl_trait_in_trait, async_fn_in_trait)] // (just needed for final tests below) // ---------------------------------------- // struct Wrapper<'a, T>(&'a T); impl Wrapper<'_, ()> { async fn async_fn() -> Self { //^ Previously rejected because it returns `-> Self`, not `-> Wrapper<'_, ()>`. Wrapper(&()) } fn impl_trait() -> impl Iterator<Item = Self> { //^ Previously rejected because it mentions `Self`, not `Wrapper<'_, ()>`. std::iter::once(Wrapper(&())) } } // ---------------------------------------- // trait Trait<'a> { type Assoc; fn new() -> Self::Assoc; } impl Trait<'_> for () { type Assoc = (); fn new() {} } impl<'a, T: Trait<'a>> Wrapper<'a, T> { async fn mk_assoc() -> T::Assoc { //^ Previously rejected because `T::Assoc` doesn't mention `'a` in the HIR, // but ends up resolving to `<T as Trait<'a>>::Assoc`, which does rely on `'a`. // That's the important part -- the elided trait. T::new() } fn a_few_assocs() -> impl Iterator<Item = T::Assoc> { //^ Previously rejected for the same reason [T::new(), T::new(), T::new()].into_iter() } } // ---------------------------------------- // trait InTrait { async fn async_fn() -> Self; fn impl_trait() -> impl Iterator<Item = Self>; } impl InTrait for &() { async fn async_fn() -> Self { &() } //^ Previously rejected just like inherent impls fn impl_trait() -> impl Iterator<Item = Self> { //^ Previously rejected just like inherent impls [&()].into_iter() } } ``` ## Technical: Lifetimes in return-position `impl Trait` (and `async fn`) are duplicated as early-bound generics local to the opaque in order to make sure we are able to substitute any late-bound lifetimes from the function in the opaque's hidden type. (The [dev guide](https://rustc-dev-guide.rust-lang.org/return-position-impl-trait-in-trait.html#aside-opaque-lifetime-duplication) has a small section about why this is necessary -- this was written for RPITITs, but it applies to all RPITs) Prior to #103491, all of the early-bound lifetimes not local to the opaque were replaced with `'static` to avoid issues where relating opaques caused their *non-captured* lifetimes to be related. This `'static` replacement led to strange and possibly unsound behaviors (https://github.com/rust-lang/rust/issues/61949#issuecomment-508836314) (https://github.com/rust-lang/rust/issues/53613) when referencing the `Self` type alias in an impl or indirectly referencing a lifetime parameter via a projection type (via a `T::Assoc` projection without an explicit trait), since lifetime resolution is performed on the HIR, when neither `T::Assoc`-style projections or `Self` in impls are expanded. Therefore an error was implemented in #62849 to deny this subtle behavior as a known limitation of the compiler. It was attempted by `@cjgillot` to fix this in #91403, which was subsequently unlanded. Then it was re-attempted to much success (🎉) in #103491, which is where we currently are in the compiler. The PR above (#103491) fixed this issue technically by *not* replacing the opaque's parent lifetimes with `'static`, but instead using variance to properly track which lifetimes are captured and are not. The PR gated any of the "side-effects" of the PR behind a feature gate (`impl_trait_projections`) presumably to avoid having to involve T-lang or T-types in the PR as well. `@cjgillot` can clarify this if I'm misunderstanding what their intention was with the feature gate. Since we're not replacing (possibly *invariant*!) lifetimes with `'static` anymore, there are no more soundness concerns here. Therefore, this PR removes the feature gate. Tests: * `tests/ui/async-await/feature-self-return-type.rs` * `tests/ui/impl-trait/feature-self-return-type.rs` * `tests/ui/async-await/issues/issue-78600.rs` * `tests/ui/impl-trait/capture-lifetime-not-in-hir.rs` --- r? cjgillot on the impl (not much, just removing the feature gate) I'm gonna mark this as FCP for T-lang and T-types.
2023-09-23also make platform_intrinsics internalRalf Jung-2/+2
2023-09-23make link_llvm_intrinsics feature internalRalf Jung-1/+1
2023-09-17Auto merge of #114452 - weiznich:feature/diagnostic_on_unimplemented, ↵bors-1/+1
r=compiler-errors `#[diagnostic::on_unimplemented]` without filters This commit adds support for a `#[diagnostic::on_unimplemented]` attribute with the following options: * `message` to customize the primary error message * `note` to add a customized note message to an error message * `label` to customize the label part of the error message The relevant behavior is specified in [RFC-3366](https://rust-lang.github.io/rfcs/3366-diagnostic-attribute-namespace.html)
2023-09-15Implement custom classes for rustdoc code blocks with ↵Guillaume Gomez-0/+2
`custom_code_classes_in_docs` feature
2023-09-12`#[diagnostic::on_unimplemented]` without filtersGeorg Semmler-1/+1
This commit adds support for a `#[diagnostic::on_unimplemented]` attribute with the following options: * `message` to customize the primary error message * `note` to add a customized note message to an error message * `label` to customize the label part of the error message Co-authored-by: León Orell Valerian Liehr <me@fmease.dev> Co-authored-by: Michael Goulet <michael@errs.io>
2023-09-08Rename the feature, but not the attribute, to `coverage_attribute`Andy Caldwell-1/+1
2023-09-08Add `no_coverage` to the 'removed features' listAndy Caldwell-1/+1
2023-09-08Rework no_coverage to coverage(off)Andy Caldwell-3/+3
2023-09-08Stabilize impl_trait_projectionsMichael Goulet-2/+0
2023-08-24Auto merge of #115131 - frank-king:feature/unnamed-fields-lite, r=petrochenkovbors-0/+2
Parse unnamed fields and anonymous structs or unions (no-recovery) It is part of #114782 which implements #49804. Only parse anonymous structs or unions in struct field definition positions. r? `@petrochenkov`
2023-08-24Parse unnamed fields and anonymous structs or unionsFrank King-0/+2
Anonymous structs or unions are only allowed in struct field definitions. Co-authored-by: carbotaniuman <41451839+carbotaniuman@users.noreply.github.com>
2023-08-22Replace version placeholders with 1.73.0Mark Rousskov-6/+6
2023-08-18Add the relocation_model to the cfgLuca Barbato-0/+2
This way is possible to write inline assembly code aware of it.
2023-08-15stabilize combining +bundle and +whole-archive link modifiersBe Wilson-2/+0
Currently, combining +bundle and +whole-archive works only with #![feature(packed_bundled_libs)] This crate feature is independent of the -Zpacked-bundled-libs command line option. This commit stabilizes the #![feature(packed_bundled_libs)] crate feature and implicitly enables it only when the +bundle and +whole-archive link modifiers are combined. This allows rlib crates to use the +whole-archive link modifier with native libraries and have all symbols included in the linked library to be included in downstream staticlib crates that use the rlib as a dependency. Other cases requiring the packed_bundled_libs behavior still require the -Zpacked-bundled-libs command line option, which can be stabilized independently in the future. Per discussion on https://github.com/rust-lang/rust/issues/108081 there is no risk of regression stabilizing the crate feature in this way because the combination of +bundle,+whole-archive link modifiers was previously not allowed.
2023-08-15Update compiler/rustc_feature/src/active.rsDirreck-1/+1
Co-authored-by: klensy <klensy@users.noreply.github.com>
2023-08-14add `rustc_codegen_ssa` support for csky and correct some codeDirreke-0/+1
2023-08-08feat: `riscv-interrupt-{m,s}` calling conventionsSeth Pellegrino-0/+2
Similar to prior support added for the mips430, avr, and x86 targets this change implements the rough equivalent of clang's [`__attribute__((interrupt))`][clang-attr] for riscv targets, enabling e.g. ```rust static mut CNT: usize = 0; pub extern "riscv-interrupt-m" fn isr_m() { unsafe { CNT += 1; } } ``` to produce highly effective assembly like: ```asm pub extern "riscv-interrupt-m" fn isr_m() { 420003a0: 1141 addi sp,sp,-16 unsafe { CNT += 1; 420003a2: c62a sw a0,12(sp) 420003a4: c42e sw a1,8(sp) 420003a6: 3fc80537 lui a0,0x3fc80 420003aa: 63c52583 lw a1,1596(a0) # 3fc8063c <_ZN12esp_riscv_rt3CNT17hcec3e3a214887d53E.0> 420003ae: 0585 addi a1,a1,1 420003b0: 62b52e23 sw a1,1596(a0) } } 420003b4: 4532 lw a0,12(sp) 420003b6: 45a2 lw a1,8(sp) 420003b8: 0141 addi sp,sp,16 420003ba: 30200073 mret ``` (disassembly via `riscv64-unknown-elf-objdump -C -S --disassemble ./esp32c3-hal/target/riscv32imc-unknown-none-elf/release/examples/gpio_interrupt`) This outcome is superior to hand-coded interrupt routines which, lacking visibility into any non-assembly body of the interrupt handler, have to be very conservative and save the [entire CPU state to the stack frame][full-frame-save]. By instead asking LLVM to only save the registers that it uses, we defer the decision to the tool with the best context: it can more accurately account for the cost of spills if it knows that every additional register used is already at the cost of an implicit spill. At the LLVM level, this is apparently [implemented by] marking every register as "[callee-save]," matching the semantics of an interrupt handler nicely (it has to leave the CPU state just as it found it after its `{m|s}ret`). This approach is not suitable for every interrupt handler, as it makes no attempt to e.g. save the state in a user-accessible stack frame. For a full discussion of those challenges and tradeoffs, please refer to [the interrupt calling conventions RFC][rfc]. Inside rustc, this implementation differs from prior art because LLVM does not expose the "all-saved" function flavor as a calling convention directly, instead preferring to use an attribute that allows for differentiating between "machine-mode" and "superivsor-mode" interrupts. Finally, some effort has been made to guide those who may not yet be aware of the differences between machine-mode and supervisor-mode interrupts as to why no `riscv-interrupt` calling convention is exposed through rustc, and similarly for why `riscv-interrupt-u` makes no appearance (as it would complicate future LLVM upgrades). [clang-attr]: https://clang.llvm.org/docs/AttributeReference.html#interrupt-risc-v [full-frame-save]: https://github.com/esp-rs/esp-riscv-rt/blob/9281af2ecffe13e40992917316f36920c26acaf3/src/lib.rs#L440-L469 [implemented by]: https://github.com/llvm/llvm-project/blob/b7fb2a3fec7c187d58a6d338ab512d9173bca987/llvm/lib/Target/RISCV/RISCVRegisterInfo.cpp#L61-L67 [callee-save]: https://github.com/llvm/llvm-project/blob/973f1fe7a8591c7af148e573491ab68cc15b6ecf/llvm/lib/Target/RISCV/RISCVCallingConv.td#L30-L37 [rfc]: https://github.com/rust-lang/rfcs/pull/3246
2023-08-07stabilize abi_thiscallBenedikt Radtke-2/+0
2023-08-04Auto merge of #112117 - bryangarza:track-caller-feature-gate, r=compiler-errorsbors-0/+2
Add separate feature gate for async fn track caller This patch adds a feature gate `async_fn_track_caller` that is separate from `closure_track_caller`. This is to allow enabling `async_fn_track_caller` separately. Fixes #110009
2023-08-03Add `internal_features` lintNilstrieb-25/+51
It lints against features that are inteded to be internal to the compiler and standard library. Implements MCP #596. We allow `internal_features` in the standard library and compiler as those use many features and this _is_ the standard library from the "internal to the compiler and standard library" after all. Marking some features as internal wasn't exactly the most scientific approach, I just marked some mostly obvious features. While there is a categorization in the macro, it's not very well upheld (should probably be fixed in another PR). We always pass `-Ainternal_features` in the testsuite About 400 UI tests and several other tests use internal features. Instead of throwing the attribute on each one, just always allow them. There's nothing wrong with testing internal features^^
2023-08-02Add separate feature gate for async fn track callerBryan Garza-0/+2
This patch adds a feature gate `async_fn_track_caller` that is separate from `closure_track_caller`. This is to allow enabling `async_fn_track_caller` separately. Fixes #110009
2023-07-29Mark lazy_type_alias as incompleteMichael Goulet-1/+1
2023-07-28Parse generic const itemsLeón Orell Valerian Liehr-0/+2
2023-07-28Introduce the `#[diagnostic]` attribute namespaceGeorg Semmler-0/+2
Co-authored-by: est31 <est31@users.noreply.github.com> Co-authored-by: Esteban Kuber <estebank@users.noreply.github.com> Co-authored-by: Vadim Petrochenkov <vadim.petrochenkov@gmail.com>
2023-07-12Replace version placeholder to 1.72Mark Rousskov-4/+4
2023-07-04Add feature and attribute definitionDeadbeef-0/+2
2023-06-29Rollup merge of #112670 - petrochenkov:typriv, r=eholkMatthias Krüger-0/+2
privacy: Type privacy lints fixes and cleanups See individual commits. Follow up to https://github.com/rust-lang/rust/pull/111801.
2023-06-21Rollup merge of #112853 - GuillaumeGomez:type_alias_type, r=oli-obkGuillaume Gomez-0/+2
Add `lazy_type_alias` feature gate Add the `type_alias_type` to be able to have the weak alias used without restrictions. Part of #112792. cc `@compiler-errors` r? `@oli-obk`
2023-06-21Add `lazy_type_alias` feature gateGuillaume Gomez-0/+2
2023-06-19Syntatically accept `become` expressionsMaybe Waffle-0/+2
2023-06-15privacy: Feature gate new type privacy lintsVadim Petrochenkov-0/+2
2023-06-01Auto merge of #103877 - oli-obk:const_eval_step_limit, r=fee1-deadbors-2/+0
Replace const eval limit by a lint and add an exponential backoff warning The lint triggers at the first power of 2 that comes after 1 million function calls or traversed back-edges (takes less than a second on usual programs). After the first emission, an unsilenceable warning is repeated at every following power of 2 terminators, causing it to get reported less and less the longer the evaluation runs. cc `@rust-lang/wg-const-eval` fixes #93481 closes #67217
2023-05-31Remove const eval limit and implement an exponential backoff lint insteadOli Scherer-2/+0
2023-05-30Swap out CURRENT_RUSTC_VERSION to 1.71.0Mark Rousskov-5/+5
2023-05-15fixup version placeholder for cfi_encoding featureklensy-1/+1
2023-05-11Add support for `cfg(overflow_checks)`AngelicosPhosphoros-0/+2
This PR adds support for detecting if overflow checks are enabled in similar fashion as debug_assertions are detected. Possible use-case of this, for example, if we want to use checked integer casts in builds with overflow checks, e.g. ```rust pub fn cast(val: usize)->u16 { if cfg!(overflow_checks) { val.try_into().unwrap() } else{ vas as _ } } ``` Resolves #91130. Tracking issue: #111466.
2023-05-09Rollup merge of #110694 - est31:builtin, r=petrochenkovDylan DPC-0/+2
Implement builtin # syntax and use it for offset_of!(...) Add `builtin #` syntax to the parser, as well as a generic infrastructure to support both item and expression position builtin syntaxes. The PR also uses this infrastructure for the implementation of the `offset_of!` macro, added by #106934. cc `@petrochenkov` `@DrMeepster` cc #110680 `builtin #` tracking issue cc #106655 `offset_of!` tracking issue
2023-05-06Rollup merge of #109677 - dpaoliello:rawdylib, r=michaelwoerister,wesleywiserYuki Okushi-2/+0
Stabilize raw-dylib, link_ordinal, import_name_type and -Cdlltool This stabilizes the `raw-dylib` feature (#58713) for all architectures (i.e., `x86` as it is already stable for all other architectures). Changes: * Permit the use of the `raw-dylib` link kind for x86, the `link_ordinal` attribute and the `import_name_type` key for the `link` attribute. * Mark the `raw_dylib` feature as stable. * Stabilized the `-Zdlltool` argument as `-Cdlltool`. * Note the path to `dlltool` if invoking it failed (we don't need to do this if `dlltool` returns an error since it prints its path in the error message). * Adds tests for `-Cdlltool`. * Adds tests for being unable to find the dlltool executable, and dlltool failing. * Fixes a bug where we were checking the exit code of dlltool to see if it failed, but dlltool always returns 0 (indicating success), so instead we need to check if anything was written to `stderr`. NOTE: As previously noted (https://github.com/rust-lang/rust/pull/104218#issuecomment-1315895618) using dlltool within rustc is temporary, but this is not the first time that Rust has added a temporary tool use and argument: https://github.com/rust-lang/rust/pull/104218#issuecomment-1318720482 Big thanks to ``````@tbu-`````` for the first version of this PR (#104218)
2023-05-05Add feature gateest31-0/+2
2023-05-05Rollup merge of #108801 - fee1-dead-contrib:c-str, r=compiler-errorsDylan DPC-0/+2
Implement RFC 3348, `c"foo"` literals RFC: https://github.com/rust-lang/rfcs/pull/3348 Tracking issue: #105723
2023-05-03Rollup merge of #105452 - rcvalle:rust-cfi-3, r=bjorn3Manish Goregaokar-0/+2
Add cross-language LLVM CFI support to the Rust compiler This PR adds cross-language LLVM Control Flow Integrity (CFI) support to the Rust compiler by adding the `-Zsanitizer-cfi-normalize-integers` option to be used with Clang `-fsanitize-cfi-icall-normalize-integers` for normalizing integer types (see https://reviews.llvm.org/D139395). It provides forward-edge control flow protection for C or C++ and Rust -compiled code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code share the same virtual address space). For more information about LLVM CFI and cross-language LLVM CFI support for the Rust compiler, see design document in the tracking issue #89653. Cross-language LLVM CFI can be enabled with -Zsanitizer=cfi and -Zsanitizer-cfi-normalize-integers, and requires proper (i.e., non-rustc) LTO (i.e., -Clinker-plugin-lto). Thank you again, ``@bjorn3,`` ``@nikic,`` ``@samitolvanen,`` and the Rust community for all the help!
2023-05-03Add cross-language LLVM CFI support to the Rust compilerRamon de C Valle-0/+2
This commit adds cross-language LLVM Control Flow Integrity (CFI) support to the Rust compiler by adding the `-Zsanitizer-cfi-normalize-integers` option to be used with Clang `-fsanitize-cfi-icall-normalize-integers` for normalizing integer types (see https://reviews.llvm.org/D139395). It provides forward-edge control flow protection for C or C++ and Rust -compiled code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code share the same virtual address space). For more information about LLVM CFI and cross-language LLVM CFI support for the Rust compiler, see design document in the tracking issue #89653. Cross-language LLVM CFI can be enabled with -Zsanitizer=cfi and -Zsanitizer-cfi-normalize-integers, and requires proper (i.e., non-rustc) LTO (i.e., -Clinker-plugin-lto).
2023-05-02Implement negative boundsMichael Goulet-0/+2
2023-05-02fix TODO commentsDeadbeef-2/+2
2023-05-02update and add a few testsDeadbeef-0/+2
2023-05-02Rollup merge of #111048 - compiler-errors:rpitit-not-incomplete, r=jackh726Dylan DPC-2/+2
Mark`feature(return_position_impl_trait_in_trait)` and`feature(async_fn_in_trait)` as not incomplete I think they've graduated, since as far as I'm aware, they don't cause compiler crashes or unsoundness anymore.
2023-05-02Rollup merge of #108668 - gibbyfree:stabilizedebuggervisualizer, r=wesleywiserDylan DPC-2/+0
Stabilize debugger_visualizer This stabilizes the `debugger_visualizer` attribute (#95939). * Marks the `debugger_visualizer` feature as `accepted`. * Marks the `debugger_visualizer` attribute as `ungated`. * Deletes feature gate test, removes feature gate from other tests. Closes #95939