| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This makes `libcore/num/mod.rs` slightly smaller. It’s still 4911 lines and not easy to navigate. This doesn’t change any public API.
|
|
As discussed in https://github.com/rust-lang/rust/issues/10184
Currently, casting a floating point number to an integer with `as` is Undefined Behavior if the value is out of range. `-Z saturating-float-casts` fixes this soundness hole by making `as` “saturate” to the maximum or minimum value of the integer type (or zero for `NaN`), but has measurable negative performance impact in some benchmarks. There is some consensus in that thread for enabling saturation by default anyway, but provide an `unsafe fn` alternative for users who know through some other mean that their values are in range.
|
|
|
|
|
|
|
|
|
|
Fix docs for formatting delegations
If you use the example in the docs right now it breaks all the options Formatters have to offer.
i.e. https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=214392ecc6eff73b4789c32568395f72 this should've padded the output with 4 zeros but didn't.
with the new example it does work: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=3bdfb29f395230c5129c5f56dcfcb2a9
The only thing i'm not quite sure about is what's the right way to do it in a loop (altough non of the docs talk about it people are doing it in the wild and there were a couple of attempts to include in libcore)
i.e. https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=4c4dca3c90ba36779ecd014f3899ab9c
|
|
Tweak wording of `collect()` on bad target type
Fix #60440.
|
|
|
|
Make const-qualification look at more `const fn`s
As explained in a lot more detail in #67053 this makes const-qualification not ignore the unstable const fns in libcore.
r? @oli-obk cc @ecstatic-morse
(Still a bit unsure about the `cfg`s here, for bootstrapping, does that seem correct ?)
Fixes #67053.
|
|
capitalize Rust
Capitalize "Rust" in docs.
|
|
Fix documentation of pattern for str::matches()
Made it the same as rmatches()
|
|
So that we can bootstrap successfully
|
|
|
|
Using deref target instead of pointer itself avoids providing access to
`&Rc<T>` for malicious implementations, which would allow calling
`Rc::get_mut`.
This is a breaking change necessary due to unsoundness, however
the impact of it should be minimal.
This only fixes the issue with malicious `PartialEq` implementations,
other `Pin` soundness issues are still here.
See <https://internals.rust-lang.org/t/unsoundness-in-pin/11311/73>
for more details.
|
|
|
|
Organize intrinsics promotion checks
cc @vertexclique
supersedes #61835
r? @RalfJung
|
|
|
|
Made it the same as rmatches()
|
|
|
|
Remove `ord` lang item
At this point it seems to be unused, and just `partial_ord` is used instead. This removes the unused lang item.
|
|
Add `enclosing scope` parameter to `rustc_on_unimplemented`
Adds a new parameter to `#[rustc_on_unimplemented]`, `enclosing scope`, which highlights the function or closure scope with a message.
The wip part refers to adding this annotation to `Try` trait to improve ergonomics (which I don't know how to do since I change both std and librustc)
Closes #61709.
|
|
|
|
Layout::pad_to_align is infallible
As per [this comment](https://github.com/rust-lang/rust/issues/55724#issuecomment-441421651) (cc @glandium).
> Per https://github.com/rust-lang/rust/blob/eb981a1/src/libcore/alloc.rs#L63-L65, `layout.size()` is always <= `usize::MAX - (layout.align() - 1)`.
>
> Which means:
>
> * The maximum value `layout.size()` can have is already aligned for `layout.align()` (`layout.align()` being a power of two, `usize::MAX - (layout.align() - 1)` is a multiple of `layout.align()`)
> * Incidentally, any value smaller than that maximum value will align at most to that maximum value.
>
> IOW, `pad_to_align` can not return `Err(LayoutErr)`, except for the layout not respecting its invariants, but we shouldn't care about that.
This PR makes `pad_to_align` return `Layout` directly, representing the fact that it cannot fail.
|
|
|
|
libunwind_panic: adjust miri panic hack
We adjust the Miri hack in libpanic_unwind such that even with `cfg(miri)`, we build a version of libpanic_unwind that actually works.
This is needed to resolve https://github.com/integer32llc/rust-playground/issues/548.
r? @oli-obk @alexcrichton
|
|
|
|
|
|
Remove unneeded prelude imports in libcore tests
These three lines are from c82da7a54b9efb1a0ccbe11de66c71f547bf7db9 dating back to 2015.
They cause problems when applying rustfmt to the codebase, because reordering wildcard imports can trigger new unused import warnings.
As a minimized example, the following program compiles successfully:
```rust
#![deny(unused_imports)]
use std::fmt::Debug;
use std::marker::Send;
pub mod repro {
use std::prelude::v1::*;
use super::*;
pub type D = dyn Debug;
pub type S = dyn Send;
}
pub type S = dyn Send;
```
but putting it through rustfmt produces a program that fails to compile:
```rust
#![deny(unused_imports)]
use std::fmt::Debug;
use std::marker::Send;
pub mod repro {
use super::*;
use std::prelude::v1::*;
pub type D = dyn Debug;
pub type S = dyn Send;
}
pub type S = dyn Send;
```
The error is:
```console
error: unused import: `std::prelude::v1::*`
--> src/main.rs:8:9
|
8 | use std::prelude::v1::*;
| ^^^^^^^^^^^^^^^^^^^
```
|
|
Make python-generated source files compatible with rustfmt
This PR adjusts the generators for src/libcore/num/dec2flt/table.rs, src/libcore/unicode/printable.rs, and src/libcore/unicode/tables.rs to make it so running `rustfmt` on the generated files no longer needs to apply any changes.
This involves tweaking the python scripts where reasonable to better match rustfmt's style, and adding `#[rustfmt::skip]` to big constant tables that there's no point having rustfmt rewrap.
r? @Dylan-DPC
|
|
Atomic as_mut_ptr
I encountered the following pattern a few times: In Rust we use some atomic type like `AtomicI32`, and an FFI interface exposes this as `*mut i32` (or some similar `libc` type).
It was not obvious to me if a just transmuting a pointer to the atomic was acceptable, or if this should use a cast that goes through an `UnsafeCell`. See https://github.com/rust-lang/rust/issues/66136#issuecomment-557802477
Transmuting the pointer directly:
```rust
let atomic = AtomicI32::new(1);
let ptr = &atomic as *const AtomicI32 as *mut i32;
unsafe {
ffi(ptr);
}
```
A dance with `UnsafeCell`:
```rust
let atomic = AtomicI32::new(1);
unsafe {
let ptr = (&*(&atomic as *const AtomicI32 as *const UnsafeCell<i32>)).get();
ffi(ptr);
}
```
Maybe in the end both ways could be valid. But why not expose a direct method to get a pointer from the standard library?
An `as_mut_ptr` method on atomics can be safe, because only the use of the resulting pointer is where things can get unsafe. I documented its use for FFI, and "Doing non-atomic reads and writes on the resulting integer can be a data race."
The standard library could make use this method in a few places in the WASM module.
cc @RalfJung as you answered my original question.
|
|
|
|
|
|
|
|
These three lines are from c82da7a54b9efb1a0ccbe11de66c71f547bf7db9 in
2015.
They cause problems when applying rustfmt to the codebase, because
reordering wildcard imports can trigger new unused import warnings.
As a minimized example, the following program compiles successfully:
#![deny(unused_imports)]
use std::fmt::Debug;
use std::marker::Send;
pub mod repro {
use std::prelude::v1::*;
use super::*;
pub type D = dyn Debug;
pub type S = dyn Send;
}
pub type S = dyn Send;
but putting it through rustfmt produces a program that fails to compile:
#![deny(unused_imports)]
use std::fmt::Debug;
use std::marker::Send;
pub mod repro {
use super::*;
use std::prelude::v1::*;
pub type D = dyn Debug;
pub type S = dyn Send;
}
pub type S = dyn Send;
The error is:
error: unused import: `std::prelude::v1::*`
--> src/main.rs:8:9
|
8 | use std::prelude::v1::*;
| ^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
|
|
|
Casting the booleans to `i8`s and converting their difference
into `Ordering` generates better assembly than casting them to
`u8`s and comparing them.
|
|
Minor documentation fix
Fixed the documentation for any as is a trait rather than a type.
|
|
Clarify `{f32,f64}::EPSILON` docs
The doc for `EPSILON` says:
> This is the difference between `1.0` and the next **largest** representable number.
Which is a bit unclear.
[Wikipedia](https://en.wikipedia.org/wiki/Machine_epsilon) says
> Machine epsilon is defined as the difference between 1 and the next **larger** floating point number
So this PR update the docs to match the Wikipedia version.
The original PR also has this in a [comment](https://github.com/rust-lang/rust/pull/50919#discussion_r192600209).
|
|
Panic machinery comments and tweaks
This is mostly more comments, but I also renamed some things:
* `BoxMeUp::box_me_up` is not terribly descriptive, and since this is a "take"-style method (the argument is `&mut self` but the return type is fully owned, even though you can't tell from the type) I chose a name involving "take".
* `continue_panic_fmt` was very confusing as it was entirely unclear what was being continued -- for some time I thought "continue" might be the same as "resume" for a panic, but that's something entirely different. So I renamed this to `begin_panic_handler`, matching the `begin_panic*` theme of the other entry points.
r? @Dylan-DPC @SimonSapin
|
|
Rephrase docs in for ptr
These methods can be supplied with NULL just fine, this is the whole point of `Option<&T>` return type.
|
|
Fixed the documentation for any as is a trait rather than a type.
|
|
|
|
Implement Debug for MaybeUninit
Precedent: `UnsafeCell` implements `Debug` even though it can't actually display the value. I noticed this omission while writing the following:
```
#[derive(Debug)]
pub struct SliceInitializer<'a, T> {
marker: PhantomData<&'a mut T>,
uninit: &'a mut [MaybeUninit<T>],
written: usize,
}
```
...which currently unergonomically fails to compile.
`UnsafeCell` does require `T: Debug`. Because of things like the above I think it'd be better to leave that requirement off. In fact, I'd also suggest removing that requirement for `UnsafeCell` too, which again I noticed in some low-level real world code.
|
|
Fix spelling typos
Should be non-semantic.
Uses https://en.wikipedia.org/wiki/Wikipedia:Lists_of_common_misspellings/For_machines to find likely typos.
|
|
Fixes small typo in array docs r? @steveklabnik
Fixes a small typo in the array documentation.
Also, wasn't sure which [message](https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#pull-requests) to put this in, and will definitely update the commit message if it is supposed to be the PR description but for "safety" - r? @steveklabnik
|
|
Add core::{f32,f64}::consts::TAU.
### **`τ`**
|
|
|
