Rustoc item summaries that are headers were not displayed at all because
they started with whitespace.
This PR fixes this and now removes the whitespace and then displays the
block.
Reject '2' as a binary digit in internals of b: number formatting
The `radix!` macro generates an implementation of the private trait `GenericRadix`, and the code replaced changes Binary's implementation to no longer accept '2' as a valid digit to print.
Granted, this code is literally only ever called from another method in this private trait, and that method has logic to never hand a '2' to the printing function. Even given this, the code's there, I thought it would be best to fix this for clarity of anyone reading it.
Deploy builds both with asserts enabled and asserts disabled to CI.
This also removes uploads to the 'try' bucket, and instead dumps
everything into the two rustc-builds and rustc-builds-alt buckets. This
makes lives easier, as there is only one location for a given "type" of
build, and since we have the git commit hash in the filenames, this is
fine; we won't run into uploads of the same commit.
cc @aidanhs -- this will break crater's logic for downloading `try#xxx` commits since the try bucket won't be uploaded into
r? @alexcrichton
impl From<bool> for AtomicBool
This seems like an obvious omission from #45610. ~~I've used the same feature name and version in the hope that this can be backported to beta so it's stabilized with the other impls. If it can't be I'll change it to `1.24.0`.~~
Improve documentation for slice swap/copy/clone operations.
Fixes#45636.
- Demonstrate how to use these operations with slices of differing
lengths
- Demonstrate how to swap/copy/clone sub-slices of a slice using
`split_at_mut`
Stabilize some `ascii_ctype` methods
As discussed in #39658, this PR stabilizes those methods for `u8` and `char`. All inherent `ascii_ctype` for `[u8]` and `str` are removed as we prefer the more explicit version `s.chars().all(|c| c.is_ascii_())`.
This PR doesn't modify the `AsciiExt` trait. There, the `ascii_ctype` methods are still unstable. It is planned to remove those in the future (I think). I had to modify some code in `ascii.rs` to properly implement `AsciiExt` for all types.
Fixes#39658.
Add std::sync::mpsc::Receiver::recv_deadline()
Essentially renames recv_max_until to recv_deadline (mostly copying recv_timeout
documentation). This function is useful to avoid the often unnecessary call to
Instant::now in recv_timeout (e.g. when the user already has a deadline). A
concrete example would be something along those lines:
```rust
use std::sync::mpsc::Receiver;
use std::time::{Duration, Instant};
/// Reads a batch of elements
///
/// Returns as soon as `max_size` elements have been received or `timeout` expires.
fn recv_batch_timeout<T>(receiver: &Receiver<T>, timeout: Duration, max_size: usize) -> Vec<T> {
recv_batch_deadline(receiver, Instant::now() + timeout, max_size)
}
/// Reads a batch of elements
///
/// Returns as soon as `max_size` elements have been received or `deadline` is reached.
fn recv_batch_deadline<T>(receiver: &Receiver<T>, deadline: Instant, max_size: usize) -> Vec<T> {
let mut result = Vec::new();
while let Ok(x) = receiver.recv_deadline(deadline) {
result.push(x);
if result.len() == max_size {
break;
}
}
result
}
```
Disable all macOS dist images to workaround travis-ci/travis-ci#8821
See: travis-ci/travis-ci#8821
Currently the [Travis status](https://www.traviscistatus.com/) is all green, I don't know how long it takes Travis to notice and fix it, so I'm merging this in immediately to keep the queue running today.
cc @rust-lang/infra
I don't believe the previous code `0 ... 2` would run into any real problems, but it seems confusing to read, given that '2' is never a valid binary digit.
As far as I can tell this code is only ever called from within another private method in the trait which has logic to never hand it '2' anyways. I thought we could change this for clarity anyways.
This also removes uploads to the 'try' bucket, and instead dumps
everything into the two rustc-builds and rustc-builds-alt buckets. This
makes lives easier, as there is only one location for a given "type" of
build, and since we have the git commit hash in the filenames, this is
fine; we won't run into uploads of the same commit.
Replace most call to grep in run-make by a script that cat the input.
Introduced a new `src/etc/cat-and-grep.sh` script (called in run-make as `$(CGREP)`), which prints the input and do a grep simultaneously. This is mainly used to debug spurious failures in run-make, such as the spurious error in #45810, as well as real errors such as #46126.
(cc #40713)
Some `grep` still remains, mainly the `grep -c` calls that count the number of matches and print the result to stdout.
Remove `T: Sized` on `ptr::is_null()`
Originally from #44932 -- this is purely a revert of the last commit of that PR, which was removing some changes from the previous commits in the PR. So a revert of a revert means this is code written by @cuviper!
@mikeyhew makes a compelling case in https://github.com/rust-lang/rfcs/issues/433#issuecomment-345495505 for why this is the right way to implement `is_null` for trait objects. And the behavior for slices makes sense to me as well.
```diff
impl<T: ?Sized> *const T {
- pub fn is_null(self) -> bool where T: Sized;
+ pub fn is_null(self) -> bool;
}
impl<T: ?Sized> *mut T {
- pub fn is_null(self) -> bool where T: Sized;
+ pub fn is_null(self) -> bool;
}
ci: Start running wasm32 tests on Travis
This commit allocates a builder to running wasm32 tests on Travis. Not all test
suites pass right now so this is starting out with just the run-pass and the
libcore test suites. This'll hopefully give us a pretty broad set of coverage
for integration in rustc itself as well as a somewhat broad coverage of the llvm
backend itself through integration/unit tests.
This commit allocates a builder to running wasm32 tests on Travis. Not all test
suites pass right now so this is starting out with just the run-pass and the
libcore test suites. This'll hopefully give us a pretty broad set of coverage
for integration in rustc itself as well as a somewhat broad coverage of the llvm
backend itself through integration/unit tests.
Introduced a new src/etc/cat-and-grep.sh script (called in run-make as
$(CGREP)), which prints the input and do a grep simultaneously. This is
mainly used to debug spurious failures in run-make, such as the sanitizer
error in #45810, as well as real errors such as #46126.
Revert "fix treatment of local types in "remote coherence" mode"
That commit had accidentally snuck in into #44884 and it causes regressions. Revert it.
This reverts commit c48650ec25.
@bors p=10 - fixes breakage in nightly
r? @eddyb
Implement the special repr(C)-non-clike-enum layout
This is the second half of https://github.com/rust-lang/rfcs/pull/2195
which specifies that
```rust
#[repr(C, u8)]
#[derive(Copy, Clone, Eq, PartialEq, Debug)]
enum MyEnum {
A(u32), // Single primitive value
B { x: u8, y: i16 }, // Composite, and the offset of `y` depends on tag being internal
C, // Empty
D(Option<u32>), // Contains an enum
E(Duration), // Contains a struct
}
```
Has the same layout as
```rust
#[repr(C)]
struct MyEnumRepr {
tag: MyEnumTag,
payload: MyEnumPayload,
}
#[repr(C)]
#[allow(non_snake_case)]
union MyEnumPayload {
A: MyEnumVariantA,
B: MyEnumVariantB,
D: MyEnumVariantD,
E: MyEnumVariantE,
}
#[repr(u8)] #[derive(Copy, Clone)] enum MyEnumTag { A, B, C, D, E }
#[repr(C)] #[derive(Copy, Clone)] struct MyEnumVariantA(u32);
#[repr(C)] #[derive(Copy, Clone)] struct MyEnumVariantB {x: u8, y: i16 }
#[repr(C)] #[derive(Copy, Clone)] struct MyEnumVariantD(Option<u32>);
#[repr(C)] #[derive(Copy, Clone)] struct MyEnumVariantE(Duration);
```
MIR: split Operand::Consume into Copy and Move.
By encoding the choice of leaving the source untouched (`Copy`) and invalidating it (`Move`) in MIR, we can express moves of copyable values and have MIR borrow-checking enforce them, *including* ownership transfer of stack locals in calls (when the ABI passes by indirection).
Optimizations could turn a "last-use" `Copy` into a `Move`, and the MIR borrow-checker, at least within the confines of safe code, could even do this when the underlying lvalue was borrowed.
(However, that last part would be the first time lifetime inference affects code generation, AFAIK).
Furthermore, as `Move`s invalidate borrows as well, for any local that is initialized only once, we can ignore borrows that happened before a `Move` and safely reuse/replace its memory storage.
This will allow us to perform NRVO in the presence of short-lived borrows, unlike LLVM (currently), and even compute optimal `StorageLive...StorageDead` ranges instead of discarding them.
[auto-toolstate][1/8] Always ignore build failure of failable tools (rls, rustfmt, clippy)
If build failed for these tools, they will be automatically skipped from distribution, and will not fail the whole build.
Test failures are *not* ignored, nor build failure of other tools (e.g. cargo). Therefore it should have no observable effect to the current CI system.
This is step 1/8 of automatic management of broken tools #45861. The purpose is concentrate all failure detection about tools into a single CI job for easy management, while keeping the ability to distribute these tools in the nightlies.
r? @Mark-Simulacrum
Document non-obvious behavior of fmt::UpperHex & co for negative integers
Before stabilization I’d have suggested changing the behavior, but that time is past.
Introduce LinkedList::drain_filter
This introduces `LinkedList::remove_if`.
This operation embodies one of the use-cases where `LinkedList` would typically be preferred over `Vec`: random removal and retrieval.
There are a number of considerations with this:
Should there be two `remove_if` methods? One where elements are only removed, one which returns a collection of removed elements.
Should this be implemented using a draining iterator pattern that covers both cases? I suspect that would incur a bit of overhead (moving the element into the iterator, then into a new collection). But I'm not sure. Maybe that's an acceptable compromise to maximize flexibility.
I don't feel I've had enough exposure to unsafe programming in rust to be certain the implementation is correct. This relies quite heavily on moving around copies of Shared pointers to make the code reasonable. Please help me out :).
Remove semicolon note
In reference to issue #46186
r? @estebank
First time doing a pull request, if there are any suggestions on how to improve this please let me know.
@jjolly
MIR: Fix value moved diagnose messages
#45960. I believe this will take a different approach. Simply replacing all nouns to verbs (`desired_action`) messes up the message `use of moved value` (although fixes the message in original issue). Here is what happens:
<pre>
$ rustc -Zborrowck-mir src/test/ui/borrowck/borrowck-reinit.rs
error[E0382]: <b>used</b> of moved value: `x` (Mir)
--> src/test/ui/borrowck/borrowck-reinit.rs:18:16
|
17 | drop(x);
| - value moved here
18 | let _ = (1,x);
| ^ value used here after move
error: aborting due to 2 previous errors
</pre>
(Notice: *"**used** of moved value: `x`"* instead of *"**use**"*)
Which does not seem to be okay.
After experimenting a bit, it looks like [`report_use_of_moved_value()`](1dc0b573e7/src/librustc_mir/borrow_check.rs (L1319)) tries to handle both these messages by taking in only one form of`desired_action`.
These messages rise from: *"[{noun} of moved value](1dc0b573e7/src/librustc_mir/borrow_check.rs (L1338-L1342))"* and *"[value {verb} here after move](1dc0b573e7/src/librustc_mir/borrow_check.rs (L1343))"*.
This PR fixes *"value {verb} here after move"* type messages by passing a corresponding verb (`desired_action`) instead of the original noun.
