Commit Graph

32233 Commits

Author SHA1 Message Date
Nicholas Nethercote
514a5d8d55 Remove the second lifetime from DiagnosticArg.
Because it's always static.

I'm surprised the compiler allowed this unused lifetime without any
complaint.
2024-01-30 18:46:08 +11:00
Nicholas Nethercote
f0426b77fc Remove the lifetime from DiagnosticArgName.
Because it's always 'static.
2024-01-30 18:46:08 +11:00
Nicholas Nethercote
06aa381adb Remove DiagnosticArgName from rustc_codegen_ssa.
It's identical to the one in `rustc_errors`; use that instead.

Also remove some `rustc_errors::` qualifiers.
2024-01-30 18:46:08 +11:00
Nicholas Nethercote
45dc19785d Remove lifetimes from some diagnostics.
Because the `&'a str` fields can be trivially converted to `String`
without causing any extra allocations.
2024-01-30 18:46:08 +11:00
Nicholas Nethercote
5350edb9e8 Remove the lifetime from DiagnosticArgValue.
Because it's almost always static.

This makes `impl IntoDiagnosticArg for DiagnosticArgValue` trivial,
which is nice.

There are a few diagnostics constructed in
`compiler/rustc_mir_build/src/check_unsafety.rs` and
`compiler/rustc_mir_transform/src/errors.rs` that now need symbols
converted to `String` with `to_string` instead of `&str` with `as_str`,
but that' no big deal, and worth it for the simplifications elsewhere.
2024-01-30 18:46:06 +11:00
bors
fb4bca04fa Auto merge of #120165 - reitermarkus:nonzero-switch-alias-direction, r=dtolnay
Switch `NonZero` alias direction.

Step 4 mentioned in https://github.com/rust-lang/rust/pull/100428#pullrequestreview-1767139731.

Depends on https://github.com/rust-lang/rust/pull/120160.

r? `@dtolnay`
2024-01-29 08:52:13 +00:00
Nicholas Nethercote
5d9dfbd08f Stop using String for error codes.
Error codes are integers, but `String` is used everywhere to represent
them. Gross!

This commit introduces `ErrCode`, an integral newtype for error codes,
replacing `String`. It also introduces a constant for every error code,
e.g. `E0123`, and removes the `error_code!` macro. The constants are
imported wherever used with `use rustc_errors::codes::*`.

With the old code, we have three different ways to specify an error code
at a use point:
```
error_code!(E0123)  // macro call

struct_span_code_err!(dcx, span, E0123, "msg");  // bare ident arg to macro call

\#[diag(name, code = "E0123")]  // string
struct Diag;
```

With the new code, they all use the `E0123` constant.
```
E0123  // constant

struct_span_code_err!(dcx, span, E0123, "msg");  // constant

\#[diag(name, code = E0123)]  // constant
struct Diag;
```

The commit also changes the structure of the error code definitions:
- `rustc_error_codes` now just defines a higher-order macro listing the
  used error codes and nothing else.
- Because that's now the only thing in the `rustc_error_codes` crate, I
  moved it into the `lib.rs` file and removed the `error_codes.rs` file.
- `rustc_errors` uses that macro to define everything, e.g. the error
  code constants and the `DIAGNOSTIC_TABLES`. This is in its new
  `codes.rs` file.
2024-01-29 07:41:41 +11:00
Nicholas Nethercote
0321de2778 Remove bogus {code} attributes on TraitImplMismatch.
This makes no sense, and has no effect. I suspect it's been confused
with a `code = "{code}"` attribute on a subdiagnostic suggestion, where
it is valid (but the "code" there is suggested source code, rather than
an error code.)
2024-01-29 07:40:10 +11:00
Nicholas Nethercote
d91d164b00 Sort attributes in compiler/rustc_errors/src/lib.rs.
As is already done in `rustc_span` and `rustc_data_structures`.
2024-01-29 07:40:08 +11:00
bors
6351247048 Auto merge of #120024 - Mark-Simulacrum:fast-union-merge, r=cjgillot
Merge into larger interval set

This reduces the work done while merging rows. In at least one case (#50450), we have thousands of union([range], [20,000 ranges]), which previously inserted each of the 20,000 ranges one by one. Now we only insert one range into the right hand set after copying the set over.

This cuts the runtime of the test case in #50450 from ~26 seconds to ~6 seconds locally, though it doesn't change the memory usage peak (~9.5GB).
2024-01-27 22:26:37 +00:00
Markus Reiter
117eb9f376
Fix NonZero suggestions. 2024-01-27 16:38:57 +01:00
Markus Reiter
554b0f70c3
Add NonZero symbol. 2024-01-27 16:38:57 +01:00
bors
8af70c7a18 Auto merge of #120062 - davidtwco:llvm-data-layout-check, r=wesleywiser
llvm: change data layout bug to an error and make it trigger more

Fixes #33446.

Don't skip the inconsistent data layout check for custom LLVMs or non-built-in targets.

With #118708, all targets will have a simple test that would trigger this error if LLVM's data layouts do change - so data layouts would be corrected during the LLVM upgrade. Therefore, with builtin targets, this error won't happen with our LLVM because each target will have been confirmed to work. With non-builtin targets, this error is probably useful to have because you can change the data layout in your target and if it is wrong then that could lead to bugs.

When using a custom LLVM, the same justification makes sense for non-builtin targets as with our LLVM, the user can update their target to match their LLVM and that's probably a good thing to do. However, with a custom LLVM, the user cannot change the builtin target data layouts if they don't match - though given that the compiler's data layout is used for layout computation and a bunch of other things - you could get some bugs because of the mismatch and probably want to know about that. I'm not sure if this is something that people do and is okay, but I doubt it?

`CFG_LLVM_ROOT` was also always set during local development with `download-ci-llvm` so this bug would never trigger locally.

In #33446, two points are raised:

- In the issue itself, changing this from a `bug!` to a proper error is what is suggested, by using `isCompatibleDataLayout` from LLVM, but that function still just does the same thing that we do and check for equality, so I've avoided the additional code necessary to do that FFI call.
- `@Mark-Simulacrum` suggests a different check is necessary to maintain backwards compatibility with old LLVM versions. I don't know how often this comes up, but we can do that with some simple string manipulation + LLVM version checks as happens already for LLVM 17 just above this diff.
2024-01-27 12:19:41 +00:00
Matthias Krüger
0972d4441e
Rollup merge of #120398 - Urgau:into_diag_arg-numbers, r=compiler-errors
Improve handling of numbers in `IntoDiagnosticArg`

While working on https://github.com/rust-lang/rust/pull/120393, I realize that my fluent selectors were not working. So here is an improvement (not a fix unfortunately).
2024-01-27 10:48:48 +01:00
Matthias Krüger
58db961d71
Rollup merge of #120386 - klensy:destruction_scopes, r=compiler-errors
ScopeTree: remove destruction_scopes as unused

last usages removed by https://github.com/rust-lang/rust/pull/116170

Unused, but still presented in memory at `t-gmax` (in DHAT termonology)
2024-01-27 10:48:48 +01:00
Matthias Krüger
c6f0a5cfe3
Rollup merge of #119957 - Young-Flash:fix, r=fmease
fix: correct suggestion arg for impl trait

follow up https://github.com/rust-lang/rust/pull/118502, close https://github.com/rust-lang/rust/issues/119775
2024-01-27 10:48:47 +01:00
Matthias Krüger
9a4417659e
Rollup merge of #118182 - estebank:issue-118164, r=davidtwco
Properly recover from trailing attr in body

When encountering an attribute in a body, we try to recover from an attribute on an expression (as opposed to a statement). We need to properly clean up when the attribute is at the end of the body where a tail expression would be.

Fix #118164, fix #118575.
2024-01-27 10:48:46 +01:00
bors
04521fd10e Auto merge of #118636 - h1467792822:dev, r=michaelwoerister
Add the unstable option  to reduce the binary size of dynamic library…

# Motivation

The average length of symbol names in the rust standard library is about 100 bytes, while the average length of symbol names in the C++ standard library is about 65 bytes. In some embedded environments where dynamic library are widely used, rust dynamic library symbol name space hash become one of the key bottlenecks of application, Especially when the existing C/C++ module is reconstructed into the rust module.

The unstable option `-Z symbol_mangling_version=hashed` is added to solve the bottleneck caused by too long dynamic library symbol names.

## Test data

The following is a set of test data on the ubuntu 18.04 LTS environment. With this plug-in, the space saving rate of dynamic libraries can reach about 20%.

The test object is the standard library of rust (built based on Xargo), tokio crate, and hyper crate.

The contents of the Cargo.toml file in the construction project of the three dynamic libraries are as follows:

```txt
# Cargo.toml
[profile.release]
panic = "abort"
opt-leve="z"
codegen-units=1
strip=true
debug=true
```
The built dynamic library also removes the `.rustc` segments that are not needed at run time and then compares the size. The detailed data is as follows:

1. libstd.so
> | symbol_mangling_version | size | saving rate |
> | --- | --- | --- |
> | legacy | 804896 ||
> | hashed | 608288 | 0.244 |
> | v0 | 858144 ||
> | hashed | 608288 | 0.291 |

2. libhyper.so
> | symbol_mangling_version(libhyper.so) | symbol_mangling_version(libstd.so) | size | saving rate |
> | --- | --- | --- | --- |
> | legacy | legacy | 866312 ||
> | hashed | legacy | 645128 |0.255|
> | legacy | hashed | 854024 ||
> | hashed | hashed | 632840 |0.259|
2024-01-27 02:32:30 +00:00
Young-Flash
8b3a681a34 minor: pick a suitable var name 2024-01-27 10:24:45 +08:00
bors
b362939be1 Auto merge of #120401 - matthiaskrgr:rollup-7740vrx, r=matthiaskrgr
Rollup of 12 pull requests

Successful merges:

 - #103522 (stabilise array methods)
 - #113489 (impl `From<&[T; N]>` for `Cow<[T]>`)
 - #119342 (Emit suggestion when trying to write exclusive ranges as `..<`)
 - #119562 (Rename `pointer` field on `Pin`)
 - #119800 (Document `rustc_index::vec::IndexVec`)
 - #120205 (std: make `HEAP` initializer never inline)
 - #120277 (Normalize field types before checking validity)
 - #120311 (core: add `From<core::ascii::Char>` implementations)
 - #120366 (mark a doctest with UB as no_run)
 - #120378 (always normalize `LoweredTy` in the new solver)
 - #120382 (Classify closure arguments in refutable pattern in argument error)
 - #120389 (Add fmease to the compiler review rotation)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-01-27 00:22:48 +00:00
Esteban Küber
a5d9def321 Properly recover from trailing attr in body
When encountering an attribute in a body, we try to recover from an
attribute on an expression (as opposed to a statement). We need to
properly clean up when the attribute is at the end of the body where a
tail expression would be.

Fix #118164.
2024-01-26 23:11:42 +00:00
Matthias Krüger
e912229ba3
Rollup merge of #120382 - fee1-dead-contrib:classify-closure-argument, r=Nadrieril
Classify closure arguments in refutable pattern in argument error

You can call it a function (and people may or may not agree with that), but it's better to just say those are closure arguments instead.
2024-01-26 23:15:53 +01:00
Matthias Krüger
fad940029b
Rollup merge of #120378 - lcnr:normalize-ast, r=compiler-errors
always normalize `LoweredTy` in the new solver

I currently expect us to stop using alias bound candidates of normalizable aliases due to https://github.com/rust-lang/trait-system-refactor-initiative/issues/77 by landing https://github.com/rust-lang/rust/pull/119744. At this point it mostly doesn't matter whether we eagerly normalize (and replace with infer vars in case of ambiguity). cc #113473 previous attempt

The infer var replacement for ambiguous projections can in very rare cases:
- weaken inference https://github.com/rust-lang/trait-system-refactor-initiative/issues/81
- strengthen inference https://github.com/rust-lang/trait-system-refactor-initiative/issues/7

I do not expect this impact on inference to significantly affect real crates.

r? ``@compiler-errors``
2024-01-26 23:15:52 +01:00
Matthias Krüger
8ec883856d
Rollup merge of #120277 - compiler-errors:normalize-before-validating, r=oli-obk
Normalize field types before checking validity

I forgot to normalize field types when checking ADT-like aggregates in the MIR validator.

This normalization is needed due to a crude check for opaque types in `mir_assign_valid_types` which prevents opaque type cycles -- if we pass in an unnormalized type, we may not detect that the destination type is an opaque, and therefore will call `type_of(opaque)` later on, which causes a cycle error -> ICE.

Fixes #120253
2024-01-26 23:15:51 +01:00
Matthias Krüger
b31bf24908
Rollup merge of #119800 - dev-ardi:tmp, r=wesleywiser
Document `rustc_index::vec::IndexVec`

Document a few of the methods.

Part of https://github.com/rust-lang/rust/issues/93792.
2024-01-26 23:15:50 +01:00
Matthias Krüger
346397d081
Rollup merge of #119562 - LegionMammal978:rename-pin-pointer, r=Amanieu,dtolnay
Rename `pointer` field on `Pin`

A few days ago, I was helping another user create a self-referential type using `PhantomPinned`. However, I noticed an odd behavior when I tried to access one of the type's fields via `Pin`'s `Deref` impl:

```rust
use std::{marker::PhantomPinned, ptr};

struct Pinned {
    data: i32,
    pointer: *const i32,
    _pin: PhantomPinned,
}

fn main() {
    let mut b = Box::pin(Pinned {
        data: 42,
        pointer: ptr::null(),
        _pin: PhantomPinned,
    });
    {
        let pinned = unsafe { b.as_mut().get_unchecked_mut() };
        pinned.pointer = &pinned.data;
    }
    println!("{}", unsafe { *b.pointer });
}
```

```rust
error[E0658]: use of unstable library feature 'unsafe_pin_internals'
  --> <source>:19:30
   |
19 |     println!("{}", unsafe { *b.pointer });
   |                              ^^^^^^^^^

error[E0277]: `Pinned` doesn't implement `std::fmt::Display`
  --> <source>:19:20
   |
19 |     println!("{}", unsafe { *b.pointer });
   |                    ^^^^^^^^^^^^^^^^^^^^^ `Pinned` cannot be formatted with the default formatter
   |
   = help: the trait `std::fmt::Display` is not implemented for `Pinned`
   = note: in format strings you may be able to use `{:?}` (or {:#?} for pretty-print) instead
   = note: this error originates in the macro `$crate::format_args_nl` which comes from the expansion of the macro `println` (in Nightly builds, run with -Z macro-backtrace for more info)
```

Since the user named their field `pointer`, it conflicts with the `pointer` field on `Pin`, which is public but unstable since Rust 1.60.0 with #93176. On versions from 1.33.0 to 1.59.0, where the field on `Pin` is private, this program compiles and prints `42` as expected.

To avoid this confusing behavior, this PR renames `pointer` to `__pointer`, so that it's less likely to conflict with a `pointer` field on the underlying type, as accessed through the `Deref` impl. This is technically a breaking change for anyone who names their field `__pointer` on the inner type; if this is undesirable, it could be renamed to something more longwinded. It's also a nightly breaking change for any external users of `unsafe_pin_internals`.
2024-01-26 23:15:49 +01:00
Matthias Krüger
7f19365560
Rollup merge of #119342 - sjwang05:issue-112254, r=wesleywiser
Emit suggestion when trying to write exclusive ranges as `..<`

Closes #112254
2024-01-26 23:15:49 +01:00
Urgau
93ff4a4f48
Fix typo
Co-authored-by: Michael Goulet <michael@errs.io>
2024-01-26 21:01:45 +01:00
Urgau
304361a10c Improve handling of numbers in IntoDiagnosticArg 2024-01-26 20:32:55 +01:00
Michael Goulet
866364cc5d Normalize field types before checking validity 2024-01-26 18:36:15 +00:00
bjorn3
37018026f0 Merge commit '3e50cf65025f96854d6597e80449b0d64ad89589' into sync_cg_clif-2024-01-26 2024-01-26 18:33:45 +00:00
klensy
90254cd55f ScopeTree: remove destruction_scopes as unused
last usages removed by https://github.com/rust-lang/rust/pull/116170
2024-01-26 19:45:00 +03:00
Deadbeef
e17f91dd8b Classify closure arguments in refutable pattern in argument error 2024-01-26 23:54:08 +08:00
bors
e7bbe8ce93 Auto merge of #120375 - matthiaskrgr:rollup-ueakvms, r=matthiaskrgr
Rollup of 9 pull requests

Successful merges:

 - #117420 (Make `#![allow_internal_unstable(..)]` work with `stmt_expr_attributes`)
 - #117678 (Stabilize `slice_group_by`)
 - #119917 (Remove special-case handling of `vec.split_off(0)`)
 - #120117 (Update `std::io::Error::downcast` return type)
 - #120329 (RFC 3349 precursors)
 - #120339 (privacy: Refactor top-level visiting in `NamePrivacyVisitor`)
 - #120345 (Clippy subtree update)
 - #120360 (Don't fire `OPAQUE_HIDDEN_INFERRED_BOUND` on sized return of AFIT)
 - #120372 (Fix outdated comment on Box)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-01-26 14:58:10 +00:00
lcnr
a39a2f73d6 next-solver: normalize in LoweredTy::from_raw 2024-01-26 15:54:57 +01:00
Matthias Krüger
b4b483574f
Rollup merge of #120360 - compiler-errors:afit-sized-lol, r=lcnr
Don't fire `OPAQUE_HIDDEN_INFERRED_BOUND` on sized return of AFIT

Conceptually, we should probably not fire `OPAQUE_HIDDEN_INFERRED_BOUND` for methods like:

```
trait Foo { async fn bar() -> Self; }
```

Even though we technically cannot prove that `Self: Sized`, which is one of the item bounds of the `Output` type in the `-> impl Future<Output = Sized>` from the async desugaring.

This is somewhat justifiable along the same lines as how we allow regular methods to return `-> Self` even though `Self` isn't sized.

Fixes #113538

(side-note: some days i wonder if we should just remove the `OPAQUE_HIDDEN_INFERRED_BOUND` lint... it does make me sad that we have non-well-formed types in signatures, though.)
2024-01-26 14:43:32 +01:00
Matthias Krüger
c48c77e160
Rollup merge of #120339 - petrochenkov:nameprivisit, r=michaelwoerister
privacy: Refactor top-level visiting in `NamePrivacyVisitor`

Full hierarchical visiting (`nested_filter::All`) is not necessary, visiting all item-likes in isolation is enough.
Tracking current item is not necessary, passing any `HirId` with the same parent module to `adjust_ident_and_get_scope` is enough.

Follow up to https://github.com/rust-lang/rust/pull/120284.
2024-01-26 14:43:31 +01:00
Matthias Krüger
5f1f6176a5
Rollup merge of #120329 - nnethercote:3349-precursors, r=fee1-dead
RFC 3349 precursors

Some cleanups I found while working on RFC 3349 that are worth landing separately.

r? `@fee1-dead`
2024-01-26 14:43:31 +01:00
Matthias Krüger
a5b60c941e
Rollup merge of #117678 - niklasf:stabilize-slice_group_by, r=dtolnay
Stabilize `slice_group_by`

Renamed "group by" to "chunk by" a per #80552.

Newly stable items:

* `core::slice::ChunkBy`
* `core::slice::ChunkByMut`
* `[T]::chunk`
* `[T]::chunk_by`

Closes #80552.
2024-01-26 14:43:29 +01:00
Matthias Krüger
4808aa8872
Rollup merge of #117420 - Jules-Bertholet:internal-unstable-stmt-expr-attributes, r=petrochenkov
Make `#![allow_internal_unstable(..)]` work with `stmt_expr_attributes`

This is a necessary first step to fixing #117304, as explained in https://github.com/rust-lang/rust/issues/117304#issuecomment-1784414453.

`@rustbot` label T-compiler
2024-01-26 14:43:29 +01:00
bors
cdd4ff8d81 Auto merge of #120367 - RalfJung:project_downcast_uninhabited, r=oli-obk
interpret: project_downcast: do not ICE for uninhabited variants

Fixes https://github.com/rust-lang/rust/issues/120337

This assertion was already under discussion for a bit; I think the [example](https://github.com/rust-lang/rust/issues/120337#issuecomment-1911076292) `@tmiasko` found is the final nail in the coffin. One could argue maybe MIR building should read the discriminant before projecting, but even then MIR optimizations should be allowed to remove that read, so the downcast should still not ICE. Maybe the downcast should be UB, but in this example UB already arises earlier when a value of type `E` is constructed.

r? `@oli-obk`
2024-01-26 12:50:02 +00:00
Ralf Jung
64cd13ff3b add test for GVN issue; cleanup in dataflow_const_prop 2024-01-26 10:40:29 +01:00
Ralf Jung
1025a12b64 interpret: project_downcast: do not ICE for uninhabited variants 2024-01-26 09:01:56 +01:00
Ardi
00ada8e30c
Update compiler/rustc_index/src/vec.rs
Co-authored-by: Wesley Wiser <wwiser@gmail.com>
2024-01-26 08:37:37 +01:00
David Tolnay
97a720b39b
Rebase slice_group_by stabilization PR 2024-01-25 22:20:59 -08:00
Matthias Krüger
e400311486
Rollup merge of #120322 - compiler-errors:higher-ranked-async-closures, r=oli-obk
Don't manually resolve async closures in `rustc_resolve`

There's a comment here that talks about doing this "[so] closure [args] are detected as upvars rather than normal closure arg usages", but we do upvar analysis on the HIR now:

cd6d8f2a04/compiler/rustc_passes/src/upvars.rs (L21-L29)

Removing this ad-hoc logic makes it so that `async |x: &str|` now introduces an implicit binder, like regular closures.

r? ```@oli-obk```
2024-01-26 06:36:39 +01:00
Matthias Krüger
626797b61d
Rollup merge of #120204 - azhogin:azhogin/collapse_debuginfo_for_builtin, r=petrochenkov
Builtin macros effectively have implicit #[collapse_debuginfo(yes)]

If collapse_debuginfo attribute for builtin macro is not specified explicitly, it will be effectively set to `#[collapse_debuginfo(yes)]`.
2024-01-26 06:36:38 +01:00
Matthias Krüger
a37fa37281
Rollup merge of #118803 - Nadrieril:min-exhaustive-patterns, r=compiler-errors
Add the `min_exhaustive_patterns` feature gate

## Motivation

Pattern-matching on empty types is tricky around unsafe code. For that reason, current stable rust conservatively requires arms for empty types in all but the simplest case. It has long been the intention to allow omitting empty arms when it's safe to do so. The [`exhaustive_patterns`](https://github.com/rust-lang/rust/issues/51085) feature allows the omission of all empty arms, but hasn't been stabilized because that was deemed dangerous around unsafe code.

## Proposal

This feature aims to stabilize an uncontroversial subset of exhaustive_patterns. Namely: when `min_exhaustive_patterns` is enabled and the data we're matching on is guaranteed to be valid by rust's operational semantics, then we allow empty arms to be omitted. E.g.:

```rust
let x: Result<T, !> = foo();
match x { // ok
    Ok(y) => ...,
}
let Ok(y) = x; // ok
```

If the place is not guaranteed to hold valid data (namely ptr dereferences, ref dereferences (conservatively) and union field accesses), then we keep stable behavior i.e. we (usually) require arms for the empty cases.

```rust
unsafe {
    let ptr: *const Result<u32, !> = ...;
    match *ptr {
        Ok(x) => { ... }
        Err(_) => { ... } // still required
    }
}
let foo: Result<u32, &!> = ...;
match foo {
    Ok(x) => { ... }
    Err(&_) => { ... } // still required because of the dereference
}
unsafe {
    let ptr: *const ! = ...;
    match *ptr {} // already allowed on stable
}
```

Note that we conservatively consider that a valid reference can point to invalid data, hence we don't allow arms of type `&!` and similar cases to be omitted. This could eventually change depending on [opsem decisions](https://github.com/rust-lang/unsafe-code-guidelines/issues/413). Whenever opsem is undecided on a case, we conservatively keep today's stable behavior.

I proposed this behavior in the [`never_patterns`](https://github.com/rust-lang/rust/issues/118155) feature gate but it makes sense on its own and could be stabilized more quickly. The two proposals nicely complement each other.

## Unresolved Questions

Part of the question is whether this requires an RFC. I'd argue this doesn't need one since there is no design question beyond the intent to omit unreachable patterns, but I'm aware the problem can be framed in ways that require design (I'm thinking of the [original never patterns proposal](https://smallcultfollowing.com/babysteps/blog/2018/08/13/never-patterns-exhaustive-matching-and-uninhabited-types-oh-my/), which would frame this behavior as "auto-nevering" happening).

EDIT: I initially proposed a future-compatibility lint as part of this feature, I don't anymore.
2024-01-26 06:36:36 +01:00
h1467792822
6e53e66bd3 MCP #705: Provide the option -Csymbol-mangling-version=hashed -Z unstable-options to shorten symbol names by replacing them with a digest.
Enrich test cases
2024-01-26 12:39:03 +08:00
bors
69db514ed9 Auto merge of #119968 - clubby789:unused-feature, r=compiler-errors
Remove unused/unnecessary features

~~The bulk of the actual code changes here is replacing try blocks with equivalent closures. I'm not entirely sure that's a good idea since it may have perf impact, happy to revert if that's the case/the change is unwanted.~~

I also removed a lot of `recursion_limit = "256"` since everything seems to build fine without that and most don't have any comment justifying it.
2024-01-26 03:18:34 +00:00