Adds new intrinsic declaration
This pr is for #132735 removes removes `extern "intrinsic"`
I think its the last block of this file and was kind of asking for advice how to handle other files as mentioned in the issue .
Define acronym for thread local storage
There are multiple references in this module's documentation to the acronym "TLS" (meaning "thread local storage"), without defining it. This is confusing for the reader.
I propose that this acronym be defined during the first use of the term.
There are multiple references in this module's documentation to the acronym "TLS", without defining it. This is confusing for the reader.
I propose that this acronym be defined during the first use of the term.
Implementation of `fmt::FormattingOptions`
Tracking issue: #118117
Public API:
```rust
#[derive(Copy, Clone, Debug, PartialEq, Eq)]
pub struct FormattingOptions { … }
#[derive(Copy, Clone, Debug, PartialEq, Eq)]
pub enum Sign {
Plus,
Minus
}
#[derive(Copy, Clone, Debug, PartialEq, Eq)]
pub enum DebugAsHex {
Lower,
Upper
}
impl FormattingOptions {
pub fn new() -> Self;
pub fn sign(&mut self, sign: Option<Sign>) -> &mut Self;
pub fn sign_aware_zero_pad(&mut self, sign_aware_zero_pad: bool) -> &mut Self;
pub fn alternate(&mut self, alternate: bool) -> &mut Self;
pub fn fill(&mut self, fill: char) -> &mut Self;
pub fn align(&mut self, alignment: Option<Alignment>) -> &mut Self;
pub fn width(&mut self, width: Option<usize>) -> &mut Self;
pub fn precision(&mut self, precision: Option<usize>) -> &mut Self;
pub fn debug_as_hex(&mut self, debug_as_hex: Option<DebugAsHex>) -> &mut Self;
pub fn get_sign(&self) -> Option<Sign>;
pub fn get_sign_aware_zero_pad(&self) -> bool;
pub fn get_alternate(&self) -> bool;
pub fn get_fill(&self) -> char;
pub fn get_align(&self) -> Option<Alignment>;
pub fn get_width(&self) -> Option<usize>;
pub fn get_precision(&self) -> Option<usize>;
pub fn get_debug_as_hex(&self) -> Option<DebugAsHex>;
pub fn create_formatter<'a>(self, write: &'a mut (dyn Write + 'a)) -> Formatter<'a>;
}
impl<'a> Formatter<'a> {
pub fn new(write: &'a mut (dyn Write + 'a), options: FormattingOptions) -> Self;
pub fn with_options<'b>(&'b mut self, options: FormattingOptions) -> Formatter<'b>;
pub fn sign(&self) -> Option<Sign>;
pub fn options(&self) -> FormattingOptions;
}
```
Relevant changes from the public API in the tracking issue (I'm leaving out some stuff I consider obvious mistakes, like missing `#[derive(..)]`s and `pub` specifiers):
- `enum DebugAsHex`/`FormattingOptions::debug_as_hex`/`FormattingOptions::get_debug_as_hex`: To support `{:x?}` as well as `{:X?}`. I had completely missed these options in the ACP. I'm open for any and all bikeshedding, not married to the name.
- `fill`/`get_fill` now takes/returns `char` instead of `Option<char>`. This simply mirrors what `Formatter::fill` returns (with default being `' '`).
- Changed `zero_pad`/`get_zero_pad` to `sign_aware_zero_pad`/`get_sign_aware_zero_pad`. This also mirrors `Formatter::sign_aware_zero_pad`. While I'm not a fan of this quite verbose name, I do believe that having the interface of `Formatter` and `FormattingOptions` be compatible is more important.
- For the same reason, renamed `alignment`/`get_alignment` to `aling`/`get_align`.
- Deviating from my initial idea, `Formatter::with_options` returns a `Formatter` which has the lifetime of the `self` reference as its generic lifetime parameter (in the original API spec, the generic lifetime of the returned `Formatter` was the generic lifetime used by `self` instead). Otherwise, one could construct two `Formatter`s that both mutably borrow the same underlying buffer, which would be unsound. This solution still has performance benefits over simply using `Formatter::new`, so I believe it is worthwhile to keep this method.
Stabilize `std::io::ErrorKind::CrossesDevices`
FCP in #130191
cc #86442
See #130191 for more info and a recap of what has happened up until now.
TLDR: This had been FCP'd in December 2022 with some other `ErrorKind`s, but the stabilization got postponed due to some concerns voiced about several of the variants. However, the only concern ever voiced for this variant in particular was a wish to rename this to `NotSameDevice` analogous to Windows's `ERROR_NOT_SAME_DEVICE` (as opposed to Unix's `EXDEV`). This suggestion did not receive any support. So let's try to FCP this as is.
r? libs-api
Stabilize noop_waker
Tracking Issue: #98286
This is a handy feature that's been used widely in tests and example async code and it'd be nice to make it available to users.
cc `@rust-lang/wg-async`
Replace black with ruff in `tidy`
`ruff` can both lint and format Python code (in fact, it should be a mostly drop-in replacement for `black` in terms of formatting), so it's not needed to use `black` anymore. This PR removes `black` and replaces it with `ruff`, to get rid of one Python dependency, and also to make Python formatting faster (although that's a small thing).
If we decide to merge this, we'll need to "reformat the world" - `ruff` is not perfectly compatible with `black`, and it also looks like `black` was actually ignoring some files before. I tried it locally (`./x test tidy --extra-checks=py:fmt --bless`) and it also reformatted some code in subtrees (e.g. `clippy` or `rustc_codegen_gcc`) - I'm not sure how to handle that.
Formatter::with_options takes self as a mutable reference (`&'a mut
Formatter<'b>`). `'a` and `'b` need to be different lifetimes. Just taking `&'a
mut Formatter<'a>` and trusting in Rust being able to implicitely convert from
`&'a mut Formatter<'b>` if necessary (after all, `'a` must be smaller than `'b`
anyway) fails because `'b` is behind a *mutable* reference. For background on
on this behavior, see https://doc.rust-lang.org/nomicon/subtyping.html#variance.
The idea behind this is to make implementing `fmt::FormattingOptions` (as well
as any future changes to `std::Formatter`) easier.
In theory, this might have a negative performance impact because of the
additional function calls. However, I strongly believe that those will be
inlined anyway, thereby producing assembly code that has comparable performance.
Fix missing newlines that rustfmt removed.
fix trailing whitespace
Fix duplicate word.
Reformat panic reasons into a list
remove trailing whitespace 2 electric boogaloo
Change verbe tense.
Integrate suggestions
Improve comments for the default backtrace printer
The existing comments were misleading, confusing, and outdated.
Take this comment for example:
```
// Any frames between `__rust_begin_short_backtrace` and `__rust_end_short_backtrace`
// are omitted from the backtrace in short mode, `__rust_end_short_backtrace` will be
// called before the panic hook, so we won't ignore any frames if there is no
// invoke of `__rust_begin_short_backtrace`.
```
this is just wrong. here is an example (full) backtrace:
<details>
```
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.01s
Running `/home/jyn/.local/lib/cargo/target/debug/example`
called `Option::unwrap()` on a `None` value
stack backtrace:
0: 0x56499698c595 - std::backtrace_rs::backtrace::libunwind::trace::h5ef2cc16e9a7415a
1: 0x56499698c595 - std::backtrace_rs::backtrace::trace_unsynchronized::h9b5e016e9075f714
2: 0x56499698c595 - std::sys_common::backtrace::_print_fmt::h2f62c7f9ff224e93
3: 0x56499698c595 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hbe51682735731910
4: 0x5649969aa26b - core::fmt::rt::Argument::fmt::h1994ab2b310d665e
5: 0x5649969aa26b - core::fmt::write::hade58a36d63468d7
6: 0x56499698a43f - std::io::Write::write_fmt::h16145587d801a9ab
7: 0x56499698c36e - std::sys_common::backtrace::_print::ha8082e56201dadb4
8: 0x56499698c36e - std::sys_common::backtrace::print::he30f96b4e7f6cbfd
9: 0x56499698d709 - std::panicking::default_hook::{{closure}}::hf0801f6b18a968d3
10: 0x56499698d4ac - std::panicking::default_hook::hd2defec7eda5aeb0
11: 0x56499698dc31 - std::panicking::rust_panic_with_hook::hde93283600065c53
12: 0x56499698daf3 - std::panicking::begin_panic_handler::{{closure}}::h5e151adbdb7ec0c1
13: 0x56499698ca59 - std::sys_common::backtrace::__rust_end_short_backtrace::he36a1407e0f77700
14: 0x56499698d7d4 - rust_begin_unwind
15: 0x5649969a9503 - core::panicking::panic_fmt::h2380d41365f95412
16: 0x5649969a958c - core::panicking::panic::h38cf8db80e8c6e67
17: 0x5649969a93e9 - core::option::unwrap_failed::he72696e53ff29a05
18: 0x5649969722b6 - core::option::Option<T>::unwrap::hb574dc0dc1703062
19: 0x5649969722b6 - example::main::h7a867aafacd93d75
20: 0x5649969721db - core::ops::function::FnOnce::call_once::h734f99a5e57291b7
21: 0x56499697226e - std::sys_common::backtrace::__rust_begin_short_backtrace::h02f5d58c351c4756
22: 0x564996972241 - std::rt::lang_start::{{closure}}::h8b134fe2c31a4355
23: 0x564996988662 - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h88d7bb571ee2aaf4
24: 0x564996988662 - std::panicking::try::do_call::hfb78dfb6599c871d
25: 0x564996988662 - std::panicking::try::habd041c8c4c8e50c
27: 0x564996988662 - std::rt::lang_start_internal::{{closure}}::h227591a6f9c0879e
28: 0x564996988662 - std::panicking::try::do_call::h3c5878333c38916a
29: 0x564996988662 - std::panicking::try::h5af7b3a127cdae70
31: 0x564996988662 - std::rt::lang_start_internal::hbc85e809eeace0dd
32: 0x56499697221a - std::rt::lang_start::ha1eb16922c9cb224
33: 0x5649969722ee - main
34: 0x7f031962a1ca - __libc_start_call_main
35: 0x7f031962a28b - __libc_start_main_impl
36: 0x5649969720a5 - _start
37: 0x0 - <unknown>
```
</details>
note particularly frames 13-21, from start_backtrace to end_backtrace. with PrintFmt::Short, these are the *only* frames that are printed; i.e. we are doing the exact opposite of the comment.
r? ``@saethlin``
clarify simd_relaxed_fma non-determinism
This is the safer spec in the sense that it is more likely to be satisfied by the backend -- and if people are okay with a non-deterministic result, I assume they don't care whether it's the same choice across all lanes or not?
Cc ``@calebzulawski`` ``@workingjubilee``
Rename `core_pattern_type` and `core_pattern_types` lib feature gates to `pattern_type_macro`
That's what the gates are actually gating, and the single char difference in naming was not helpful either
fixes#128987
Add lint against function pointer comparisons
This is kind of a follow-up to https://github.com/rust-lang/rust/pull/117758 where we added a lint against wide pointer comparisons for being ambiguous and unreliable; well function pointer comparisons are also unreliable. We should IMO follow a similar logic and warn people about it.
-----
## `unpredictable_function_pointer_comparisons`
*warn-by-default*
The `unpredictable_function_pointer_comparisons` lint checks comparison of function pointer as the operands.
### Example
```rust
fn foo() {}
let a = foo as fn();
let _ = a == foo;
```
### Explanation
Function pointers comparisons do not produce meaningful result since they are never guaranteed to be unique and could vary between different code generation units. Furthermore different function could have the same address after being merged together.
----
This PR also uplift the very similar `clippy::fn_address_comparisons` lint, which only linted on if one of the operand was an `ty::FnDef` while this PR lints proposes to lint on all `ty::FnPtr` and `ty::FnDef`.
```@rustbot``` labels +I-lang-nominated
~~Edit: Blocked on https://github.com/rust-lang/libs-team/issues/323 being accepted and it's follow-up pr~~
The existing comments were misleading, confusing, and wrong.
Take this comment for example:
```
// Any frames between `__rust_begin_short_backtrace` and `__rust_end_short_backtrace`
// are omitted from the backtrace in short mode, `__rust_end_short_backtrace` will be
// called before the panic hook, so we won't ignore any frames if there is no
// invoke of `__rust_begin_short_backtrace`.
```
this is just wrong. here is an example (full) backtrace:
```
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.01s
Running `/home/jyn/.local/lib/cargo/target/debug/example`
called `Option::unwrap()` on a `None` value
stack backtrace:
0: 0x56499698c595 - std::backtrace_rs::backtrace::libunwind::trace::h5ef2cc16e9a7415a
1: 0x56499698c595 - std::backtrace_rs::backtrace::trace_unsynchronized::h9b5e016e9075f714
2: 0x56499698c595 - std::sys_common::backtrace::_print_fmt::h2f62c7f9ff224e93
3: 0x56499698c595 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hbe51682735731910
4: 0x5649969aa26b - core::fmt::rt::Argument::fmt::h1994ab2b310d665e
5: 0x5649969aa26b - core::fmt::write::hade58a36d63468d7
6: 0x56499698a43f - std::io::Write::write_fmt::h16145587d801a9ab
7: 0x56499698c36e - std::sys_common::backtrace::_print::ha8082e56201dadb4
8: 0x56499698c36e - std::sys_common::backtrace::print::he30f96b4e7f6cbfd
9: 0x56499698d709 - std::panicking::default_hook::{{closure}}::hf0801f6b18a968d3
10: 0x56499698d4ac - std::panicking::default_hook::hd2defec7eda5aeb0
11: 0x56499698dc31 - std::panicking::rust_panic_with_hook::hde93283600065c53
12: 0x56499698daf3 - std::panicking::begin_panic_handler::{{closure}}::h5e151adbdb7ec0c1
13: 0x56499698ca59 - std::sys_common::backtrace::__rust_end_short_backtrace::he36a1407e0f77700
14: 0x56499698d7d4 - rust_begin_unwind
15: 0x5649969a9503 - core::panicking::panic_fmt::h2380d41365f95412
16: 0x5649969a958c - core::panicking::panic::h38cf8db80e8c6e67
17: 0x5649969a93e9 - core::option::unwrap_failed::he72696e53ff29a05
18: 0x5649969722b6 - core::option::Option<T>::unwrap::hb574dc0dc1703062
19: 0x5649969722b6 - example::main::h7a867aafacd93d75
20: 0x5649969721db - core::ops::function::FnOnce::call_once::h734f99a5e57291b7
21: 0x56499697226e - std::sys_common::backtrace::__rust_begin_short_backtrace::h02f5d58c351c4756
22: 0x564996972241 - std::rt::lang_start::{{closure}}::h8b134fe2c31a4355
23: 0x564996988662 - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h88d7bb571ee2aaf4
24: 0x564996988662 - std::panicking::try::do_call::hfb78dfb6599c871d
25: 0x564996988662 - std::panicking::try::habd041c8c4c8e50c
27: 0x564996988662 - std::rt::lang_start_internal::{{closure}}::h227591a6f9c0879e
28: 0x564996988662 - std::panicking::try::do_call::h3c5878333c38916a
29: 0x564996988662 - std::panicking::try::h5af7b3a127cdae70
31: 0x564996988662 - std::rt::lang_start_internal::hbc85e809eeace0dd
32: 0x56499697221a - std::rt::lang_start::ha1eb16922c9cb224
33: 0x5649969722ee - main
34: 0x7f031962a1ca - __libc_start_call_main
35: 0x7f031962a28b - __libc_start_main_impl
36: 0x5649969720a5 - _start
37: 0x0 - <unknown>
```
note particularly frames 13-21, from start_backtrace to end_backtrace. with PrintFmt::Short, these are the *only* frames that are printed; i.e. we are doing the exact opposite of the comment.
Update `NonZero` and `NonNull` to not field-project (per MCP#807)
https://github.com/rust-lang/compiler-team/issues/807#issuecomment-2506098540 was accepted, so this is the first PR towards moving the library to not using field projections into `[rustc_layout_scalar_valid_range_*]` types.
`NonZero` was already using `transmute` nearly everywhere, so there are very few changes to it.
`NonNull` needed more changes, but they're mostly simple, changing `.pointer` to `.as_ptr()`.
r? libs
cc #133324, which will tidy up some of the MIR from this a bit more, but isn't a blocker.
