0
0
mirror of https://github.com/rust-lang/rust.git synced 2024-11-22 10:25:09 +01:00
Commit Graph

1556 Commits

Author SHA1 Message Date
Matthias Krüger
4a699fc475
Rollup merge of #132541 - RalfJung:const-stable-extern-crate, r=compiler-errors
Proper support for cross-crate recursive const stability checks

~~Stacked on top of https://github.com/rust-lang/rust/pull/132492; only the last three commits are new.~~

In a crate without `staged_api` but with `-Zforce-unstable-if-unmarked`, we now subject all functions marked with `#[rustc_const_stable_indirect]` to recursive const stability checks. We require an opt-in so that by default, a crate can be built with `-Zforce-unstable-if-unmarked` and use nightly features as usual. This property is recorded in the crate metadata so when a `staged_api` crate calls such a function, it sees the `#[rustc_const_stable_indirect]` and allows it to be exposed on stable. This, finally, will let us expose `const fn` from hashbrown on stable.

The second commit makes const stability more like regular stability: via `check_missing_const_stability`, we ensure that all publicly reachable functions have a const stability attribute -- both in  `staged_api` crates and `-Zforce-unstable-if-unmarked` crates. To achieve this, we move around the stability computation so that const stability is computed after regular stability is done. This lets us access the final result of the regular stability computation, which we use so that `const fn` can inherit the regular stability (but only if that is "unstable"). Fortunately, this lets us get rid of an `Option` in `ConstStability`.

This is the last PR that I have planned in this series.

r? `@compiler-errors`
2024-11-12 18:11:04 +01:00
bors
d4822c2d84 Auto merge of #127589 - notriddle:notriddle/search-sem-3, r=GuillaumeGomez
rustdoc-search: simplify rules for generics and type params

**Heads up!**: This PR is a follow-up that depends on #124544. It adds 12dc24f460, a change to the filtering behavior, and 9900ea48b5, a minor ranking tweak.

Part of https://github.com/rust-lang/rust-project-goals/issues/112

This PR overturns https://github.com/rust-lang/rust/pull/109802

## Preview

* no results: [`Box<[A]> -> Vec<B>`](http://notriddle.com/rustdoc-html-demo-12/search-sem-3/std/index.html?search=Box%3C%5BA%5D%3E%20-%3E%20Vec%3CB%3E)
* results: [`Box<[A]> -> Vec<A>`](http://notriddle.com/rustdoc-html-demo-12/search-sem-3/std/index.html?search=Box%3C%5BA%5D%3E%20-%3E%20Vec%3CA%3E)
* [`T -> U`](http://notriddle.com/rustdoc-html-demo-12/search-sem-3/std/index.html?search=T%20-%3E%20U)
* [`Cx -> TyCtxt`](http://notriddle.com/rustdoc-html-demo-12/search-sem-3-compiler/rustdoc/index.html?search=Cx%20-%3E%20TyCtxt)

![image](https://github.com/user-attachments/assets/015ae28c-7469-4f7f-be03-157d28d7ec97)

## Description

This commit is a response to feedback on the displayed type signatures results, by making generics act stricter.

- Order within generics is significant. This means `Vec<Allocator>` now matches only with a true vector of allocators, instead of matching the second type param. It also makes unboxing within generics stricter, so `Result<A, B>` only matches if `B` is in the error type and `A` is in the success type. The top level of the function search is unaffected.
- Generics are only "unboxed" if a type is explicitly opted into it. References and tuples are hardcoded to allow unboxing, and Box, Rc, Arc, Option, Result, and Future are opted in with an unstable attribute. Search result unboxing is the process that allows you to search for `i32 -> str` and get back a function with the type signature `&Future<i32> -> Box<str>`.
- Instead of ranking by set overlap, it ranks by the number of items in the type signature. This makes it easier to find single type signatures like transmute.

## Find the discussion on

* <https://rust-lang.zulipchat.com/#narrow/stream/393423-t-rustdoc.2Fmeetings/topic/meeting.202024-07-08/near/449965149>
* <https://github.com/rust-lang/rust/pull/124544#issuecomment-2204272265>
* <https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/deciding.20on.20semantics.20of.20generics.20in.20rustdoc.20search>
2024-11-11 12:26:00 +00:00
Ralf Jung
e96808162a ensure that all publicly reachable const fn have const stability info 2024-11-10 10:16:26 +01:00
Ralf Jung
686eeb83e9 honor rustc_const_stable_indirect in non-staged_api crate with -Zforce-unstable-if-unmarked 2024-11-10 10:01:27 +01:00
Ralf Jung
e3010e84db remove support for rustc_safe_intrinsic attribute; use rustc_intrinsic functions instead 2024-11-08 09:16:00 +01:00
Ralf Jung
10723c2896 remove support for extern-block const intrinsics 2024-11-04 23:27:45 +01:00
Jubilee
759e80d019
Rollup merge of #132576 - jdonszelmann:no-attrid-in-stats, r=nnethercote
remove attribute ids from hir stats (they're simply not needed)

Turns out these are simply not needed. Yay!

r? `@nnethercote`
2024-11-03 20:08:15 -08:00
Jonathan Dönszelmann
efaf9ab430
remove attribute ids from hir stats (they're simply not needed) 2024-11-03 22:14:54 +01:00
Michael Goulet
6b96103bf3 Rename the FIXMEs, remove a few that dont matter anymore 2024-11-03 18:59:41 +00:00
Jubilee
847b6fe6b0
Rollup merge of #132246 - workingjubilee:campaign-on-irform, r=compiler-errors
Rename `rustc_abi::Abi` to `BackendRepr`

Remove the confabulation of `rustc_abi::Abi` with what "ABI" actually means by renaming it to `BackendRepr`, and rename `Abi::Aggregate` to `BackendRepr::Memory`. The type never actually represented how things are passed, as that has to have `PassMode` considered, at minimum, but rather it just is how we represented some things to the backend. This conflation arose because LLVM, the primary backend at the time, would lower certain IR forms using certain ABIs. Even that only somewhat was true, as it broke down when one ventured significantly afield of what is described by the System V AMD64 ABI either by using different architectures, ABI-modifying IR annotations, the same architecture **with different ISA extensions enabled**, or other... unexpected delights.

Unfortunately both names are still somewhat of a misnomer right now, as people have written code for years based on this misunderstanding. Still, their original names are even moreso, and for better or worse, this backend code hasn't received as much maintenance as the rest of the compiler, lately. Actually arriving at a correct end-state will simply require us to disentangle a lot of code in order to fix, much of it pointlessly repeated in several places. Thus this is not an "actual fix", just a way to deflect further misunderstandings.
2024-10-30 14:01:37 -07:00
Michael Howell
12dc24f460 rustdoc-search: simplify rules for generics and type params
This commit is a response to feedback on the displayed type
signatures results, by making generics act stricter.

Generics are tightened by making order significant. This means
`Vec<Allocator>` now matches only with a true vector of allocators,
instead of matching the second type param. It also makes unboxing
within generics stricter, so `Result<A, B>` only matches if `B`
is in the error type and `A` is in the success type. The top level
of the function search is unaffected.

Find the discussion on:

* <https://rust-lang.zulipchat.com/#narrow/stream/393423-t-rustdoc.2Fmeetings/topic/meeting.202024-07-08/near/449965149>
* <https://github.com/rust-lang/rust/pull/124544#issuecomment-2204272265>
* <https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/deciding.20on.20semantics.20of.20generics.20in.20rustdoc.20search/near/476841363>
2024-10-30 12:27:48 -07:00
Jubilee Young
7086dd83cc compiler: rustc_abi::Abi => BackendRepr
The initial naming of "Abi" was an awful mistake, conveying wrong ideas
about how psABIs worked and even more about what the enum meant.
It was only meant to represent the way the value would be described to
a codegen backend as it was lowered to that intermediate representation.
It was never meant to mean anything about the actual psABI handling!
The conflation is because LLVM typically will associate a certain form
with a certain ABI, but even that does not hold when the special cases
that actually exist arise, plus the IR annotations that modify the ABI.

Reframe `rustc_abi::Abi` as the `BackendRepr` of the type, and rename
`BackendRepr::Aggregate` as `BackendRepr::Memory`. Unfortunately, due to
the persistent misunderstandings, this too is now incorrect:
- Scattered ABI-relevant code is entangled with BackendRepr
- We do not always pre-compute a correct BackendRepr that reflects how
  we "actually" want this value to be handled, so we leave the backend
  interface to also inject various special-cases here
- In some cases `BackendRepr::Memory` is a "real" aggregate, but in
  others it is in fact using memory, and in some cases it is a scalar!

Our rustc-to-backend lowering code handles this sort of thing right now.
That will eventually be addressed by lifting duplicated lowering code
to either rustc_codegen_ssa or rustc_target as appropriate.
2024-10-29 14:56:00 -07:00
lcnr
f51ec110a7 TypingMode 🤔 2024-10-29 17:01:24 +01:00
bors
2df8dbb1b3 Auto merge of #132277 - workingjubilee:rollup-5e6q6e4, r=workingjubilee
Rollup of 9 pull requests

Successful merges:

 - #130259 (Lower AST node id only once)
 - #131441 (Add a new trait `proc_macro::ToTokens`)
 - #132247 (stable_mir: Directly use types from rustc_abi)
 - #132249 (compiler: Add rustc_abi dependence to the compiler)
 - #132255 (Add `LayoutData::is_uninhabited` and use it)
 - #132258 ([rustdoc] Unify variant struct fields margins with struct fields)
 - #132260 (cg_llvm: Use a type-safe helper to cast `&str` and `&[u8]` to `*const c_char`)
 - #132261 (refactor: cleaner check to return None)
 - #132271 (Updating Fuchsia platform-support documentation)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-29 07:32:45 +00:00
Jubilee
d6be363400
Rollup merge of #132249 - workingjubilee:add-rustc-abi, r=compiler-errors
compiler: Add rustc_abi dependence to the compiler

Depend on rustc_abi in compiler crates that use it indirectly but have not yet taken on that dependency, and are not *significantly* entangled in my other PRs. This leaves an "excise rustc_target" step after the dust settles.
2024-10-28 10:18:50 -07:00
bors
3f1be1ec7e Auto merge of #132145 - RalfJung:stdarch, r=Amanieu
bump stdarch

This lets us remove a hack from https://github.com/rust-lang/rust/pull/131349.

r? `@Amanieu`

try-job: test-various
2024-10-28 16:25:56 +00:00
Ralf Jung
d066dfdb83 we can now enable the 'const stable fn must be stable' check 2024-10-28 11:48:39 +01:00
asquared31415
6fc7ce43d2 Error on alignments greater than isize::MAX
Co-authored-by: Jieyou Xu <jieyouxu@outlook.com>
2024-10-28 13:17:37 +08:00
Jubilee Young
4839d6e6e5 compiler: Add rustc_abi dependence to the compiler
Depend on rustc_abi in compiler crates that use it indirectly but have
not yet taken on that dependency, and are not entangled in my other PRs.
This leaves an "excise rustc_target" step after the dust settles.
2024-10-27 21:10:58 -07:00
bors
81d6652e74 Auto merge of #131284 - dingxiangfei2009:rename-smart-ptr-to-coerce-referent, r=compiler-errors
Rename macro `SmartPointer` to `CoercePointee`

As per resolution #129104 we will rename the macro to better reflect the technical specification of the feature and clarify the communication.

- `SmartPointer` is renamed to `CoerceReferent`
- `#[pointee]` attribute is renamed to `#[referent]`
- `#![feature(derive_smart_pointer)]` gate is renamed to `#![feature(derive_coerce_referent)]`.
- Any mention of `SmartPointer` in the file names are renamed accordingly.

r? `@compiler-errors`

cc `@nikomatsakis` `@Darksonn`
2024-10-27 17:04:12 +00:00
Matthias Krüger
8207d89b5e
Rollup merge of #132114 - jieyouxu:features-bundle, r=fee1-dead
Use `Enabled{Lang,Lib}Feature`  instead of n-tuples

Instead of passing around e.g. `(gate_name, attr_span, stable_since)` 3-tuples for enabled lang features or `(gate_name, attr_span)` 2-tuples for enabled lib features, use `Enabled{Lang,Lib}Feature` structs with named fields.

Also did some minor code-golfing of involved iterator chains to hopefully make them easier to follow.

Follow-up to https://github.com/rust-lang/rust/pull/132098#issuecomment-2434523431 cc `@RalfJung.`
2024-10-26 06:29:47 +02:00
Ralf Jung
8849ac6042 tcx.is_const_fn doesn't work the way it is described, remove it
Then we can rename the _raw functions to drop their suffix, and instead
explicitly use is_stable_const_fn for the few cases where that is really what
you want.
2024-10-25 20:52:39 +02:00
Ralf Jung
36dda4571d add a HACK to allow stdarch migration 2024-10-25 20:31:40 +02:00
Ralf Jung
a0215d8e46 Re-do recursive const stability checks
Fundamentally, we have *three* disjoint categories of functions:
1. const-stable functions
2. private/unstable functions that are meant to be callable from const-stable functions
3. functions that can make use of unstable const features

This PR implements the following system:
- `#[rustc_const_stable]` puts functions in the first category. It may only be applied to `#[stable]` functions.
- `#[rustc_const_unstable]` by default puts functions in the third category. The new attribute `#[rustc_const_stable_indirect]` can be added to such a function to move it into the second category.
- `const fn` without a const stability marker are in the second category if they are still unstable. They automatically inherit the feature gate for regular calls, it can now also be used for const-calls.

Also, several holes in recursive const stability checking are being closed.
There's still one potential hole that is hard to avoid, which is when MIR
building automatically inserts calls to a particular function in stable
functions -- which happens in the panic machinery. Those need to *not* be
`rustc_const_unstable` (or manually get a `rustc_const_stable_indirect`) to be
sure they follow recursive const stability. But that's a fairly rare and special
case so IMO it's fine.

The net effect of this is that a `#[unstable]` or unmarked function can be
constified simply by marking it as `const fn`, and it will then be
const-callable from stable `const fn` and subject to recursive const stability
requirements. If it is publicly reachable (which implies it cannot be unmarked),
it will be const-unstable under the same feature gate. Only if the function ever
becomes `#[stable]` does it need a `#[rustc_const_unstable]` or
`#[rustc_const_stable]` marker to decide if this should also imply
const-stability.

Adding `#[rustc_const_unstable]` is only needed for (a) functions that need to
use unstable const lang features (including intrinsics), or (b) `#[stable]`
functions that are not yet intended to be const-stable. Adding
`#[rustc_const_stable]` is only needed for functions that are actually meant to
be directly callable from stable const code. `#[rustc_const_stable_indirect]` is
used to mark intrinsics as const-callable and for `#[rustc_const_unstable]`
functions that are actually called from other, exposed-on-stable `const fn`. No
other attributes are required.
2024-10-25 20:31:40 +02:00
许杰友 Jieyou Xu (Joe)
3528149f73 Introduce Enabled{Lang,Lib}Feature
Instead of passing around random n-tuples of e.g. `(gate_name, attr_sp,
since)`.
2024-10-25 10:30:37 +08:00
Tau Gärtli
4e48768908
rustdoc: Extend fake_variadic to "wrapped" tuples
This allows impls such as `impl QueryData for OneOf<(T,)>`
to be displayed as variadic: `impl QueryData for OneOf<(T₁, T₂, …, Tₙ)>`.

See question on zulip:
<https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/Make.20.60.23.5Bdoc.28fake_variadic.29.5D.60.20more.20useful>
2024-10-24 18:50:55 +02:00
Michael Goulet
1920c66a8d Plumb through param_env to note_type_err 2024-10-24 02:48:08 +00:00
Ding Xiang Fei
fd36b3a4a8
s/SmartPointer/CoerceReferent/g
move derive_smart_pointer into removed set
2024-10-24 02:14:09 +08:00
Ralf Jung
44638853f5 rename lang feature lists to include LANG 2024-10-23 09:14:43 +01:00
Ralf Jung
ad3991d303 nightly feature tracking: get rid of the per-feature bool fields 2024-10-23 09:14:41 +01:00
bors
86d69c705a Auto merge of #132035 - matthiaskrgr:rollup-ty1e4q0, r=matthiaskrgr
Rollup of 8 pull requests

Successful merges:

 - #125205 (Fixup Windows verbatim paths when used with the `include!` macro)
 - #131049 (Validate args are correct for `UnevaluatedConst`, `ExistentialTraitRef`/`ExistentialProjection`)
 - #131549 (Add a note for `?` on a `impl Future<Output = Result<..>>` in sync function)
 - #131731 (add `TestFloatParse` to `tools.rs` for bootstrap)
 - #131732 (Add doc(plugins), doc(passes), etc. to INVALID_DOC_ATTRIBUTES)
 - #132006 (don't stage-off to previous compiler when CI rustc is available)
 - #132022 (Move `cmp_in_dominator_order` out of graph dominator computation)
 - #132033 (compiletest: Make `line_directive` return a `DirectiveLine`)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-22 14:16:37 +00:00
Matthias Krüger
83085b99c2
Rollup merge of #131732 - m4tx:fix-82824, r=davidtwco
Add doc(plugins), doc(passes), etc. to INVALID_DOC_ATTRIBUTES

This fixes #82824.
2024-10-22 15:28:45 +02:00
Matthias Krüger
3f15d296f4
Rollup merge of #131049 - compiler-errors:more-validation, r=spastorino
Validate args are correct for `UnevaluatedConst`, `ExistentialTraitRef`/`ExistentialProjection`

For the `Existential*` ones, we have to do some adjustment to the args list to deal with the missing `Self` type, so we introduce a `debug_assert_existential_args_compatible` function to the interner as well.
2024-10-22 15:28:38 +02:00
Ralf Jung
1381773e01 make some rustc_feature internals private, and ensure invariants with debug assertions 2024-10-22 07:37:55 +01:00
Ralf Jung
46ce5cbf33 terminology: #[feature] *enables* a feature (instead of "declaring" or "activating" it) 2024-10-22 07:37:54 +01:00
bors
7ed1a51b25 Auto merge of #131980 - matthiaskrgr:rollup-iy5nw71, r=matthiaskrgr
Rollup of 5 pull requests

Successful merges:

 - #131814 (`optimize` attribute applied to things other than methods/functions/c…)
 - #131927 (Check for filecheck directives in files marked `skip-filecheck`)
 - #131967 (Remove `lower_mono_bounds`)
 - #131973 (fix(rustdoc-json-types): document rustc-hash feature)
 - #131976 (feat(rustdoc-json-types): mark simple enums as copy)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-20 21:40:21 +00:00
ash
080103f1ed misapplied optimize attribute throws a compilation error (#128488) 2024-10-20 08:34:15 -06:00
Noratrieb
3efd5926f6 Stop relying on hashmap iteration for hir stat printing
Just because the code says it's OK does not mean that it actually is OK.
Nodes with the same total size were not sorted, their order relied on
hashmap iteration.
2024-10-20 00:12:52 -07:00
Michael Goulet
4886e9a134 Unify secondary_span and swap_secondary_and_primary 2024-10-15 14:39:49 -04:00
Mateusz Maćkowski
d11a9702ab
Add doc(plugins), doc(passes), etc. to INVALID_DOC_ATTRIBUTES 2024-10-15 13:28:39 +02:00
bors
88f311479d Auto merge of #131724 - matthiaskrgr:rollup-ntgkkk8, r=matthiaskrgr
Rollup of 7 pull requests

Successful merges:

 - #130608 (Implemented `FromStr` for `CString` and `TryFrom<CString>` for `String`)
 - #130635 (Add `&pin (mut|const) T` type position sugar)
 - #130747 (improve error messages for `C-cmse-nonsecure-entry` functions)
 - #131137 (Add 1.82 release notes)
 - #131328 (Remove unnecessary sorts in `rustc_hir_analysis`)
 - #131496 (Stabilise `const_make_ascii`.)
 - #131706 (Fix two const-hacks)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-15 05:02:38 +00:00
Matthias Krüger
fb691b470a
Rollup merge of #130635 - eholk:pin-reborrow-sugar, r=compiler-errors
Add `&pin (mut|const) T` type position sugar

This adds parser support for `&pin mut T` and `&pin const T` references. These are desugared to `Pin<&mut T>` and `Pin<&T>` in the AST lowering phases.

This PR currently includes #130526 since that one is in the commit queue. Only the most recent commits (bd450027eb4a94b814a7dd9c0fa29102e6361149 and following) are new.

Tracking:

- #130494

r? `@compiler-errors`
2024-10-15 05:12:34 +02:00
bors
785c83015c Auto merge of #129458 - EnzymeAD:enzyme-frontend, r=jieyouxu
Autodiff Upstreaming - enzyme frontend

This is an upstream PR for the `autodiff` rustc_builtin_macro that is part of the autodiff feature.

For the full implementation, see: https://github.com/rust-lang/rust/pull/129175

**Content:**
It contains a new `#[autodiff(<args>)]` rustc_builtin_macro, as well as a `#[rustc_autodiff]` builtin attribute.
The autodiff macro is applied on function `f` and will expand to a second function `df` (name given by user).
It will add a dummy body to `df` to make sure it type-checks. The body will later be replaced by enzyme on llvm-ir level,
we therefore don't really care about the content. Most of the changes (700 from 1.2k) are in `compiler/rustc_builtin_macros/src/autodiff.rs`, which expand the macro. Nothing except expansion is implemented for now.
I have a fallback implementation for relevant functions in case that rustc should be build without autodiff support. The default for now will be off, although we want to flip it later (once everything landed) to on for nightly. For the sake of CI, I have flipped the defaults, I'll revert this before merging.

**Dummy function Body:**
The first line is an `inline_asm` nop to make inlining less likely (I have additional checks to prevent this in the middle end of rustc. If `f` gets inlined too early, we can't pass it to enzyme and thus can't differentiate it.
If `df` gets inlined too early, the call site will just compute this dummy code instead of the derivatives, a correctness issue. The following black_box lines make sure that none of the input arguments is getting optimized away before we replace the body.

**Motivation:**
The user facing autodiff macro can verify the user input. Then I write it as args to the rustc_attribute, so from here on I can know that these values should be sensible. A rustc_attribute also turned out to be quite nice to attach this information to the corresponding function and carry it till the backend.
This is also just an experiment, I expect to adjust the user facing autodiff macro based on user feedback, to improve usability.

As a simple example of what this will do, we can see this expansion:
From:
```
#[autodiff(df, Reverse, Duplicated, Const, Active)]
pub fn f1(x: &[f64], y: f64) -> f64 {
    unimplemented!()
}
```
to
```
#[rustc_autodiff]
#[inline(never)]
pub fn f1(x: &[f64], y: f64) -> f64 {
    ::core::panicking::panic("not implemented")
}
#[rustc_autodiff(Reverse, Duplicated, Const, Active,)]
#[inline(never)]
pub fn df(x: &[f64], dx: &mut [f64], y: f64, dret: f64) -> f64 {
    unsafe { asm!("NOP"); };
    ::core::hint::black_box(f1(x, y));
    ::core::hint::black_box((dx, dret));
    ::core::hint::black_box(f1(x, y))
}
```
I will add a few more tests once I figured out why rustc rebuilds every time I touch a test.

Tracking:

- https://github.com/rust-lang/rust/issues/124509

try-job: dist-x86_64-msvc
2024-10-15 01:30:01 +00:00
Matthias Krüger
b9e083f86b
Rollup merge of #131567 - CastilloDel:reject-unstable-with-accepted-features, r=jieyouxu
Emit an error for unstable attributes that reference already stable features

Closes https://github.com/rust-lang/rust/issues/129814
2024-10-12 23:00:58 +02:00
CastilloDel
497100a13c Emit an error for unstable attributes that reference already stable features
Add missing error annotations and .stderr file

Acknowledge comments
2024-10-12 10:19:24 +02:00
Manuel Drehwald
624c071b99 Single commit implementing the enzyme/autodiff frontend
Co-authored-by: Lorenz Schmidt <bytesnake@mailbox.org>
2024-10-11 19:13:31 +02:00
bors
f4966590d8 Auto merge of #131045 - compiler-errors:remove-unnamed_fields, r=wesleywiser
Retire the `unnamed_fields` feature for now

`#![feature(unnamed_fields)]` was implemented in part in #115131 and #115367, however work on that feature has (afaict) stalled and in the mean time there have been some concerns raised (e.g.[^1][^2]) about whether `unnamed_fields` is worthwhile to have in the language, especially in its current desugaring. Because it represents a compiler implementation burden including a new kind of anonymous ADT and additional complication to field selection, and is quite prone to bugs today, I'm choosing to remove the feature.

However, since I'm not one to really write a bunch of words, I'm specifically *not* going to de-RFC this feature. This PR essentially *rolls back* the state of this feature to "RFC accepted but not yet implemented"; however if anyone wants to formally unapprove the RFC from the t-lang side, then please be my guest. I'm just not totally willing to summarize the various language-facing reasons for why this feature is or is not worthwhile, since I'm coming from the compiler side mostly.

Fixes #117942
Fixes #121161
Fixes #121263
Fixes #121299
Fixes #121722
Fixes #121799
Fixes #126969
Fixes #131041

Tracking:
* https://github.com/rust-lang/rust/issues/49804

[^1]: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Unnamed.20struct.2Funion.20fields
[^2]: https://github.com/rust-lang/rust/issues/49804#issuecomment-1972619108
2024-10-11 13:11:13 +00:00
Eric Holk
b490bf56b7
Fix clippy and rustfmt compilation 2024-10-07 11:15:15 -07:00
Eric Holk
ae698f8199
Add sugar for &pin (const|mut) types 2024-10-07 11:15:04 -07:00
bors
0b16baa570 Auto merge of #131235 - codemountains:rename-nestedmetaitem-to-metaitemlnner, r=nnethercote
Rename `NestedMetaItem` to `MetaItemInner`

Fixes #131087

r? `@nnethercote`
2024-10-07 08:59:55 +00:00