| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This reverts commit e53a2a72743810e05f58c61c9d8a4c89b712ad2e.
|
|
This commit is just covering the feature gate itself and the tests
that made direct use of `!` and thus need to opt back into the
feature.
A follow on commit brings back the other change that motivates the
revert: Namely, going back to the old rules for falling back to `()`.
|
|
Implement `shrink_to` method on collections
Fixes #49385
|
|
|
|
Tracking issue: https://github.com/rust-lang/rust/issues/33417
|
|
|
|
|
|
Stabilize termination_trait, split out termination_trait_test
For #48453.
First time contribution, so I'd really appreciate any feedback on how this PR can be better.
Not sure exactly what kind of documentation update is needed. If there is no PR to update the reference, I can try doing that this week as I have time.
|
|
Add 12 num::NonZero* types for primitive integers, deprecate core::nonzero
RFC: https://github.com/rust-lang/rfcs/pull/2307
Tracking issue: ~~https://github.com/rust-lang/rust/issues/27730~~ https://github.com/rust-lang/rust/issues/49137
Fixes https://github.com/rust-lang/rust/issues/27730
|
|
This stabilizes `main` with non-() return types; see #48453.
|
|
RFC: https://github.com/rust-lang/rfcs/pull/2307
|
|
It stays in libcore rather than being private in HashMap’s module
because it shares code with the deprecated *stable* `SipHasher` type.
|
|
Make `assert` a built-in procedural macro
Makes `assert` macro a built-in one without touching its functionality. This is a prerequisite for RFC 2011 (#44838).
|
|
Stabilize inclusive range (`..=`)
Stabilize the followings:
* `inclusive_range` — The `std::ops::RangeInclusive` and `std::ops::RangeInclusiveTo` types, except its fields (tracked by #49022 separately).
* `inclusive_range_syntax` — The `a..=b` and `..=b` expression syntax
* `dotdoteq_in_patterns` — Using `a..=b` in a pattern
cc #28237
r? @rust-lang/lang
|
|
Stabilize std::ops::RangeInclusive and std::ops::RangeInclusiveTo.
|
|
Fallible allocation
Implementing RFC#2116 [Fallible Allocation](https://github.com/rust-lang/rust/issues/48043) .
Work in progress. Initially adding @Gankro's try_reserve for Vec.
|
|
|
|
Replace feature(never_type) with feature(exhaustive_patterns).
feature(exhaustive_patterns) only covers the pattern-exhaustives checks
that used to be covered by feature(never_type)
|
|
|
|
Stabilize FusedIterator
FusedIterator is a marker trait that promises that the implementing
iterator continues to return `None` from `.next()` once it has returned
`None` once (and/or `.next_back()`, if implemented).
The effects of FusedIterator are already widely available through
`.fuse()`, but with stable `FusedIterator`, stable Rust users can
implement this trait for their iterators when appropriate.
Closes #35602
|
|
FusedIterator is a marker trait that promises that the implementing
iterator continues to return `None` from `.next()` once it has returned
`None` once (and/or `.next_back()`, if implemented).
The effects of FusedIterator are already widely available through
`.fuse()`, but with stable `FusedIterator`, stable Rust users can
implement this trait for their iterators when appropriate.
|
|
This commit imports the `stdsimd` crate into the standard library,
creating an `arch` and `simd` module inside of both libcore and libstd.
Both of these modules are **unstable** and will continue to be so until
RFC 2335 is stabilized.
As a brief recap, the modules are organized as so:
* `arch` contains all current architectures with intrinsics, for example
`std::arch::x86`, `std::arch::x86_64`, `std::arch::arm`, etc. These
modules contain all of the intrinsics defined for the platform, like
`_mm_set1_epi8`.
* In the standard library, the `arch` module also exports a
`is_target_feature_detected` macro which performs runtime detection to
determine whether a target feature is available at runtime.
* The `simd` module contains experimental versions of strongly-typed
lane-aware SIMD primitives, to be fully fleshed out in a future RFC.
The main purpose of this commit is to start pulling in all these
intrinsics and such into the standard library on nightly and allow
testing and such. This'll help allow users to easily kick the tires and
see if intrinsics work as well as allow us to test out all the
infrastructure for moving the intrinsics into the standard library.
|
|
Termination trait in tests
Support the `Termination` trait in unit tests (cc https://github.com/rust-lang/rust/issues/43301)
Also, a drive-by fix for #47075.
This is joint work with @bkchr.
|
|
|
|
Also make `std::termination` module public and rename feature.
The lib feature needs a different name from the language feature.
|
|
|
|
RFC 2070 part 1: PanicInfo and Location API changes
This implements part of https://rust-lang.github.io/rfcs/2070-panic-implementation.html
Tracking issue: https://github.com/rust-lang/rust/issues/44489
* Move `std::panic::PanicInfo` and `std::panic::Location` to a new `core::panic` module. The two types and the `std` module were already `#[stable]` and stay that way, the new `core` module is `#[unstable]`.
* Add a new `PanicInfo::message(&self) -> Option<&fmt::Arguments>` method, which is `#[unstable]`.
* Implement `Display` for `PanicInfo` and `Location`
|
|
|
|
Per https://rust-lang.github.io/rfcs/2070-panic-implementation.html
|
|
|
|
|
|
|
|
`Shared` is now a deprecated `type` alias.
CC https://github.com/rust-lang/rust/issues/27730#issuecomment-352800629
|
|
|
|
r=estebank
type error method suggestions use whitelisted identity-like conversions
Previously, on a type mismatch (and if this wasn't preëmpted by a
higher-priority suggestion), we would look for argumentless methods
returning the expected type, and list them in a `help` note. This had two
major shortcomings: firstly, a lot of the suggestions didn't really make
sense (if you used a &str where a String was expected,
`.to_ascii_uppercase()` is probably not the solution you were hoping
for). Secondly, we weren't generating suggestions from the most useful
traits! We address the first problem with an internal
`#[rustc_conversion_suggestion]` attribute meant to mark methods that keep
the "same value" in the relevant sense, just converting the type. We
address the second problem by making `FnCtxt.probe_for_return_type` pass
the `ProbeScope::AllTraits` to `probe_op`: this would seem to be safe
because grep reveals no other callers of `probe_for_return_type`.
Also, structured suggestions are pretty and good for RLS and friends.
Unfortunately, the trait probing is still not all one would hope for: at a
minimum, we don't know how to rule out `into()` in cases where it wouldn't
actually work, and we don't know how to rule in `.to_owned()` where it
would. Issues #46459 and #46460 have been filed and are ref'd in a FIXME.
This is hoped to resolve #42929, #44672, and #45777.
|
|
As a side effect, this fixes the warning about repr(C, simd) that has been reported during x86_64 windows builds since #47111 (see also: #47103)
|
|
Previously, on a type mismatch (and if this wasn't preëmpted by a
higher-priority suggestion), we would look for argumentless methods
returning the expected type, and list them in a `help` note.
This had two major shortcomings. Firstly, a lot of the suggestions didn't
really make sense (if you used a &str where a String was expected,
`.to_ascii_uppercase()` is probably not the solution you were hoping
for). Secondly, we weren't generating suggestions from the most useful
traits!
We address the first problem with an internal
`#[rustc_conversion_suggestion]` attribute meant to mark methods that keep
the "same value" in the relevant sense, just converting the type. We
address the second problem by making `FnCtxt.probe_for_return_type` pass
the `ProbeScope::AllTraits` to `probe_op`: this would seem to be safe
because grep reveals no other callers of `probe_for_return_type`.
Also, structured suggestions are preferred (because they're pretty, but
also for RLS and friends).
Also also, we make the E0055 autoderef recursion limit error use the
one-time-diagnostics set, because we can potentially hit the limit a lot
during probing. (Without this,
test/ui/did_you_mean/recursion_limit_deref.rs would report "aborting due to
51 errors").
Unfortunately, the trait probing is still not all one would hope for: at a
minimum, we don't know how to rule out `into()` in cases where it wouldn't
actually work, and we don't know how to rule in `.to_owned()` where it
would. Issues #46459 and #46460 have been filed and are ref'd in a FIXME.
This is hoped to resolve #42929, #44672, and #45777.
|
|
Use memchr to speed up [u8]::contains 3x
None
|
|
|
|
This is the first part of the RFC 1937 that supports new
`Termination` trait in the rust `main` function.
|
|
|
|
Add read, read_string, and write functions to std::fs
New APIs in `std::fs`:
```rust
pub fn read<P: AsRef<Path>>(path: P) -> io::Result<Vec<u8>> { … }
pub fn read_string<P: AsRef<Path>>(path: P) -> io::Result<String> { … }
pub fn write<P: AsRef<Path>, C: AsRef<[u8]>>(path: P, contents: C) -> io::Result<()> { ... }
```
(`read_string` is based on `read_to_string` and so returns an error on non-UTF-8 content.)
Before:
```rust
use std::fs::File;
use std::io::Read;
let mut bytes = Vec::new();
File::open(filename)?.read_to_end(&mut bytes)?;
do_something_with(bytes)
```
After:
```rust
use std::fs;
do_something_with(fs::read(filename)?)
```
|
|
Fixes #46038
|
|
Turns out ThinLTO was internalizing this symbol and eliminating it. Worse yet if
you compiled with LTO turns out no TLS destructors would run on Windows! The
`#[used]` annotation should be a more bulletproof implementation (in the face of
LTO) of preserving this symbol all the way through in LLVM and ensuring it makes
it all the way to the linker which will take care of it.
|
|
|
|
This commit removes the `rand` crate from the standard library facade as
well as the `__rand` module in the standard library. Neither of these
were used in any meaningful way in the standard library itself. The only
need for randomness in libstd is to initialize the thread-local keys of
a `HashMap`, and that unconditionally used `OsRng` defined in the
standard library anyway.
The cruft of the `rand` crate and the extra `rand` support in the
standard library makes libstd slightly more difficult to port to new
platforms, namely WebAssembly which doesn't have any randomness at all
(without interfacing with JS). The purpose of this commit is to clarify
and streamline randomness in libstd, focusing on how it's only required
in one location, hashmap seeds.
Note that the `rand` crate out of tree has almost always been a drop-in
replacement for the `rand` crate in-tree, so any usage (accidental or
purposeful) of the crate in-tree should switch to the `rand` crate on
crates.io. This then also has the further benefit of avoiding
duplication (mostly) between the two crates!
|
|
|
|
Before:
```rust
use std::fs::File;
use std::io::Read;
let mut bytes = Vec::new();
File::open(filename)?.read_to_end(&mut bytes)?;
do_something_with(bytes)
```
After:
```rust
use std::fs::File;
do_something_with(File::read_contents(filename)?)
```
|
|
We don't want to stabilize them now already. The goal of this set of
commits is just to add inherent methods to the four types. Stabilizing
all of those methods can be done later.
|
|
Implement TryFrom<&[T]> for &[T; N]
There are many cases where a buffer with a static compile-time size is preferred over a slice with a dynamic size. This allows for performing a checked conversion from `&[T]` to `&[T; N]`. This may also lead to compile-time optimizations involving `[T; N]` such as loop unrolling.
This is my first PR to Rust, so I'm not sure if discussion of this change should happen here or does it need its own RFC? I figured these changes would be a subset of #33417.
|
