@compiler-errors the tests look good, thanks for the work! I'll review the code shortly...

One question though, does the code support something like this:

let _: Option<&usize> = Some(1);

I'd expect rustc to suggest .as_ref() here, since it should be fine with auto ref coercions (in this exact case it could also suggest &1, but given an opaque Option<usize> we should probably try suggesting as_ref).

@petrochenkov I agree that rfcs/ does not make much sense in the long run and we should sort things better, however in the meantime it makes sense to use the same style for all RFCs, even if eventually we won't have rfc-specific directories at all.

@bors r=oli-obk

Shouldn't this have abi: "softfloat".into(), like aarch64-unknwon-none-softfloat?

Rrright. I'll check/fix the PR more closely and see if there are still valid use cases.

(switched to https://github.com/rust-lang/rust/labels/S-waiting-on-author due to CI issues and the comment above, feel free to use @rustbot ready when this is ready for review)

See the changelog/individual commits for complete set of changes, but TL;DR:

• Add ThreadId
• Use u32 and u8 instead of i32 where applicable
• Use Seconds and MessageId more

@the8472 my main argument in this case is readability, all other options seem significantly less readable than is_none_or when it can be applied directly (i.e. negating its result is not readable, but otherwise it is better).

@m-ou-se yeah, this is a bad example, I agree 😅

Ig a better example would be something like

pub fn is_ungated(&self, feature: Symbol) -> bool {
-    self.spans.borrow().get(&feature).map_or(true, |spans| spans.is_empty())
+    self.spans.borrow().get(&feature).is_none_or(|spans| spans.is_empty())
}

As using is_some_and would require double-negation:

    !self.spans.borrow().get(&feature).is_some_and(|spans| !spans.is_empty())

Similarly I think !(...).is_some_and() is not nice with long chains, where you have to remember negation from the start.

Result::is_err_or and Result::is_ok_or seem potentially interesting, I think I saw a few cases in the compiler where they can be used.

The naming is a problem though, is_err_or looks too much like is_error, similarly to Option::err_or which was not accepted a while back: https://github.com/rust-lang/rust/pull/73040#pullrequestreview-442096330.

For Result::is_ok_or_err_and I haven't yet seen any use-cases yet. It is pretty uncommon, although not unheard of, to have Result<T, T>, so usefulness of this method (especially with such a long name...) is questionable. Additionally it can be expressed via matches!(x, Ok(v) | Err(v) if ...) which is not too bad — it's a bit longer, but perfectly readable.

So, my opinions:

• Result::is_err_or and Result::is_ok_or may be interesting, but on the verge of being too much as they are far less common (in my experience) and have naming problems
• Result::is_ok_or_err_and doesn't seem appealing.

Good catch, thanks!

(as a side note span_to_snippet returns a result, so this would have to be a is_ok_and, but yeah)

@craterbot check

<!-- Thank you for filing a bug report! 🐛 Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. -->

I tried this code:

fn main() {
    let _ = *(0 as *const ());
}

playground

I expected to see this happen: A compiler error, dereferencing pointers is unsafe, and no unsafe block is provided. Instead, this happened:

   Compiling playground v0.0.1 (/playground)
warning: dereferencing a null pointer
 --> src/main.rs:2:13
  |
2 |     let _ = *(0 as *const ());
  |             ^^^^^^^^^^^^^^^^^ this code causes undefined behavior when executed
  |
  = note: `#[warn(deref_nullptr)]` on by default

warning: `playground` (bin "playground") generated 1 warning
    Finished dev [unoptimized + debuginfo] target(s) in 0.97s
     Running `target/debug/playground`

As far as I can tell, this code erroneously compiles for any Copy type, so long as the pattern doesn't bind anything to an identifier. Calls to unsafe functions cause a compiler error as normal.

Meta

Works on the playground when I tested with stable-1.66.1, beta-1.67.0-beta.10, and nightly-1.69.0 (2023-01-23)

This is in fact fixed by https://github.com/rust-lang/rust/pull/102256 on the latest stable:

error[E0133]: dereference of raw pointer is unsafe and requires unsafe function or block
 --> src/main.rs:2:13
  |
2 |     let _ = *(0 as *const ());
  |             ^^^^^^^^^^^^^^^^^ dereference of raw pointer
  |
  = note: raw pointers may be null, dangling or unaligned; they can violate aliasing rules and cause data races: all of these are undefined behavior

<!-- Before making this PR, please ensure the following:

• CHANGELOG.md is updated (if necessary).
• Documentation and tests are updated (if necessary). -->

Hi, I don't know if you are interested to solve CI warnings ... I describe what I did

Warnings principally arise from 2 unmantained actions actions-rs/toolchain actions-rs/cargo, although widely used, and from an outdated Swatinem/rust-cache@v1 version

For Swatinem/rust-cache, set-output and save-state warnings were fixed in the release v2.0.1. Instead the best replacement for actions-rs/toolchain seems to be dtolnay/rust-toolchain (see https://github.com/actions-rs/toolchain/issues/216), cargo command can be executed simply inside a run task

Two side-effects of these changes that I have experienced testing CI are:

1. Problem: cargo command in run task reads rust-toolchain.toml and selects always the nightly pinned version, instead in the previous behavior, If I didn't miss something, the installed toolchain is used by cargo Solution: when toolchain != nightly --> cargo +${{ toolchain_installed }} ...

2. Problem: dtolnay/rust-toolchain conditionally enable sparse-registry mode to speed-up crates.io sync. But for some reason with the pinned nightly version it doesn't work unless adding the flag -Z sparse-registry to cargo command, maybe an unhandled exception Solution: when toolchain == nightly --> CARGO_REGISTRIES_CRATES_IO_PROTOCOL: git

As a side note: [T; N] -> [T] is not Deref coercion, it's unsize coercion (which is, I believe, special cased to participate in method resolution (as opposed to, say [T; N] -> dyn Trait which is still unsize coercion but does not get involved in the method resolution)).

I also don't think that's particularly confusing, as it is common in Rust to have different types have methods with the same names.

Thanks!

I think this would make sense if we'd be using nightly, so that you don't have to change it 2 times when updating, but since it's just stable let's keep it simple and use cargo +stable.

this can probably just be +stable?

why is this needed?

I've updated the nightly, so the workaround can be removed.

Hm, I would expect this to suggest return. (still better than the status quo ig)