| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Switch to bootstrapping from 1.29 beta
r? @alexcrichton
|
|
slices: fix ZST slice iterators making up pointers; debug_assert alignment in from_raw_parts
This fixes the problem that we are fabricating pointers out of thin air. I also managed to share more code between the mutable and shared iterators, while reducing the amount of macros.
I am not sure how useful it really is to add a `debug_assert!` in libcore. Everybody gets a release version of that anyway, right? Is there at least a CI job that runs the test suite with a debug version?
Fixes #42789
|
|
|
|
|
|
Also use ident, not expr, to avoid accidental side-effects
|
|
This also changes the IR for nth(), but the new IR actually looks nicer that the old
(and it is one instruction shorter).
|
|
|
|
|
|
|
|
|
|
|
|
Rollup of 15 pull requests
Successful merges:
- #52793 (Add test for NLL: unexpected "free region `` does not outlive" error )
- #52799 (Use BitVector for global sets of AttrId)
- #52809 (Add test for unexpected region for local data ReStatic)
- #52834 ([NLL] Allow conflicting borrows of promoted length zero arrays)
- #52835 (Fix Alias intra doc ICE)
- #52854 (fix memrchr in miri)
- #52899 (tests/ui: Add missing mips{64} ignores)
- #52908 (Use SetLenOnDrop in Vec::truncate())
- #52915 (Don't count MIR locals as borrowed after StorageDead when finding locals live across a yield terminator)
- #52926 (rustc: Trim down the `rust_2018_idioms` lint group)
- #52930 (rustc_resolve: record single-segment extern crate import resolutions.)
- #52939 (Make io::Read::read_to_end consider io::Take::limit)
- #52942 (Another SmallVec.extend optimization)
- #52947 (1.27 actually added the `armv5te-unknown-linux-musleabi` target)
- #52954 (async can begin expressions)
Failed merges:
r? @ghost
|
|
fix memrchr in miri
The previous PR https://github.com/rust-lang/rust/pull/52744 was not enough because it assumed that the split between the `mid` and `end` parts returned by `align_to` was aligned. But really the only guarantee we have is that the `mid` part is aligned, so make use of that.
|
|
|
|
Treat gc=No characters as numeric
[`char::is_numeric`](https://doc.rust-lang.org/std/primitive.char.html#method.is_numeric) and [`char::is_alphanumeric`](https://doc.rust-lang.org/std/primitive.char.html#method.is_alphanumeric) are documented to be defined “in terms of the Unicode General Categories 'Nd', 'Nl', 'No'”, but unicode.py does not group 'No' with the other 'N' categories. These functions therefore currently return `false` for characters like ⟨¾⟩ and ⟨①⟩.
|
|
Fix a typo in unsize.rs
RfC -> RFC
|
|
Implement Unpin for FutureObj and LocalFutureObj
cc @MajorBreakfast
r? @aturon
|
|
Fix From<LocalWaker>
This is a follow-up to https://github.com/rust-lang/rust/pull/52640
Fixes `From<LocalWaker>` which is affected by the same accidental drop bug (unless I'm totally mistaken)
r? @cramertj
|
|
Remove unstable and deprecated APIs
|
|
RfC -> RFC
|
|
Implement inner deref for Option and Result
tracking issue: #50264
|
|
|
|
|
|
|
|
This reverts commit c8f9b84b393915a48253e3edc862c15a9b7152a7.
|
|
|
|
Prefer to_string() to format!()
Simple benchmarks suggest in some cases it can be faster by even 37%:
```
test converting_f64_long ... bench: 339 ns/iter (+/- 199)
test converting_f64_short ... bench: 136 ns/iter (+/- 34)
test converting_i32_long ... bench: 87 ns/iter (+/- 16)
test converting_i32_short ... bench: 87 ns/iter (+/- 49)
test converting_str ... bench: 54 ns/iter (+/- 15)
test formatting_f64_long ... bench: 349 ns/iter (+/- 176)
test formatting_f64_short ... bench: 145 ns/iter (+/- 14)
test formatting_i32_long ... bench: 98 ns/iter (+/- 14)
test formatting_i32_short ... bench: 93 ns/iter (+/- 15)
test formatting_str ... bench: 86 ns/iter (+/- 23)
```
|
|
|
|
Misc cleanups
|
|
make memrchr use align_offset
I hope I did not screw that up...
Cc @oli-obk who authored the original https://github.com/rust-lang/rust/pull/44537
Fixes #50567 (thanks @bjorn3)
|
|
Change ManuallyDrop<T> to a lang item.
This PR implements the approach @RalfJung proposes in https://internals.rust-lang.org/t/pre-rfc-unions-drop-types-and-manuallydrop/8025 (lang item `struct` instead of `union`).
A followup PR can easily solve #47034 as well, by just adding a few `?Sized` to `libcore/mem.rs`.
r? @nikomatsakis
|
|
Fix doc comment for 'ptr::copy_to' method
Fix error in doc comment for `ptr::copy_to` method.
|
|
Rollup of bare_trait_objects PRs
All deny attributes were moved into bootstrap so they can be disabled with a line of config.
Warnings for external tools are allowed and it's up to the tool's maintainer to keep it warnings free.
r? @Mark-Simulacrum
cc @ljedrz @kennytm
|
|
|
|
|
|
|
|
|
|
|
|
|
|
std::ops::Try impl for std::task::Poll
I originally left out the `Try` impl for `Poll` because I was curious if we needed it, and @MajorBreakfast and I had discussed the potential for it to introduce confusion about exactly what control-flow was happening at different points. However, after porting a pretty significant chunk of Fuchsia over to futures 0.3, I discovered that I was *constantly* having to do repetitive matching on `Poll<Result<...>>` or `Poll<Option<Result<...>>>` in order to propagate errors correctly. `try_poll` (propagate `Poll::Ready(Err(..))`s) helped in some places, but it was far more common to need some form of conversion between `Result`, `Poll<Result<...>>`, and `Poll<Option<Result<...>>>`. The `Try` trait conveniently provides all of these conversions in addition to a more concise syntax (`?`), so I'd like to experiment with using these instead.
cc @seanmonstar
r? @aturon
Note: this change means that far more futures 0.1 code can work without significant changes since it papers over the fact that `Result` is no longer at the top-level when using `Stream` and `Future` (since it's now `Poll<Result<...>>` or `Poll<Option<Result<...>>>` instead of `Result<Poll<..>>` and `Result<Poll<Option<...>>>`).
|
|
Clarify what a task is
Currently we call two distinct concepts "task":
1. The top-level future that is polled until completion
2. The lightweight "thread" that is responsible for polling the top-level future. What additional data beside the future is stored in this type varies between different `Executor` implementations.
I'd prefer to return to the old formulation by @alexcrichton:
```rust
/// A handle to a "task", which represents a single lightweight "thread" of
/// execution driving a future to completion.
pub struct Task {
```
Source: [`task_impl/mod.rs` in futures-rs 0.1](https://github.com/rust-lang-nursery/futures-rs/blob/1328fc9e8af5737183df477c7501e6ea24ff2053/src/task_impl/mod.rs#L49-L50)
I think that this change will make it much easier to explain everything.
r? @aturon
@cramertj
|
|
|
|
|
|
|
|
|
|
|
|
|
|
clarify pointer offset function safety concerns
|
|
Prefer `Option::map`/etc over `match` wherever it improves clarity
This isn't intended to change behavior anywhere. A lot of times statements like `match x { None => None, Some(y) => [...] }` can be rewritten using `Option::map` or `Option::and_then` in a way that preserves or improves clarity, so that's what I've done here.
I think it's particularly valuable to keep things in `libcore` and `libstd` pretty/idiomatic since it's not uncommon to follow the `[src]` links when browsing the rust-lang.org docs for std/core. If there's any concern about pushing style-based changes though, I'll happily back out the non-std/core commits here.
|
|
impl PartialEq+Eq for BuildHasherDefault
`BuildHasherDefault`is only one way of implementing `BuildHasher`. Clearly, every `BuildHasherDefault` for the same type `H` is identical, since it just uses `Default<H>` to construct `H`. In general, this is not true for every `BuildHasher`, so I think it is helpful to implement `PartialEq` and `Eq`.
|
