Add offset_of! macro (RFC 3308)
Implements https://github.com/rust-lang/rfcs/pull/3308 (tracking issue #106655) by adding the built in macro `core::mem::offset_of`. Two of the future possibilities are also implemented:
* Nested field accesses (without array indexing)
* DST support (for `Sized` fields)
I wrote this a few months ago, before the RFC merged. Now that it's merged, I decided to rebase and finish it.
cc `@thomcc` (RFC author)
Allow to feed a value in another query's cache and remove `WithOptConstParam`
I used it to remove `WithOptConstParam` queries, as an example.
The idea is that a query (here `typeck(function)`) can write into another query's cache (here `type_of(anon const)`). The dependency node for `type_of` would depend on all the current dependencies of `typeck`.
There is still an issue with cycles: if `type_of(anon const)` is accessed before `typeck(function)`, we will still have the usual cycle. The way around this issue is to `ensure` that `typeck(function)` is called before accessing `type_of(anon const)`.
When replayed, we may the following cases:
- `typeck` is green, in that case `type_of` is green too, and all is right;
- `type_of` is green, `typeck` may still be marked as red (it depends on strictly more things than `type_of`) -> we verify that the saved value and the re-computed value of `type_of` have the same hash;
- `type_of` is red, then `typeck` is red -> it's the caller responsibility to ensure `typeck` is recomputed *before* `type_of`.
As `anon consts` have their own `DefPathData`, it's not possible to have the def-id of the anon-const point to something outside the original function, but the general case may have to be resolved before using this device more broadly.
There is an open question about loading from the on-disk cache. If `typeck` is loaded from the on-disk cache, the side-effect does not happen. The regular `type_of` implementation can go and fetch the correct value from the decoded `typeck` results, and the dep-graph will check that the hashes match, but I'm not sure we want to rely on this behaviour.
I specifically allowed to feed the value to `type_of` from inside a call to `type_of`. In that case, the dep-graph will check that the fingerprints of both values match.
This implementation is still very sensitive to cycles, and requires that we call `typeck(function)` before `typeck(anon const)`. The reason is that `typeck(anon const)` calls `type_of(anon const)`, which calls `typeck(function)`, which feeds `type_of(anon const)`, and needs to build the MIR so needs `typeck(anon const)`. The latter call would not cycle, since `type_of(anon const)` has been set, but I'd rather not remove the cycle check.
Substitute missing trait items suggestion correctly
Properly substitute missing item suggestions, so that when they reference generics from their parent trait they actually have the right time for the impl.
Also, some other minor tweaks like using `/* Type */` to signify a GAT's type is actually missing, and fixing generic arg suggestions for GATs in general.
fix lint regression in `non_upper_case_globals`
Fixes#110573
The issue also exists for inherent associated types (where I copied my impl from). `EarlyContext` is more involved to fix in this way, so I'll leave it be for now (note it's unstable so that's not urgent).
r? `@compiler-errors`
Implement `Neg` for signed non-zero integers.
Negating a non-zero integer currently requires unpacking to a primitive and re-wrapping. Since negation of non-zero signed integers always produces a non-zero result, it is safe to implement `Neg` for `NonZeroI{N}`.
The new `impl` is marked as stable because trait impls for two stable types can't be marked unstable.
See discussion on https://github.com/rust-lang/libs-team/issues/105 for additional context.
Negating a non-zero integer currently requires unpacking to a
primitive and re-wrapping. Since negation of non-zero signed
integers always produces a non-zero result, it is safe to
implement `Neg` for `NonZeroI{N}`.
The new `impl` is marked as stable because trait implementations
for two stable types can't be marked unstable.
Add suggestion to use closure argument instead of a capture on borrowck error
Fixes#109271
r? `@compiler-errors`
This should probably be refined a bit, but opening a PR so that I don't forget anything.
Support AIX-style archive type
Reading facility of AIX big archive has been supported by `object` since 0.30.0.
Writing facility of AIX big archive has already been supported by `ar_archive_writer`, but we need to bump the version to support the new archive type enum.
make `non_upper_case_globals` lint not report trait impls
We should not lint on trait `impl`s for `non_upper_case_globals`; the user doesn't have control over the name. This brings `non_upper_case_globals` into consistency with other `nonstandard_style` lints.
Fix no_std tests that load libc from the sysroot when download-rustc is enabled
There were a series of unfortunate interactions here. Here's an MCVE of the test this fixes (committed as `tests/ui/meta/no_std-extern-libc.rs`):
```rust
#![crate_type = "lib"]
#![no_std]
#![feature(rustc_private)]
extern crate libc;
```
Before, this would give an error about duplicate versions of libc:
```
error[E0464]: multiple candidates for `rlib` dependency `libc` found
--> fake-test-src-base/allocator/no_std-alloc-error-handler-default.rs:15:1
|
LL | extern crate libc;
| ^^^^^^^^^^^^^^^^^^
|
= note: candidate #1: /home/gh-jyn514/rust/build/aarch64-unknown-linux-gnu/stage2/lib/rustlib/aarch64-unknown-linux-gnu/lib/liblibc-358db1024b7d9957.rlib
= note: candidate #2: /home/gh-jyn514/rust/build/aarch64-unknown-linux-gnu/stage2/lib/rustlib/aarch64-unknown-linux-gnu/lib/liblibc-ebc478710122a279.rmeta
```
Both these versions were downloaded from CI, but one came from the `rust-std` component and one came from `rustc-dev`:
```
; tar -tf build/cache/f2d9a3d0771504f1ae776226a5799dcb4408a91a/rust-std-nightly-x86_64-unknown-linux-gnu.tar.xz | grep liblibc
rust-std-nightly-x86_64-unknown-linux-gnu/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-68a2d9e195dd6ed2.rlib
; tar -tf build/cache/f2d9a3d0771504f1ae776226a5799dcb4408a91a/rustc-dev-nightly-x86_64-unknown-linux-gnu.tar.xz | grep liblibc
rustc-dev-nightly-x86_64-unknown-linux-gnu/rustc-dev/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-f226c9fbdd92a0fd.rmeta
```
The fix was to only copy files from `rust-std` unless a Step explicitly requests for the `rustc-dev` components to be available by calling `builder.ensure(compile::Rustc)`.
To avoid having to re-parse the `rustc-dev.tar.xz` tarball every time, which is quite slow, this adds a new `build/host/ci-rustc/.rustc-dev-contents` cache file which stores only the names of files we need to copy into the sysroot.
This also allows reverting the hack in https://github.com/rust-lang/rust/pull/110121; now that we only copy rustc-dev on-demand, we can correctly add the `Rustc` check artifacts into the sysroot, so that this works correctly even when `download-rustc` is forced to `true` and some tool depends on a local change to `compiler`.
---
See https://github.com/rust-lang/rust/issues/108767#issuecomment-1501217657 for why `no_std` is required for the MCVE test to fail; it's complicated and not particularly important.
Fixes https://github.com/rust-lang/rust/issues/108767.
There were a series of unfortunate interactions here. Here's an MCVE of the test this fixes (committed as `tests/ui/meta/no_std-extern-libc.rs`):
```rust
#![crate_type = "lib"]
#![no_std]
#![feature(rustc_private)]
extern crate libc;
```
Before, this would give an error about duplicate versions of libc:
```
error[E0464]: multiple candidates for `rlib` dependency `libc` found
--> fake-test-src-base/allocator/no_std-alloc-error-handler-default.rs:15:1
|
LL | extern crate libc;
| ^^^^^^^^^^^^^^^^^^
|
= note: candidate #1: /home/gh-jyn514/rust/build/aarch64-unknown-linux-gnu/stage2/lib/rustlib/aarch64-unknown-linux-gnu/lib/liblibc-358db1024b7d9957.rlib
= note: candidate #2: /home/gh-jyn514/rust/build/aarch64-unknown-linux-gnu/stage2/lib/rustlib/aarch64-unknown-linux-gnu/lib/liblibc-ebc478710122a279.rmeta
```
Both these versions were downloaded from CI, but one came from the `rust-std` component and one came from `rustc-dev`:
```
; tar -tf build/cache/f2d9a3d0771504f1ae776226a5799dcb4408a91a/rust-std-nightly-x86_64-unknown-linux-gnu.tar.xz | grep liblibc
rust-std-nightly-x86_64-unknown-linux-gnu/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-68a2d9e195dd6ed2.rlib
; tar -tf build/cache/f2d9a3d0771504f1ae776226a5799dcb4408a91a/rustc-dev-nightly-x86_64-unknown-linux-gnu.tar.xz | grep liblibc
rustc-dev-nightly-x86_64-unknown-linux-gnu/rustc-dev/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-f226c9fbdd92a0fd.rmeta
```
The fix was to only copy files from `rust-std` unless a Step explicitly requests for the `rustc-dev` components to be available by calling `builder.ensure(compile::Rustc)`.
To avoid having to re-parse the `rustc-dev.tar.xz` tarball every time, which is quite slow, this adds a new `build/host/ci-rustc/.rustc-dev-contents` cache file which stores only the names of files we need to copy into the sysroot.
This also allows reverting the hack in
https://github.com/rust-lang/rust/pull/110121; now that we only copy
rustc-dev on-demand, we can correctly add the `Rustc` check artifacts
into the sysroot, so that this works correctly even when
`download-rustc` is forced to `true`.
---
See https://github.com/rust-lang/rust/issues/108767#issuecomment-1501217657 for why `no_std` is required for the MCVE test to fail; it's complicated and not particularly important.
Fixes https://github.com/rust-lang/rust/issues/108767.
Support `x test --stage 1 ui-fulldeps`
`@Nilstrieb` had an excellent idea the other day: the same way that rustdoc is able to load `rustc_driver` from the sysroot, ui-fulldeps tests should also be able to load it from the sysroot. That allows us to run fulldeps tests with stage1, without having to fully rebuild the compiler twice. It does unfortunately have the downside that we're building the tests with the *bootstrap* compiler, not the in-tree sources, but since most of the fulldeps tests are for the *API* of the compiler, that seems ok.
I think it's possible to extend this to `run-make-fulldeps`, but I've run out of energy for tonight.
- Move `plugin` tests into a subdirectory.
Plugins are loaded at runtime with `dlopen` and so require the ABI of the running compile to match the ABI of the compiler linked with `rustc_driver`. As a result they can't be supported in stage 1 and have to use `// ignore-stage1`.
- Remove `ignore-stage1` from most non-plugin tests
- Ignore diagnostic tests in stage 1. Even though this requires a stage 2 build to load rustc_driver, it's primarily testing the error message that the *running* compiler emits when the diagnostic struct is malformed.
- Pass `-Zforce-unstable-if-unmarked` in stage1, not just stage2. That allows running `hash-stable-is-unstable` in stage1, since it now suggests adding `rustc_private` to enable loading the crates.
- Add libLLVM.so to the stage0 target sysroot, to allow fulldeps tests that act as custom drivers to load it at runtime.
- Pass `--sysroot stage0-sysroot` in compiletest so that we use the correct version of std.
- Move a few lint tests from ui-fulldeps to ui
These had an `aux-build:lint-group-plugin-test.rs` that they never actually loaded with `feature(plugin)` nor tested. I removed the unused aux-build and they pass fine with stage 1.
Fixes https://github.com/rust-lang/rust/issues/75905.
Nils had an excellent idea the other day: the same way that rustdoc is
able to load `rustc_driver` from the sysroot, ui-fulldeps tests should
also be able to load it from the sysroot. That allows us to run fulldeps
tests with stage1, without having to fully rebuild the compiler twice.
It does unfortunately have the downside that we're running the tests on
the *bootstrap* compiler, not the in-tree sources, but since most of the
fulldeps tests are for the *API* of the compiler, that seems ok.
I think it's possible to extend this to `run-make-fulldeps`, but I've
run out of energy for tonight.
- Move `plugin` tests into a subdirectory.
Plugins are loaded at runtime with `dlopen` and so require the ABI of
the running compile to match the ABI of the compiler linked with
`rustc_driver`. As a result they can't be supported in stage 1 and have
to use `// ignore-stage1`.
- Remove `ignore-stage1` from most non-plugin tests
- Ignore diagnostic tests in stage 1. Even though this requires a stage
2 build to load rustc_driver, it's primarily testing the error message
that the *running* compiler emits when the diagnostic struct is malformed.
- Pass `-Zforce-unstable-if-unmarked` in stage1, not just stage2. That
allows running `hash-stable-is-unstable` in stage1, since it now
suggests adding `rustc_private` to enable loading the crates.
- Add libLLVM.so to the stage0 target sysroot, to allow fulldeps tests
that act as custom drivers to load it at runtime.
- Pass `--sysroot stage0-sysroot` in compiletest so that we use the
correct version of std.
Check freeze with right param-env in `deduced_param_attrs`
We're checking if a trait (`Freeze`) holds in a polymorphic function, but not using that function's own (reveal-all) param-env. This causes us to try to eagerly normalize a specializable projection type that has no default value, which causes an ICE.
Fixes#110171
Remove `remap_env_constness` in queries
This removes some of the complexities with const traits. #88119 used to be caused by this but was fixed by `param_env = param_env.without_const()`.
Update some ignored tests.
This unignores some tests which no longer need to be ignored (see individual commits for reasons why). This also adds some descriptions to why tests are ignored so they can be seen in the test output.
suggest lifetime for closure parameter type when mismatch
This is a draft PR, will add test cases later and be ready for review.
This PR fixes https://github.com/rust-lang/rust/issues/105675 by adding a diagnostics suggestion. Also a partial fix to https://github.com/rust-lang/rust/issues/105528.
The following code will have a compile error now:
```
fn const_if_unit(input: bool) -> impl for<'a> FnOnce(&'a ()) -> usize {
let x = |_| 1;
x
}
```
Before this PR:
```
error[E0308]: mismatched types
--> src/lib.rs:3:5
|
3 | x
| ^ one type is more general than the other
|
= note: expected trait `for<'a> FnOnce<(&'a (),)>`
found trait `FnOnce<(&(),)>`
note: this closure does not fulfill the lifetime requirements
--> src/lib.rs:2:13
|
2 | let x = |_| 1;
| ^^^
error: implementation of `FnOnce` is not general enough
--> src/lib.rs:3:5
|
3 | x
| ^ implementation of `FnOnce` is not general enough
|
= note: closure with signature `fn(&'2 ()) -> usize` must implement `FnOnce<(&'1 (),)>`, for any lifetime `'1`...
= note: ...but it actually implements `FnOnce<(&'2 (),)>`, for some specific lifetime `'2`
For more information about this error, try `rustc --explain E0308`.
error: could not compile `rust-test` due to 2 previous errors
```
After this PR:
```
error[E0308]: mismatched types
--> src/lib.rs:3:5
|
3 | x
| ^ one type is more general than the other
|
= note: expected trait `for<'a> FnOnce<(&'a (),)>`
found trait `FnOnce<(&(),)>`
note: this closure does not fulfill the lifetime requirements
--> src/lib.rs:2:13
|
2 | let x = |_| 1;
| ^^^
help: consider changing the type of the closure parameters
|
2 | let x = |_: &_| 1;
| ~~~~~~~
error: implementation of `FnOnce` is not general enough
--> src/lib.rs:3:5
|
3 | x
| ^ implementation of `FnOnce` is not general enough
|
= note: closure with signature `fn(&'2 ()) -> usize` must implement `FnOnce<(&'1 (),)>`, for any lifetime `'1`...
= note: ...but it actually implements `FnOnce<(&'2 (),)>`, for some specific lifetime `'2`
For more information about this error, try `rustc --explain E0308`.
error: could not compile `rust-test` due to 2 previous errors
```
After applying the suggestion, it compiles. The suggestion might not always be correct as the generation procedure of that suggestion is quite simple...
This test was ignored long ago in
https://github.com/rust-lang/rust/pull/20578/ when the syntax for
closures was changed.
The current status is that a closure with an explicit `!` return type
will trigger the `unreachable_code` lint which appears to be the
original intent of the test
(https://github.com/rust-lang/rust/pull/16836). A closure without a
return type won't trigger the lint since the `!` type isn't inferred
(AFAIK). This restores the test to its original form.
Do not attempt to commute comparison and cast to codegen discriminants
The general algorithm to compute a discriminant is:
```
relative_tag = tag - niche_start
is_niche = relative_tag <= (ule) relative_max
discr = if is_niche {
cast(relative_tag) + niche_variants.start()
} else {
untagged_variant
}
```
We have an optimization branch which attempts to merge the addition and the subtraction by commuting them with the cast. We currently get this optimization wrong.
This PR takes the easiest and safest way: remove the optimization, and let LLVM handle it. (Perf may not agree with that course of action 😅)
There may be a less invasive solution, but I don't have the necessary knowledge of LLVM semantics to find it. Cranelift has the same optimization, which should be handled similarly.
cc `@nikic` and `@bjorn3` if you have a better solution.
Fixes https://github.com/rust-lang/rust/issues/110128
Reformulate `point_at_expr_source_of_inferred_type` to be more accurate
Be more accurate when deducing where along the several usages of a binding it is constrained to be some type that is incompatible with an expectation.
This also renames the method to `note_source_of_type_mismatch_constraint` because I prefer that name, though I guess I can revert that. (Also drive-by rename `note_result_coercion` -> `suggest_coercing_result_via_try_operator`, because it's suggesting, not noting!)
This PR is (probably?) best reviewed per commit, but it does regress a bit only to fix it later on, so it could also be reviewed as a whole if that makes the final results more clear.
r? `@estebank`
Remove all but one of the spans in `BoundRegionKind::BrAnon`
There are only three places where `BoundRegionKind::BrAnon` uses `Some(span)` instead of `None`. Two of them are easy to remove, which this PR does.
r? ```@jackh726```
don't uniquify regions when canonicalizing
uniquifying causes a bunch of issues, most notably it causes `AliasEq(<?x as Trait<'a>>::Assoc, <?x as Trait<'a>>::Assoc)` to result in ambiguity because both `normalizes-to` paths result in ambiguity and substs equate should trivially succeed but doesn't because we uniquified `'a` to two different regions.
I originally added uniquification to make it easier to deal with requirement 6 from the dev-guide: https://rustc-dev-guide.rust-lang.org/solve/trait-solving.html#requirements
> ### 6. Trait solving must be (free) lifetime agnostic
>
> Trait solving during codegen should have the same result as during typeck. As we erase
> all free regions during codegen we must not rely on them during typeck. A noteworthy example
> is special behavior for `'static`.
cc https://github.com/rust-lang/rustc-dev-guide/pull/1671
Relying on regions being identical may cause ICE during MIR typeck, but even without this PR we can end up relying on that as type inference vars can resolve to types which contain an identical region. Let's land this and deal with any ICE that crop up as we go. Will look at this issue again before stabilization.
r? ```@compiler-errors```
Improve safe transmute error reporting
This patch updates the error reporting when Safe Transmute is not possible between 2 types by including the reason.
Also, fix some small bugs that occur when computing the `Answer` for transmutability.
The `std` test straightforwardly can't work without file descriptors;
#99417 tracks moving it out of tests/ui.
`issue-13560.rs` requires the target to support dynamic linking.
`extern-mod-syntax` is interesting. The original test was added to check
if `extern mod` could be parsed correctly and used `extern mod std` and
an import:
138dc3048a (diff-73700e1e851b7a37bc92174635dab726124c82e5bfabbbc45b4a3c2e8e14fadd)
At some point `std::json::Object` was moved out of std to an unstable
rustc-only `extras` crate, and rather than just changing the import it
got changed to use the unstable crate. When `extras` was removed, people
assumed the test was meant to also test rustc_private and changed it to
another unstable crate rather than using something in std.
This changes the test to remove the `rustc_private` import, to allow it
to work properly when cross-compiling.
This patch updates the error reporting when Safe Transmute is not
possible between 2 types by including the reason.
Also, fix some small bugs that occur when computing the `Answer` for
transmutability.
Added diagnostic for pin! macro in addition to Box::pin if Unpin isn't implemented
I made a PR earlier, but accidentally renamed a branch and that deleted the PR... sorry for the duplicate
Currently, if an operation on `Pin<T>` is performed that requires `T` to implement `Unpin`, the diagnostic suggestion is to use `Box::pin` ("note: consider using `Box::pin`").
This PR suggests pin! as well, as that's another valid way of pinning a value, and avoids a heap allocation. Appropriate diagnostic suggestions were included to highlight the difference in semantics (local pinning for pin! vs non-local for Box::pin).
Fixes#109964
Check for body owner fallibly in error reporting
Sometimes the "body id" we use for an obligation cause is not actually a body owner, like when we're doing WF checking on items.
Fixes#110157
Erase lifetimes above `ty::INNERMOST` when probing ambiguous types
Turns out that `TyCtxt::replace_escaping_bound_vars_uncached` only erases bound vars exactly at `ty::INNERMOST`, and not everything above. This regresses the suggestions for non-lifetime binders, but oh well, I don't really care about those.
Fixes#110052
Preserve argument indexes when inlining MIR
We store argument indexes on VarDebugInfo. Unlike the previous method of relying on the variable index to know whether a variable is an argument, this survives MIR inlining.
We also no longer check if var.source_info.scope is the outermost scope. When a function gets inlined, the arguments to the inner function will no longer be in the outermost scope. What we care about though is whether they were in the outermost scope prior to inlining, which we know by whether we assigned an argument index.
Fixes#83217
I considered using `Option<NonZeroU16>` instead of `Option<u16>` to store the index. I didn't because `TypeFoldable` isn't implemented for `NonZeroU16` and because it looks like due to padding, it currently wouldn't make any difference. But I indexed from 1 anyway because (a) it'll make it easier if later it becomes worthwhile to use a `NonZeroU16` and because the arguments were previously indexed from 1, so it made for a smaller change.
This is my first PR on rust-lang/rust, so apologies if I've gotten anything not quite right.
Do not use ImplDerivedObligationCause for inherent impl method error reporting
We were constructing a `TraitRef` out of impl substs, for an *inherent* impl that has no corresponding trait. Instead of doing that, let's construct a meaningful obligation cause code, and instead adjust the error reporting machinery to handle that correctly.
Fixes#110131
cc #106702, which introduced this regression
fix: ensure bad `#[test]` invocs retain correct AST
Fixes#109816
Ensures that a `StmtKind::Item` doesn't get converted into a plain `Item` (causing the ICE from the linked issue) Also unifies the error path a bit.
Rollup of 8 pull requests
Successful merges:
- #110153 (Fix typos in compiler)
- #110165 (rustdoc: use CSS `overscroll-behavior` instead of JavaScript)
- #110175 (Symbol cleanups)
- #110203 (Remove `..` from return type notation)
- #110205 (rustdoc: make settings radio and checks thicker, less contrast)
- #110222 (Improve the error message when forwarding a matched fragment to another macro)
- #110237 (Split out a separate feature gate for impl trait in associated types)
- #110241 (tidy: Issue an error when UI test limits are too high)
Failed merges:
- #110218 (Remove `ToRegionVid`)
r? `@ghost`
`@rustbot` modify labels: rollup
Split out a separate feature gate for impl trait in associated types
in https://github.com/rust-lang/rust/issues/107645 it was decided that we'll take a new route for type alias impl trait. The exact route isn't clear yet, so while I'm working on implementing some of these proposed changes (e.g. in https://github.com/rust-lang/rust/pull/110010) to be able to experiment with them, I will also work on stabilizing another sugar version first: impl trait in associated types. Similarly I'll look into creating feature gates for impl trait in const/static types.
This PR does nothing but split the feature gate, so that you need to enable a different feature gate for
```rust
impl Trait for Type {
type Assoc = impl SomeTrait;
}
```
than what you need for `type Foo = impl SomeTrait;`
Improve the error message when forwarding a matched fragment to another macro
Adds a link to [Forwarding a matched fragment](https://doc.rust-lang.org/nightly/reference/macros-by-example.html#forwarding-a-matched-fragment) section of the Rust Reference, and suggests a possible fix (using `:tt` instead in the macro definition).
Also removes typos from the original message, it should be `:lifetime` instead of `$lifetime`.
## Motivation
When trying to write a macro which uses a literal in the matcher from the outer macro, like the following one, using a fragment specified that isn't one of `:ident`, `:lifetime`, or `:tt` currently results in a hard to understand message.
```rs
macro_rules! make_t_for_all_tokens {
($($name:literal as $variant:expr,)*) => {
macro_rules! t {
$(
($name) => {
$variant
};
)*
}
};
}
make_t_for_all_tokens! {
"fn" as Token::Fn,
"return" as Token::Return,
"let" as Token::Let,
}
// This creates
//
// macro_rules! t {
// ("fn") => {
// Token::Fn
// };
// ("return") => {
// Token::Return
// };
// ("let") => {
// Token::Let
// };
// }
t!["fn"];
```
### Before
```
error: no rules expected the token `"fn"`
--> src/main.rs:103:10
|
32 | macro_rules! t {
| -------------- when calling this macro
...
103 | t!["fn"];
| ^^^^ no rules expected this token in macro call
|
note: while trying to match `"fn"`
--> src/main.rs:34:6
|
34 | ($name) => {
| ^^^^^
...
58 | / make_t_for_all_tokens! {
59 | | "fn" as Token::Fn,
60 | | "return" as Token::Return,
61 | | "let" as Token::Let,
62 | | }
| |_- in this macro invocation
= note: captured metavariables except for `$tt`, `$ident` and `$lifetime` cannot be compared to other tokens
= note: this error originates in the macro `make_t_for_all_tokens` (in Nightly builds, run with -Z macro-backtrace for more info)
```
### After
```
error: no rules expected the token `"fn"`
--> src/main.rs:103:10
|
32 | macro_rules! t {
| -------------- when calling this macro
...
103 | t!["fn"];
| ^^^^ no rules expected this token in macro call
|
note: while trying to match `"fn"`
--> src/main.rs:34:6
|
34 | ($name) => {
| ^^^^^
...
58 | / make_t_for_all_tokens! {
59 | | "fn" as Token::Fn,
60 | | "return" as Token::Return,
61 | | "let" as Token::Let,
62 | | }
| |_- in this macro invocation
= note: captured metavariables except for `:tt`, `:ident` and `:lifetime` cannot be compared to other tokens
= note: see https://doc.rust-lang.org/nightly/reference/macros-by-example.html#forwarding-a-matched-fragment for more information
= help: try using `:tt` instead in the macro definition
= note: this error originates in the macro `make_t_for_all_tokens` (in Nightly builds, run with -Z macro-backtrace for more info)
```
## Unresolved questions
- Preferrably the suggestion should be attached to the `$name:literal` part of the outer macro, instead of being in the notes section at the end. But I'm not familiar with how the compiler works at all, and I have no idea how to approach this kind of solution.
- `@Nilstrieb` raised a question that the suggestion of adding `:tt` isn't accurate when there's more than `tt` being matched, for example when the input is an `item`.
Remove `..` from return type notation
`@nikomatsakis` and I decided that using `..` in the return-type notation syntax is probably overkill.
r? `@eholk` since you reviewed the last one
Since this is piggybacking now totally off of a pre-existing syntax (parenthesized generics), let me know if you need any explanation of the logic here, since it's a bit more complicated now.
Fix transmute intrinsic mir validation ICE
I stumbled across this at work, the minimal reproducer is included as a test which ICEs before this change.
I'm not 100% sure this is the right fix, but it matches what we do in `mir_assign_valid_types` so seems reasonable at least.
fixes#110151
r? `@lcnr` since they've been keeping the relevant logic correct, cc `@scottmcm`
Adds a link to the relevant part of The Rust Reference in the eror
message, and suggests a possible fix (replacing the fragment specifier
with :tt in the macro definition).
Fixes typos in the original message.
Signed-off-by: Lena Milizé <me@lvmn.org>
Split implied and super predicate queries, then allow elaborator to filter only supertraits
Split the `super_predicates_of` query into a new `implied_predicates_of` query. The former now only returns the *real* supertraits of a trait alias, and the latter now returns the implied predicates (which include all of the `where` clauses of the trait alias). The behavior of these queries is identical for regular traits.
Now that the two queries are split, we can add a new filter method to the elaborator, `filter_only_self()`, which can be used in instances that we need only the *supertrait* predicates, such as during the elaboration used in closure signature deduction. This toggles the usage of `super_predicates_of` instead of `implied_predicates_of` during elaboration of a trait predicate.
This supersedes #104745, and fixes the four independent bugs identified in that PR.
Fixes#104719Fixes#106238Fixes#110023Fixes#109514
r? types
Support safe transmute in new solver
Basically copies the same implementation as the old solver, but instead of looking for param types, we look for type or const placeholders.
Rename tests/ui/unique to tests/ui/box/unit
fixes https://github.com/rust-lang/rust/issues/109878
Since tests/ui/box already exists, I have temporarily named it boxed-box, but if another name sounds better, please let me know.
Initial support for loongarch64-unknown-linux-gnu
Hi, We hope to add a new port in rust for LoongArch.
LoongArch intro
LoongArch is a RISC style ISA which is independently designed by Loongson
Technology in China. It is divided into two versions, the 32-bit version (LA32)
and the 64-bit version (LA64). LA64 applications have application-level
backward binary compatibility with LA32 applications. LoongArch is composed of
a basic part (Loongson Base) and an expanded part. The expansion part includes
Loongson Binary Translation (LBT), Loongson VirtualiZation (LVZ), Loongson SIMD
EXtension (LSX) and Loongson Advanced SIMD EXtension(LASX).
Currently the LA464 processor core supports LoongArch ISA and the Loongson
3A5000 processor integrates 4 64-bit LA464 cores. LA464 is a four-issue 64-bit
high-performance processor core. It can be used as a single core for high-end
embedded and desktop applications, or as a basic processor core to form an
on-chip multi-core system for server and high-performance machine applications.
Documentations:
ISA:
https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html
ABI:
https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html
More docs can be found at:
https://loongson.github.io/LoongArch-Documentation/README-EN.html
Since last year, we have locally adapted two versions of rust, rust1.41 and rust1.57, and completed the test locally.
I'm not sure if I'm submitting all the patches at once, so I split up the patches and here's one of the commits
Migrate most of `rustc_builtin_macros` to diagnostic impls
cc #100717
This is a couple of days work, but I decided to stop for now before the PR becomes too big. There's around 50 unresolved failures when `rustc::untranslatable_diagnostic` is denied, which I'll finish addressing once this PR goes thtough
A couple of outputs have changed, but in all instances I think the changes are an improvement/are more consistent with other diagnostics (although I'm happy to revert any which seem worse)
rustc_metadata: Filter encoded data more aggressively using `DefKind`
I focused on data that contains spans, because spans are expensive to encode/decode/hash, but also touched `should_encode_visibility` too.
One incorrect use of impl visibility in diagnostics is also replaced with trait visibility.
this test was added for rust 0.4 and doesn't test anything specific.
The repro originally relied on extern functions which are now just
ordinary methods. It's also a run pass test even though `main` has
been commented out.
Rollup of 8 pull requests
Successful merges:
- #109527 (Set up standard library path substitution in rust-gdb and gdbgui)
- #109752 (Stall auto trait assembly in new solver for int/float vars)
- #109860 (Add support for RISC-V relax target feature)
- #109923 (Update `error [E0449]: unnecessary visibility qualifier` to be more clear)
- #110070 (The `wrapping_neg` example for unsigned types shouldn't use `i8`)
- #110146 (fix(doc): do not parse inline when output is json for external crate)
- #110147 (Add regression test for #104916)
- #110149 (Update books)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Add regression test for #104916Closes#104916
I haven't tested if it still passes with debug assertions enabled so it'd be better to wait for CI to be green.
r? compiler-errors
Update `error [E0449]: unnecessary visibility qualifier` to be more clear
This updates the error message `error[E0449]: unnecessary visibility qualifier` by clearly indicating that visibility qualifiers already inherit their visibility from a parent item. The error message previously implied that the qualifiers were permitted, which is not the case anymore.
Resolves#109822.
We store argument indexes on VarDebugInfo. Unlike the previous method of
relying on the variable index to know whether a variable is an argument,
this survives MIR inlining.
We also no longer check if var.source_info.scope is the outermost scope.
When a function gets inlined, the arguments to the inner function will
no longer be in the outermost scope. What we care about though is
whether they were in the outermost scope prior to inlining, which we
know by whether we assigned an argument index.
Add suggestion to remove `derive()` if invoked macro is non-derive
Adds to the existing `expected derive macro, found {}` error message:
```
help: remove the surrounding "derive()":
--> $DIR/macro-path-prelude-fail-4.rs:1:3
|
LL | #[derive(inline)]
| ^^^^^^^ ^
```
This suggestion will either fix the issue, in the case that the macro was valid, or provide a better error message if not
Not ready for merge yet, as the highlighted span is only valid for trivial formatting. Is there a nice way to get the parent span of the macro path within `smart_resolve_macro_path`?
Closes#109589
Migrate remainder of rustc_ty_utils to `SessionDiagnostic`
This moves the remaining errors in `rust_ty_utils` to `SessionsDiagnostic`.
r? ``@davidtwco``
Instantiate instead of erasing binder when probing param methods
Fixes#108836
There is a really old comment saying that a `WhereClauseCandidate` probe candidate "should not contain any inference variables", but I'm not really confident that that comment applies anymore. In contrast, other candidates that we assemble during method probe contain inference variables in their substitutions (e.g. `InherentImplCandidate`)...
Since this change is made only to support a nightly feature, I'm happy to gate the new behavior behind this feature flag or discuss it further.
r? types
Better diagnostic when pattern matching tuple structs
Fixes#108284
When trying to pattern match a tuple struct we might get a flawed error message if there are missing fields. E.g.
```
let x = Foo(100, 200);
if let Foo { 0: bar } = x { ... }
```
Produces this error:
```
error[E0769]: tuple variant `Foo` written as struct variant
--> hello.rs:5:12
|
5 | if let Foo { 0: foo } = x {
| ^^^^^^^^^^^^^^
|
help: use the tuple variant pattern syntax instead
|
5 | if let Foo(_, _) = x {
| ~~~~~~
```
Which doesn't highlight that we can still use the struct syntax but we need to fill missing fields. This pr changes this error to:
```
error[E0027]: pattern does not mention field `1`
--> hello.rs:5:12
|
5 | if let Foo { 0: foo } = x {
| ^^^^^^^^^^^^^^ missing field `1`
|
help: include the missing field in the pattern
|
5 | if let Foo { 0: foo, 1: _ } = x {
| ~~~~~~~~
help: if you don't care about this missing field, you can explicitly ignore it
|
5 | if let Foo { 0: foo, .. } = x {
| ~~~~~~
```
Suggest defining const parameter when appropriate
Helps a bit with #91119.
Following #105523's lead, I use placeholder `/* Type */` instead of `_` in the suggestion.
It should be easier for newcomers to parse.
`@rustbot` label A-diagnostics
r? diagnostics
Enforce that `PointerLike` requires a pointer-like ABI
At least temporarily, let's ban coercing things that are pointer-sized and pointer-aligned but *not* `Abi::Scalar(..)` into `dyn*`. See: https://github.com/rust-lang/rust/pull/104694#discussion_r1142522073
This can be lifted in the future if we decie that we *want* to be able to coerce something `repr(C)` into a `dyn*`, but we'll have to figure out what to do with Miri and codegen...
r? compiler
Add ability to transmute (somewhat) with generic consts in arrays
Previously if the expression contained generic consts and did not have a directly equivalent type, transmuting the type in this way was forbidden, despite the two sizes being identical. Instead, we should be able to lazily tell if the two consts are identical, and if so allow them to be transmuted.
This is done by normalizing the forms of expressions into sorted order of multiplied terms, which is not generic over all expressions, but should handle most cases.
This allows for some _basic_ transmutations between types that are equivalent in size without requiring additional stack space at runtime.
I only see one other location at which `SizeSkeleton` is being used, and it checks for equality so this shouldn't affect anywhere else that I can tell.
See [this Stackoverflow post](https://stackoverflow.com/questions/73085012/transmute-nested-const-generic-array-rust) for what was previously necessary to convert between types. This PR makes converting nested `T -> [T; 1]` transmutes possible, and `[uB*2; N] -> [uB; N * 2]` possible as well.
I'm not sure whether this is something that would be wanted, and if it is it definitely should not be insta-stable, so I'd add a feature gate.
More descriptive error when qself path doesnt have a trait on the RHS of `as`
`<Ty as Enum>::Assoc` should report that `Enum` is a trait. Main question is whether to eagerly report the error, or raise it with `return Err(..)` -- i'll note that in an inline comment though.
cc `@GuillaumeGomez` who said this came up at a Paris Rust meetup.
r? `@petrochenkov`
Label `non_exhaustive` attribute on privacy errors from non-local items
Label when an ADT is `non_exhaustive` and we get a privacy error, help with confusion in a case like this:
```rust
#[non_exhaustive]
pub struct Foo;
// other crate
let x = Foo;
//~^ ERROR unit struct `Foo` is private
```
diagnostics: account for self type when looking for source of unsolved type variable
Fixes#109905.
When searching for the source of an unsolved infer var inside of a list of generic args, we look through the `tcx.generics_of(…).own_substs(…)` which *skips* the self type if present. However, the computed `argument_index` is later[^1] used to index into `tcx.generics_of(…).params` which may still contain the self type. In such case, we are off by one when indexing into the parameters.
From now on, we account for this immediately after calling `own_substs` which keeps things local.
This also fixes the wrong output in the preexisting UI test `inference/need_type_info/concrete-impl.rs` which was overlooked. It used to claim that the *type of type parameter `Self`* couldn't be inferred in `<Struct as Ambiguous<_>>::method()` which of course isn't true: `Self` equals `Struct` here, `A` couldn't be inferred.
`@rustbot` label A-diagnostics
[^1]: f98a271814/compiler/rustc_infer/src/infer/error_reporting/need_type_info.rs (L471)
Implement support for `GeneratorWitnessMIR` in new solver
r? ```@cjgillot```
I mostly want this to cut down the number of failing UI tests when running the UI test suite with `--compare-mode=next-solver`, but there doesn't seem like much reason to block implementing this since it adds minimal complexity to the existing structural traits impl in the new solver.
If others are against adding this for some reason, then maybe we should just make `GeneratorWitnessMIR` return `NoSolution` for these traits. Anything but an ICE please 😸🧊
Check pattern refutability on THIR
The current `check_match` query is based on HIR, but partially re-lowers HIR into THIR.
This PR proposed to use the results of the `thir_body` query to check matches, instead of re-building THIR.
Most of the diagnostic changes are spans getting shorter, or commas/semicolons not getting removed.
This PR degrades the diagnostic for confusing constants in patterns (`let A = foo()` where `A` resolves to a `const A` somewhere): it does not point ot the definition of `const A` any more.
Rollup of 7 pull requests
Successful merges:
- #109909 (Deny `use`ing tool paths)
- #109921 (Don't ICE when encountering `dyn*` in statics or consts)
- #109922 (Disable `has_thread_local` on OpenHarmony)
- #109926 (write threads info into log only when debugging)
- #109968 (Add regression test for #80409)
- #109969 (Add regression test for #86351)
- #109973 (rustdoc: Improve logo display very small screen)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Don't ICE when encountering `dyn*` in statics or consts
Since we have properly implemented `dyn*` support in CTFE (#107728), let's not ICE here anymore.
Fixes#105777
r? `@eholk`
Use SipHash-1-3 instead of SipHash-2-4 for StableHasher
Noticed this, and it seems easy and likely a perf win. IIUC we don't need DDOS resistance (just collision) so we ideally would have an even faster hash, but it's hard to beat this SipHash impl here, since it's been so highly tuned for the interface.
It wouldn't surprise me if there's some subtle reason changing this sucks, as it's so obvious it seems likely to have been done. Still, SipHash-1-3 seems to still have the guarantees StableHasher should need (and seemingly more), and is clearly less work. So it's worth a shot.
Not fully tested locally.
Validate `ignore` and `only` compiletest directive, and add human-readable ignore reasons
This PR adds strict validation for the `ignore` and `only` compiletest directives, failing if an unknown value is provided to them. Doing so uncovered 79 tests in `tests/ui` that had invalid directives, so this PR also fixes them.
Finally, this PR adds human-readable ignore reasons when tests are ignored due to `ignore` or `only` directives, like *"only executed when the architecture is aarch64"* or *"ignored when the operative system is windows"*. This was the original reason why I started working on this PR and #108659, as we need both of them for Ferrocene.
The PR is a draft because the code is extremely inefficient: it calls `rustc --print=cfg --target $target` for every rustc target (to gather the list of allowed ignore values), which on my system takes between 4s and 5s, and performs a lot of allocations of constant values. I'll fix both of them in the coming days.
r? `@ehuss`
Do not suppress temporary_cstring_as_ptr in macros.
There isn't really a reason to skip the lint when part of the expression comes from an expansion.
Fixes https://github.com/rust-lang/rust/issues/94694
Move a const-prop-lint specific hack from mir interpret to const-prop-lint and make it fallible
fixes#109743
This hack didn't need to live in the mir interpreter. For const-prop-lint it is entirely correct to avoid doing any const prop if normalization fails at this stage. Most likely we couldn't const propagate anything anyway, and if revealing was needed (so opaque types were involved), we wouldn't want to be too smart and leak the hidden type anyway.
Emit feature error for parenthesized generics in associated type bounds
We don't actually do AST->HIR lowering with some `-Zunpretty` flags, so it's not correct to just delay a bug instead of emitting a feature error.
Some diagnostics regressed because of the new errors, but oh well. 🤷Fixes#109898
Fix `non_exhaustive_omitted_patterns` lint span
Fixes#109837
`DUMMY_SP` was being passed as the span in many cases where we have a span available to use. This meant that the location of the violating pattern wasn't shown, or the list of un-covered variants
r? `@Nilstrieb`
Previously if the expression contained generic consts and did not have a directly equivalent
type, transmuting the type in this way was forbidden, despite the two sizes being identical.
Instead, we should be able to lazily tell if the two consts are identical, and if so allow them
to be transmuted.
Never consider int and float vars for `FnPtr` candidates
This solves a regression where `0.0.cmp()` was ambiguous when a custom trait with a `cmp` method was in scope.
For integers it shouldn't be a problem in practice so I wasn't able to add a test.
I'm not sure whether there could be more issues hidden in the shadows as mentioned in the issue, but this should at least fix the problematic regression immediately.
fixes#109892
r? oli-obk
This solves a regression where `0.0.cmp()` was ambiguous when a custom
trait with a `cmp` method was in scope.
FOr integers it shouldn't be a problem in practice so I wasn't able to
add a test.
Drop array patterns using subslices
Fixes#109004
Drops contiguous subslices of an array when moving elements out with a pattern, which improves perf for large arrays
r? `@compiler-errors`
Fix subslice capture in closure
Fixes#109298 by refining captures in the same way for Subslices and Indexes. The comment `// we never capture this` seems to have been inaccurate, as changing it to an assert causes many test failures
`@rustbot` label +A-closures
Move `doc(primitive)` future incompat warning to `invalid_doc_attributes`
Fixes#88070.
It's been a while since this was turned into a "future incompatible lint" so I think we can now turn it into a hard error without problem.
r? `@jyn514`
Initial support for return type notation (RTN)
See: https://smallcultfollowing.com/babysteps/blog/2023/02/13/return-type-notation-send-bounds-part-2/
1. Only supports `T: Trait<method(): Send>` style bounds, not `<T as Trait>::method(): Send`. Checking validity and injecting an implicit binder for all of the late-bound method generics is harder to do for the latter.
* I'd add this in a follow-up.
3. ~Doesn't support RTN in general type position, i.e. no `let x: <T as Trait>::method() = ...`~
* I don't think we actually want this.
5. Doesn't add syntax for "eliding" the function args -- i.e. for now, we write `method(): Send` instead of `method(..): Send`.
* May be a hazard if we try to add it in the future. I'll probably add it in a follow-up later, with a structured suggestion to change `method()` to `method(..)` once we add it.
7. ~I'm not in love with the feature gate name 😺~
* I renamed it to `return_type_notation` ✔️
Follow-up PRs will probably add support for `where T::method(): Send` bounds. I'm not sure if we ever want to support return-type-notation in arbitrary type positions. I may also make the bounds require `..` in the args list later.
r? `@ghost`
Something similar was previously removed as a part of #104602, but after this PR all table changes should also be "locally correct" after every update.
Insert alignment checks for pointer dereferences when debug assertions are enabled
Closes https://github.com/rust-lang/rust/issues/54915
- [x] Jake tells me this sounds like a place to use `MirPatch`, but I can't figure out how to insert a new basic block with a new terminator in the middle of an existing basic block, using `MirPatch`. (if nobody else backs up this point I'm checking this as "not actually a good idea" because the code looks pretty clean to me after rearranging it a bit)
- [x] Using `CastKind::PointerExposeAddress` is definitely wrong, we don't want to expose. Calling a function to get the pointer address seems quite excessive. ~I'll see if I can add a new `CastKind`.~ `CastKind::Transmute` to the rescue!
- [x] Implement a more helpful panic message like slice bounds checking.
r? `@oli-obk`
Closures always implement `FnOnce` in new solver
We should process `[closure]: FnOnce(Tys...) -> Ty` obligations *before* fallback and closure analysis. We can do this by taking advantage of the fact that `FnOnce` is always implemented by closures, even before we definitely know the closure kind.
Fixescompiler-errors/next-solver-hir-issues#15
r? ``@oli-obk`` (trying to spread the reviewer load for new trait solver prs, and this one is pretty self-contained, though feel free to reassign 😸)
Don't ICE on placeholder consts in deep reject
Since we canonicalize const params into placeholder consts, we need to be able to handle them during deep reject.
r? `@lcnr` (though maybe `@oli-obk` can look at this one too, if he wants 😸)
Fixescompiler-errors/next-solver-hir-issues#10
Rollup of 7 pull requests
Successful merges:
- #106985 (Enhanced doucmentation of binary search methods for `slice` and `VecDeque` for unsorted instances)
- #109509 (compiletest: Don't allow tests with overlapping prefix names)
- #109719 (RELEASES: Add "Only support Android NDK 25 or newer" to 1.68.0)
- #109748 (Don't ICE on `DiscriminantKind` projection in new solver)
- #109749 (Canonicalize float var as float in new solver)
- #109761 (Drop binutils on powerpc-unknown-freebsd)
- #109766 (Fix title for openharmony.md)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Canonicalize float var as float in new solver
Typo in new canonicalizer -- we should be canonicalizing float vars as `CanonicalTyVarKind::Float`, not `CanonicalTyVarKind::Int`.
Fixescompiler-errors/next-solver-hir-issues#9
Don't ICE on `DiscriminantKind` projection in new solver
As title says, since we now actually call `Ty::discriminant_kind` on placeholder types 😃
Also drive-by simplify `Pointee::Metadata` projection logic, and fix the UI test because the `<T as Pointee>::Metadata` tests weren't actually exercising the new projection logic, since we still eagerly normalize (which hits `project.rs` in the old solver) in HIR typeck.
r? `@lcnr` tho feel free to re-roll, this pr is very low-priority and not super specific to the new trait solver.
Fixescompiler-errors/next-solver-hir-issues#14
compiletest: Don't allow tests with overlapping prefix names
Some tests will delete their output directory before starting. The output directory is based on the test names. If one test is the prefix of another test, then when that test starts, it could try to delete the output directory of the other test with the longer path, or otherwise clash with it while the two tests are trying to create/delete/modify the same directory.
In practice, this manifested as a random error on macOS where two tests were trying to create/delete/create `rustdoc/primitive` and `rustdoc/primitive/no_std`, which resulted in an EINVAL (InvalidInput) error.
This renames some of the offending tests, adds `compiletest-ignore-dir` to prevent compiletest from processing some files, and adds a check to prevent this from happening in the future.
Fixes#109397
Partial stabilization of `once_cell`
This PR aims to stabilize a portion of the `once_cell` feature:
- `core::cell::OnceCell`
- `std::cell::OnceCell` (re-export of the above)
- `std::sync::OnceLock`
This will leave `LazyCell` and `LazyLock` unstabilized, which have been moved to the `lazy_cell` feature flag.
Tracking issue: https://github.com/rust-lang/rust/issues/74465 (does not fully close, but it may make sense to move to a new issue)
Future steps for separate PRs:
- ~~Add `#[inline]` to many methods~~ #105651
- Update cranelift usage of the `once_cell` crate
- Update rust-analyzer usage of the `once_cell` crate
- Update error messages discussing once_cell
## To be stabilized API summary
```rust
// core::cell (in core/cell/once.rs)
pub struct OnceCell<T> { .. }
impl<T> OnceCell<T> {
pub const fn new() -> OnceCell<T>;
pub fn get(&self) -> Option<&T>;
pub fn get_mut(&mut self) -> Option<&mut T>;
pub fn set(&self, value: T) -> Result<(), T>;
pub fn get_or_init<F>(&self, f: F) -> &T where F: FnOnce() -> T;
pub fn into_inner(self) -> Option<T>;
pub fn take(&mut self) -> Option<T>;
}
impl<T: Clone> Clone for OnceCell<T>;
impl<T: Debug> Debug for OnceCell<T>
impl<T> Default for OnceCell<T>;
impl<T> From<T> for OnceCell<T>;
impl<T: PartialEq> PartialEq for OnceCell<T>;
impl<T: Eq> Eq for OnceCell<T>;
```
```rust
// std::sync (in std/sync/once_lock.rs)
impl<T> OnceLock<T> {
pub const fn new() -> OnceLock<T>;
pub fn get(&self) -> Option<&T>;
pub fn get_mut(&mut self) -> Option<&mut T>;
pub fn set(&self, value: T) -> Result<(), T>;
pub fn get_or_init<F>(&self, f: F) -> &T where F: FnOnce() -> T;
pub fn into_inner(self) -> Option<T>;
pub fn take(&mut self) -> Option<T>;
}
impl<T: Clone> Clone for OnceLock<T>;
impl<T: Debug> Debug for OnceLock<T>;
impl<T> Default for OnceLock<T>;
impl<#[may_dangle] T> Drop for OnceLock<T>;
impl<T> From<T> for OnceLock<T>;
impl<T: PartialEq> PartialEq for OnceLock<T>
impl<T: Eq> Eq for OnceLock<T>;
impl<T: RefUnwindSafe + UnwindSafe> RefUnwindSafe for OnceLock<T>;
unsafe impl<T: Send> Send for OnceLock<T>;
unsafe impl<T: Sync + Send> Sync for OnceLock<T>;
impl<T: UnwindSafe> UnwindSafe for OnceLock<T>;
```
No longer planned as part of this PR, and moved to the `rust_cell_try` feature gate:
```rust
impl<T> OnceCell<T> {
pub fn get_or_try_init<F, E>(&self, f: F) -> Result<&T, E> where F: FnOnce() -> Result<T, E>;
}
impl<T> OnceLock<T> {
pub fn get_or_try_init<F, E>(&self, f: F) -> Result<&T, E> where F: FnOnce() -> Result<T, E>;
}
```
I am new to this process so would appreciate mentorship wherever needed.
Give return-position impl traits in trait a (synthetic) name to avoid name collisions with new lowering strategy
The only needed commit from this PR is the last one.
r? `@compiler-errors`
Needs #109455.
