Commit Graph

708 Commits

Author SHA1 Message Date
Matthias Krüger
f9ca213510 remove some things that do not need to be 2024-04-11 21:09:52 +02:00
Oli Scherer
07310e21d4 Set the correct tracking issue for pattern types 2024-04-08 20:53:05 +00:00
bors
537aab7a2e Auto merge of #120131 - oli-obk:pattern_types_syntax, r=compiler-errors
Implement minimal, internal-only pattern types in the type system

rebase of https://github.com/rust-lang/rust/pull/107606

You can create pattern types with `std::pat::pattern_type!(ty is pat)`. The feature is incomplete and will panic on you if you use any pattern other than integral range patterns. The only way to create or deconstruct a pattern type is via `transmute`.

This PR's implementation differs from the MCP's text. Specifically

> This means you could implement different traits for different pattern types with the same base type. Thus, we just forbid implementing any traits for pattern types.

is violated in this PR. The reason is that we do need impls after all in order to make them usable as fields. constants of type `std::time::Nanoseconds` struct are used in patterns, so the type must be structural-eq, which it only can be if you derive several traits on it. It doesn't need to be structural-eq recursively, so we can just manually implement the relevant traits on the pattern type and use the pattern type as a private field.

Waiting on:

* [x] move all unrelated commits into their own PRs.
* [x] fix niche computation (see 2db07f94f44f078daffe5823680d07d4fded883f)
* [x] add lots more tests
* [x] T-types MCP https://github.com/rust-lang/types-team/issues/126 to finish
* [x] some commit cleanup
* [x] full self-review
* [x] remove 61bd325da19a918cc3e02bbbdce97281a389c648, it's not necessary anymore I think.
* [ ] ~~make sure we never accidentally leak pattern types to user code (add stability checks or feature gate checks and appopriate tests)~~ we don't even do this for the new float primitives
* [x] get approval that [the scope expansion to trait impls](https://rust-lang.zulipchat.com/#narrow/stream/326866-t-types.2Fnominated/topic/Pattern.20types.20types-team.23126/near/427670099) is ok

r? `@BoxyUwU`
2024-04-08 16:25:23 +00:00
Matthias Krüger
337be99bb6
Rollup merge of #120144 - petrochenkov:unty, r=davidtwco
privacy: Stabilize lint `unnameable_types`

This is the last piece of ["RFC #2145: Type privacy and private-in-public lints"](https://github.com/rust-lang/rust/issues/48054).

Having unstable lints is not very useful because you cannot even dogfood them in the compiler/stdlib in this case (https://github.com/rust-lang/rust/pull/113284).
The worst thing that may happen when a lint is removed are some `removed_lints` warnings, but I haven't heard anyone suggesting removing this specific lint.

This lint is allow-by-default and is supposed to be enabled explicitly.
Some false positives are expected, because sometimes unnameable types are a legitimate pattern.
This lint also have some unnecessary false positives, that can be fixed - see https://github.com/rust-lang/rust/issues/120146 and https://github.com/rust-lang/rust/issues/120149.

Closes https://github.com/rust-lang/rust/issues/48054.
2024-04-08 14:31:10 +02:00
Oli Scherer
c340e67dec Add pattern types to parser 2024-04-08 11:57:17 +00:00
Ben Kimock
a7912cb421 Put checks that detect UB under their own flag below debug_assertions 2024-04-06 11:21:47 -04:00
Jules Bertholet
9d200f2d88
Address review comments 2024-04-02 10:57:54 -05:00
Jules Bertholet
f37a4d55ee
Implement "&<pat> everywhere"
The original proposal allows reference patterns
with "compatible" mutability, however it's not clear
what that means so for now we require an exact match.

I don't know the type system code well, so if something
seems to not make sense it's probably because I made a
mistake
2024-03-30 12:57:54 -05:00
bors
45796d1c24 Auto merge of #123080 - Jules-Bertholet:mut-ref-mut, r=Nadrieril
Match ergonomics 2024: implement mutable by-reference bindings

Implements the mutable by-reference bindings portion of match ergonomics 2024 (#123076), with the `mut ref`/`mut ref mut` syntax, under feature gate `mut_ref`.

r? `@Nadrieril`

`@rustbot` label A-patterns A-edition-2024
2024-03-29 11:08:11 +00:00
Jules Bertholet
528d45af18
Feature gate 2024-03-27 11:20:28 -04:00
DianQK
47ed73a7b5
Eliminate UbCheck for non-standard libraries 2024-03-27 21:02:40 +08:00
Matthias Krüger
783778c631
Rollup merge of #121619 - RossSmyth:pfix_match, r=petrochenkov
Experimental feature postfix match

This has a basic experimental implementation for the RFC postfix match (rust-lang/rfcs#3295, #121618). [Liaison is](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Postfix.20Match.20Liaison/near/423301844) ```@scottmcm``` with the lang team's [experimental feature gate process](https://github.com/rust-lang/lang-team/blob/master/src/how_to/experiment.md).

This feature has had an RFC for a while, and there has been discussion on it for a while. It would probably be valuable to see it out in the field rather than continue discussing it. This feature also allows to see how popular postfix expressions like this are for the postfix macros RFC, as those will take more time to implement.

It is entirely implemented in the parser, so it should be relatively easy to remove if needed.

This PR is split in to 5 commits to ease review.

1. The implementation of the feature & gating.
2. Add a MatchKind field, fix uses, fix pretty.
3. Basic rustfmt impl, as rustfmt crashes upon seeing this syntax without a fix.
4. Add new MatchSource to HIR for Clippy & other HIR consumers
2024-03-22 11:36:58 +01:00
Matthias Krüger
b469a6dd9b
Rollup merge of #122843 - WaffleLapkin:semicolon-vs-the-never, r=compiler-errors
Add a never type option to make diverging blocks `()`

More experiments for ~~the blood god~~ T-lang!

Usage example:
```rust
 #![allow(internal_features)]
 #![feature(never_type, rustc_attrs)]
 #![rustc_never_type_options(diverging_block_default = "unit")]

fn main() {
    let _: u8 = { //~ error: expected `u8`, found `()`
        return;
    };
}
```

r? compiler-errors

I'm not sure how I feel about parsing the attribute every time we create `FnCtxt`. There must be a better way to do this, right?
2024-03-22 01:07:33 +01:00
Maybe Waffle
6f2c6efe01 Change syntax of the never type attribute thingy
Previous:
  ```rust
  #![rustc_never_type_mode = "fallback_to_unit|..."]
  ```

New:
  ```rust
  #![rustc_never_type_options(fallback = "unit|...")]
  ```
This allows adding other options for other never-related experiments.
2024-03-21 19:47:46 +00:00
Nadrieril
120d3570aa Add barest-bones deref patterns
Co-authored-by: Deadbeef <ent3rm4n@gmail.com>
2024-03-20 22:30:27 +01:00
Mark Rousskov
4fb89c5056 branch 1.78: replace-version-placeholder 2024-03-19 19:27:24 -04:00
Matthias Krüger
ea7ea2df86
Rollup merge of #122695 - surechen:make_only_local_explict_argument, r=lcnr
Change only_local to a enum type.

Change only_local to enum type and change the macros to always require a variant of that enum.

r? `@lcnr`
2024-03-19 18:03:52 +01:00
surechen
db48dfcd03 Change only_local to enum type and change the macros to always require a variant of that enum. 2024-03-19 20:13:40 +08:00
bors
21d94a3d2c Auto merge of #122055 - compiler-errors:stabilize-atb, r=oli-obk
Stabilize associated type bounds (RFC 2289)

This PR stabilizes associated type bounds, which were laid out in [RFC 2289]. This gives us a shorthand to express nested type bounds that would otherwise need to be expressed with nested `impl Trait` or broken into several `where` clauses.

### What are we stabilizing?

We're stabilizing the associated item bounds syntax, which allows us to put bounds in associated type position within other bounds, i.e. `T: Trait<Assoc: Bounds...>`. See [RFC 2289] for motivation.

In all position, the associated type bound syntax expands into a set of two (or more) bounds, and never anything else (see "How does this differ[...]" section for more info).

Associated type bounds are stabilized in four positions:
* **`where` clauses (and APIT)** - This is equivalent to breaking up the bound into two (or more) `where` clauses. For example, `where T: Trait<Assoc: Bound>` is equivalent to `where T: Trait, <T as Trait>::Assoc: Bound`.
* **Supertraits** - Similar to above, `trait CopyIterator: Iterator<Item: Copy> {}`. This is almost equivalent to breaking up the bound into two (or more) `where` clauses; however, the bound on the associated item is implied whenever the trait is used. See #112573/#112629.
* **Associated type item bounds** - This allows constraining the *nested* rigid projections that are associated with a trait's associated types. e.g. `trait Trait { type Assoc: Trait2<Assoc2: Copy>; }`.
* **opaque item bounds (RPIT, TAIT)** - This allows constraining associated types that are associated with the opaque without having to *name* the opaque. For example, `impl Iterator<Item: Copy>` defines an iterator whose item is `Copy` without having to actually name that item bound.

The latter three are not expressible in surface Rust (though for associated type item bounds, this will change in #120752, which I don't believe should block this PR), so this does represent a slight expansion of what can be expressed in trait bounds.

### How does this differ from the RFC?

Compared to the RFC, the current implementation *always* desugars associated type bounds to sets of `ty::Clause`s internally. Specifically, it does *not* introduce a position-dependent desugaring as laid out in [RFC 2289], and in particular:
* It does *not* desugar to anonymous associated items in associated type item bounds.
* It does *not* desugar to nested RPITs in RPIT bounds, nor nested TAITs in TAIT bounds.

This position-dependent desugaring laid out in the RFC existed simply to side-step limitations of the trait solver, which have mostly been fixed in #120584. The desugaring laid out in the RFC also added unnecessary complication to the design of the feature, and introduces its own limitations to, for example:
* Conditionally lowering to nested `impl Trait` in certain positions such as RPIT and TAIT means that we inherit the limitations of RPIT/TAIT, namely lack of support for higher-ranked opaque inference. See this code example: https://github.com/rust-lang/rust/pull/120752#issuecomment-1979412531.
* Introducing anonymous associated types makes traits no longer object safe, since anonymous associated types are not nameable, and all associated types must be named in `dyn` types.

This last point motivates why this PR is *not* stabilizing support for associated type bounds in `dyn` types, e.g, `dyn Assoc<Item: Bound>`. Why? Because `dyn` types need to have *concrete* types for all associated items, this would necessitate a distinct lowering for associated type bounds, which seems both complicated and unnecessary compared to just requiring the user to write `impl Trait` themselves. See #120719.

### Implementation history:

Limited to the significant behavioral changes and fixes and relevant PRs, ping me if I left something out--
* #57428
* #108063
* #110512
* #112629
* #120719
* #120584

Closes #52662

[RFC 2289]: https://rust-lang.github.io/rfcs/2289-associated-type-bounds.html
2024-03-19 00:04:09 +00:00
Matthias Krüger
b19c67c0fc
Rollup merge of #122060 - clubby789:stabilize-imported-main, r=lcnr
Stabilize `imported_main`

FCP: https://github.com/rust-lang/rust/issues/28937#issuecomment-1977822831
Docs: https://github.com/rust-lang/reference/pull/1461
2024-03-18 22:24:37 +01:00
bors
c03ea3dfd9 Auto merge of #121926 - tgross35:f16-f128-step3-feature-gate, r=compiler-errors,petrochenkov
`f16` and `f128` step 3: compiler support & feature gate

Continuation of https://github.com/rust-lang/rust/pull/121841, another portion of https://github.com/rust-lang/rust/pull/114607

This PR exposes the new types to the world and adds a feature gate. Marking this as a draft because I need some feedback on where I did the feature gate check. It also does not yet catch type via suffixed literals (so the feature gate test will fail, probably some others too because I haven't belssed).

If there is a better place to check all types after resolution, I can do that. If not, I figure maybe I can add a second gate location in AST when it checks numeric suffixes.

Unfortunately I still don't think there is much testing to be done for correctness (codegen tests or parsed value checks) until we have basic library support. I think that will be the next step.

Tracking issue: https://github.com/rust-lang/rust/issues/116909

r? `@compiler-errors`
cc `@Nilstrieb`
`@rustbot` label +F-f16_and_f128
2024-03-16 02:02:00 +00:00
Maybe Waffle
adfdd273ae Add rustc_never_type_mode = "no_fallback" 2024-03-15 17:48:26 +00:00
Maybe Waffle
19bc337063 Add rustc_never_type_mode crate-level attribute to allow experimenting 2024-03-15 17:48:26 +00:00
Trevor Gross
e782d27ec6 Add feature gates for f16 and f128
Includes related tests and documentation pages.

Michael Goulet: Don't issue feature error in resolver for f16/f128
unless finalize

Co-authored-by: Michael Goulet <michael@errs.io>
2024-03-14 13:32:54 -04:00
surechen
5dd44f43c7 change some attribute to only_local 2024-03-14 17:12:39 +08:00
Vadim Petrochenkov
95ec17a793 privacy: Stabilize lint unnameable_types 2024-03-13 18:37:40 +03:00
Jacob Pratt
05f22c3614
Rollup merge of #121840 - oli-obk:freeze, r=dtolnay
Expose the Freeze trait again (unstably) and forbid implementing it manually

non-emoji version of https://github.com/rust-lang/rust/pull/121501

cc #60715

This trait is useful for generic constants (associated consts of generic traits). See the test (`tests/ui/associated-consts/freeze.rs`) added in this PR for a usage example. The builtin `Freeze` trait is the only way to do it, users cannot work around this issue.

It's also a useful trait for building some very specific abstrations, as shown by the usage by the `zerocopy` crate: https://github.com/google/zerocopy/issues/941

cc ```@RalfJung```

T-lang signed off on reexposing this unstably: https://github.com/rust-lang/rust/pull/121501#issuecomment-1969827742
2024-03-11 03:47:19 -04:00
Martin Nordholts
ee428c55b2 diagnostics: Do not suggest using #[unix_sigpipe] without a value
Remove `Word` from the `unix_sigpipe` attribute template so that plain
`#[unix_sigpipe]` is not included in suggestions of valid forms of the
attribute. Also re-arrange diagnostics code slightly to avoid duplicate
diagnostics.
2024-03-10 15:12:50 +01:00
Michael Goulet
c63f3feb0f Stabilize associated type bounds 2024-03-08 20:56:25 +00:00
Matthias Krüger
d774fbea7c
Rollup merge of #119365 - nbdd0121:asm-goto, r=Amanieu
Add asm goto support to `asm!`

Tracking issue: #119364

This PR implements asm-goto support, using the syntax described in "future possibilities" section of [RFC2873](https://rust-lang.github.io/rfcs/2873-inline-asm.html#asm-goto).

Currently I have only implemented the `label` part, not the `fallthrough` part (i.e. fallthrough is implicit). This doesn't reduce the expressive though, since you can use label-break to get arbitrary control flow or simply set a value and rely on jump threading optimisation to get the desired control flow. I can add that later if deemed necessary.

r? ``@Amanieu``
cc ``@ojeda``
2024-03-08 08:19:17 +01:00
Guillaume Gomez
b0d7f2bb0e
Rollup merge of #119888 - weiznich:stablize_diagnostic_namespace, r=compiler-errors
Stabilize the `#[diagnostic]` namespace and `#[diagnostic::on_unimplemented]` attribute

This PR stabilizes the `#[diagnostic]` attribute namespace and a minimal option of the `#[diagnostic::on_unimplemented]` attribute.

The `#[diagnostic]` attribute namespace is meant to provide a home for attributes that allow users to influence error messages emitted by the compiler. The compiler is not guaranteed to use any of this hints, however it should accept any (non-)existing attribute in this namespace and potentially emit lint-warnings for unused attributes and options. This is meant to allow discarding certain attributes/options in the future to allow fundamental changes to the compiler without the need to keep then non-meaningful options working.

The `#[diagnostic::on_unimplemented]` attribute is allowed to appear on a trait definition. This allows crate authors to hint the compiler to emit a specific error message if a certain trait is not implemented. For the `#[diagnostic::on_unimplemented]` attribute the following options are implemented:

* `message` which provides the text for the top level error message
* `label` which provides the text for the label shown inline in the broken code in the error message
* `note` which provides additional notes.

The `note` option can appear several times, which results in several note messages being emitted. If any of the other options appears several times the first occurrence of the relevant option specifies the actually used value. Any other occurrence generates an lint warning. For any other non-existing option a lint-warning is generated.

All three options accept a text as argument. This text is allowed to contain format parameters referring to generic argument or `Self` by name via the `{Self}` or `{NameOfGenericArgument}` syntax. For any non-existing argument a lint warning is generated.

This allows to have a trait definition like:

```rust
#[diagnostic::on_unimplemented(
    message = "My Message for `ImportantTrait<{A}>` is not implemented for `{Self}`",
    label = "My Label",
    note = "Note 1",
    note = "Note 2"
)]
trait ImportantTrait<A> {}

```

which then generates for the following code

```rust
fn use_my_trait(_: impl ImportantTrait<i32>) {}

fn main() {
    use_my_trait(String::new());
}
```

this error message:

```
error[E0277]: My Message for `ImportantTrait<i32>` is not implemented for `String`
  --> src/main.rs:14:18
   |
14 |     use_my_trait(String::new());
   |     ------------ ^^^^^^^^^^^^^ My Label
   |     |
   |     required by a bound introduced by this call
   |
   = help: the trait `ImportantTrait<i32>` is not implemented for `String`
   = note: Note 1
   = note: Note 2
```

[Playground with the unstable feature](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=05133acce8e1d163d481e97631f17536)

Fixes #111996
2024-03-07 18:32:46 +01:00
Matthias Krüger
efe9deace8
Rollup merge of #121382 - nnethercote:rework-untranslatable_diagnostic-lint, r=davidtwco
Rework `untranslatable_diagnostic` lint

Currently it only checks calls to functions marked with `#[rustc_lint_diagnostics]`. This PR changes it to check calls to any function with an `impl Into<{D,Subd}iagnosticMessage>` parameter. This greatly improves its coverage and doesn't rely on people remembering to add `#[rustc_lint_diagnostics]`. It also lets us add `#[rustc_lint_diagnostics]` to a number of functions that don't have an `impl Into<{D,Subd}iagnosticMessage>`, such as `Diag::span`.

r? ``@davidtwco``
2024-03-06 22:02:46 +01:00
clubby789
c7030e9b91 Stabilize imported_main 2024-03-06 12:01:54 +00:00
Ross Smyth
68a58f255a Add postfix-match experimental feature
Co-authored-by: Josh Stone <jistone@redhat.com>
2024-03-05 23:34:45 -05:00
Nicholas Nethercote
b7d58eef4b Rewrite the untranslatable_diagnostic lint.
Currently it only checks calls to functions marked with
`#[rustc_lint_diagnostics]`. This commit changes it to check calls to
any function with an `impl Into<{D,Subd}iagMessage>` parameter. This
greatly improves its coverage and doesn't rely on people remembering to
add `#[rustc_lint_diagnostics]`.

The commit also adds `#[allow(rustc::untranslatable_diagnostic)`]
attributes to places that need it that are caught by the improved lint.
These places that might be easy to convert to translatable diagnostics.

Finally, it also:
- Expands and corrects some comments.
- Does some minor formatting improvements.
- Adds missing `DecorateLint` cases to
  `tests/ui-fulldeps/internal-lints/diagnostics.rs`.
2024-03-06 14:19:01 +11:00
Matthias Krüger
c1bb406a21
Rollup merge of #122014 - surechen:change_attributes_to_local_20240304, r=lcnr
Change some attributes to only_local.

Modified according to https://github.com/rust-lang/compiler-team/issues/505.

r? ``@lcnr``
2024-03-05 22:10:01 +01:00
surechen
8dd126d847 Change some attributes to only_local.
Modified according to https://github.com/rust-lang/compiler-team/issues/505.
2024-03-05 18:31:11 +08:00
Oli Scherer
1e57df1969 Add a scheme for moving away from extern "rust-intrinsic" entirely 2024-03-04 16:13:50 +00:00
Guillaume Gomez
be31b6b6cd Add new pattern_complexity attribute to add possibility to limit and check recursion in pattern matching 2024-03-03 13:10:15 +01:00
Oli Scherer
7849230740 Forbid implementing Freeze even if the trait is stabilized 2024-02-29 14:10:29 +00:00
Jacob Pratt
69716291c3
Rollup merge of #121740 - surechen:change_attribute_to_local_20240228, r=lcnr
Changing some attributes to only_local.

Modified according to https://github.com/rust-lang/compiler-team/issues/505.

r?  ``@lcnr``
2024-02-29 05:25:27 -05:00
surechen
11f948952f Changing some attributes to only_local.
Modified according to https://github.com/rust-lang/compiler-team/issues/505.
2024-02-28 22:46:02 +08:00
Georg Semmler
d013b5a462
Stabilize the #[diagnostic] namespace and #[diagnostic::on_unimplemented] attribute
This PR stabilizes the `#[diagnostic]` attribute namespace and a minimal
option of the `#[diagnostic::on_unimplemented]` attribute.

The `#[diagnostic]` attribute namespace is meant to provide a home for
attributes that allow users to influence error messages emitted by the
compiler. The compiler is not guaranteed to use any of this hints,
however it should accept any (non-)existing attribute in this namespace
and potentially emit lint-warnings for unused attributes and options.
This is meant to allow discarding certain attributes/options in the
future to allow fundamental changes to the compiler without the need to
keep then non-meaningful options working.

The `#[diagnostic::on_unimplemented]` attribute is allowed to appear
on a trait definition. This allows crate authors to hint the compiler
to emit a specific error message if a certain trait is not implemented.
For the `#[diagnostic::on_unimplemented]` attribute the following
options are implemented:

* `message` which provides the text for the top level error message
* `label` which provides the text for the label shown inline in the
broken code in the error message
* `note` which provides additional notes.

The `note` option can appear several times, which results in several
note messages being emitted. If any of the other options appears several
times the first occurrence of the relevant option specifies the actually
used value. Any other occurrence generates an lint warning. For any
other non-existing option a lint-warning is generated.

All three options accept a text as argument. This text is allowed to
contain format parameters referring to generic argument or `Self` by
name via the `{Self}` or `{NameOfGenericArgument}` syntax. For any
non-existing argument a lint warning is generated.

Tracking issue: #111996
2024-02-27 08:50:56 +01:00
surechen
03a10a917a Changing some attributes to only_local.
Modified according to https://github.com/rust-lang/compiler-team/issues/505.

By running test cases, I found that modifying the attribute's only_local tag sometimes causes some unintuitive error reports, so I tend to split it into multiple PRs and edit a small number of attributes each time to prevent too many changes at once. Prevent possible subsequent difficulties in locating problems.
2024-02-27 10:45:19 +08:00
bors
5c786a7fe3 Auto merge of #121516 - RalfJung:platform-intrinsics-begone, r=oli-obk
remove platform-intrinsics ABI; make SIMD intrinsics be regular intrinsics

`@Amanieu` `@workingjubilee` I don't think there is any reason these need to be "special"? The [original RFC](https://rust-lang.github.io/rfcs/1199-simd-infrastructure.html) indicated eventually making them stable, but I think that is no longer the plan, so seems to me like we can clean this up a bit.

Blocked on https://github.com/rust-lang/stdarch/pull/1538, https://github.com/rust-lang/rust/pull/121542.
2024-02-26 22:24:16 +00:00
Matthias Krüger
6e3ece3aac
Rollup merge of #121493 - surechen:edit_attribute_only_local, r=lcnr
By changing some attributes to only_local, reducing encoding attributes in the crate metadate.

Thank you.
This is part of changing attributes to only_local. I hope get your opinion  whether I should split into multiple PRs, or submit in one.

According to [try to not rely on attributes from extern crates](https://github.com/rust-lang/compiler-team/issues/505) and lcnr's guidance.
2024-02-26 16:06:03 +01:00
Matthias Krüger
e13f454874
Rollup merge of #119590 - ChrisDenton:cfg-target-abi, r=Nilstrieb
Stabilize `cfg_target_abi`

This stabilizes the `cfg` option called `target_abi`:

```rust
#[cfg(target_abi = "eabihf")]
```

Tracking issue: #80970

fixes #78791
resolves #80970
2024-02-25 17:05:19 +01:00
Ralf Jung
cc3df0af7b remove platform-intrinsics ABI; make SIMD intrinsics be regular intrinsics 2024-02-25 08:14:52 +01:00
bors
e9f9594913 Auto merge of #121114 - Nilstrieb:no-inline!, r=saethlin
Add `#[rustc_no_mir_inline]` for standard library UB checks

should help with #121110 and also with #120848

Because the MIR inliner cannot know whether the checks are enabled or not, so inlining is an unnecessary compile time pessimization when debug assertions are disabled. LLVM knows whether they are enabled or not, so it can optimize accordingly without wasting time.

r? `@saethlin`
2024-02-25 03:47:31 +00:00
Chris Denton
93ec0e6299
Stabilize cfg_target_abi 2024-02-24 17:52:03 -03:00