Add non-panicking abs() functions to all signed integer types.
Currently, calling abs() on one of the signed integer types might panic (in
debug mode at least) because the absolute value of the largest negative value
can not be represented in that signed type. Unlike all other integer
operations, there is currently not a non-panicking version on this function.
This seems to just be an oversight in the design, therefore just adding it now.
Auto merge of #34951 - tomgarcia:covariant-vec, r=brson
Make vec::Drain and binary_heap::Drain covariant
I removed all mutable pointers/references, and added covariance tests similar to the ones in #32635. It builds and passes the tests, but I noticed that there weren't any tests of Drain's behaviour (at least not in libcollectionstest), so I'm not sure if my changes accidently broke Drain's behaviour. Should I add some tests for that (and if so, what should the tests include)?
Auto merge of #34856 - jseyfried:refactor_reset_tls, r=nrc
Avoid reseting the thread local interner at the beginning of `phase_1_parse_input`
The thread local interner is used before `phase_1_parse_input` to create `InternedString`s, which currently wrap `Rc<String>`s. Once `InternedString` is refactored to be an interned string id (like `Name`), resetting will invalidate everything that was interned before `phase_1_parse_input`.
The resets were only useful for the `rusti` project, which can now use `driver::reset_thread_local_state`.
previously the logic was accepting wrong triples (like
`x86_64_unknown-linux-musl`) as valid ones (like `x86_64-unknown-linux-musl`) if
they contained an underscore instead of a dash.
fixes #33329
---
r? @brson
I wanted to use a compile-fail test at first. But, you can't pass an extra `--target` flag to `rustc` for those because they already call `rustc --target $HOST` so you get a `error: Option 'target' given more than once.`. The run-make test used here works fine though.
Auto merge of #33312 - Byron:double-ended-iterator-for-args, r=alexcrichton
DoubleEndedIterator for Args
This PR implements the DoubleEndedIterator trait for the `std::env::Args[Os]` structure, as well
as the internal implementations.
It is primarily motivated by me, as I happened to implement a simple `reversor` program many times
now, which so far had to use code like this:
```Rust
for arg in std::env::args().skip(1).collect::<Vec<_>>().iter().rev() {}
```
... even though I would have loved to do this instead:
```Rust
for arg in std::env::args().skip(1).rev() {}
```
The latter is more natural, and I did not find a reason for not implementing it.
After all, on every system, the number of arguments passed to the program are known
at runtime.
To my mind, it follows KISS, and does not try to be smart at all. Also, there are no unit-tests,
primarily as I did not find any existing tests for the `Args` struct either.
The windows implementation is basically a copy-pasted variant of the `next()` method implementation,
and I could imagine sharing most of the code instead. Actually I would be happy if the reviewer would
ask for it.
Auto merge of #34983 - alexcrichton:windows-flaky, r=brson
std: Ignore tests where threads outlive main
Long ago we discovered that threads which outlive main and then exit while the
rest of the program is exiting causes Windows to hang (#20704). That's what was
happening in this test so let's just not run this test any more.
Rollup merge of #34965 - jonathandturner:multispan_cleanup, r=sanxiyn
Remove unused methods from MultiSpan
Removed a couple of unused methods from MultiSpan. I thought about batching this with some other changes but wasn't sure when I'd get around to them, so PR for a tiny fix instead.
Alex Crichton [Fri, 22 Jul 2016 23:21:51 +0000 (16:21 -0700)]
std: Ignore tests where threads outlive main
Long ago we discovered that threads which outlive main and then exit while the
rest of the program is exiting causes Windows to hang (#20704). That's what was
happening in this test so let's just not run this test any more.
Auto merge of #34924 - cgswords:empty_delim, r=nrc
Added empty CloseDelim to tokens for future use.
Description says it all. I added a new DelimToken type, Empty, to indicate a Delimited tokenstream with no actual delimiters (which are variously useful for constructing macro output).
try to recover the non-matching types in projection errors
The type equation in projection takes place under a binder and a snapshot, which
we can't easily take types out of. Instead, when encountering a projection error,
try to re-do the projection and find the type error then.
This fails to produce a sane type error when the failure was a "leak_check" failure.
I can't think of a sane way to show *these*, so I just left them use the old crappy
representation, and added a test to make sure we don't break them.
Refactor constant evaluation to use a single error reporting function
that reports a type-error-like message.
Also, unify all error codes with the "constant evaluation error" message
to just E0080, and similarly for a few other duplicate codes. The old
situation was a total mess, and now that we have *something* we can
further iterate on the UX.
switch projection errors to use the new type error messages
Unfortunately, projection errors do not come with a nice set of
mismatched types. This is because the type equality check occurs
within a higher-ranked context. Therefore, only the type error
is reported. This is ugly but was always the situation.
I will introduce better errors for the lower-ranked case in
another commit.
Auto merge of #34724 - mitchmindtree:mpsc_receiver_try_recv, r=alexcrichton
Add a method to the mpsc::Receiver for producing a non-blocking iterator
Currently, the `mpsc::Receiver` offers methods for receiving values in both blocking (`recv`) and non-blocking (`try_recv`) flavours. However only blocking iteration over values is supported. This PR adds a non-blocking iterator to complement the `try_recv` method, just as the blocking iterator complements the `recv` method.
Use-case
-------------
I predominantly use rust in my work on real-time systems and in particular real-time audio generation/processing. I use `mpsc::channel`s to communicate between threads in a purely non-blocking manner. I.e. I might send messages from the GUI thread to the audio thread to update the state of the dsp-graph, or from the audio thread to the GUI thread to display the RMS of each node. These are just a couple examples (I'm probably using 30+ channels across my various projects). I almost exclusively use the `mpsc::Receiver::try_recv` method to avoid blocking any of the real-time threads and causing unwanted glitching/stuttering. Now that I mention it, I can't think of a single time that I personally have used the `recv` method (though I can of course see why it would be useful, and perhaps the common case for many people).
As a result of this experience, I can't help but feel there is a large hole in the `Receiver` API.
For the most part, I've been working around this using `while let Ok(v) = r.try_recv() { ... }`, however as nice as this is, it is clearly no match for the Iterator API.
As an example, in the majority of my channel use cases I only want to check for *n* number of messages before breaking from the loop so that I don't miss the audio IO callback or hog the GUI thread for too long when an unexpectedly large number of messages are sent. Currently, I have to write something like this:
```rust
let mut take = 100;
while let Ok(msg) = rx.try_recv() {
// Do stuff with msg
if take == 0 {
break;
}
take -= 1;
}
```
or wrap the `try_recv` call in a `Range<usize>`/`FilterMap` iterator combo.
On the other hand, this PR would allow for the following:
```rust
for msg in rx.try_iter().take(100) {
// Do stuff with msg
}
```
I imagine this might also be useful to game devs, embedded or anyone doing message passing across real-time threads.
Auto merge of #34544 - 3Hren:issue/xx/reinterpret-format-precision-for-strings, r=alexcrichton
feat: reinterpret `precision` field for strings
This commit changes the behavior of formatting string arguments with both width and precision fields set.
Documentation says that the `width` field is the "minimum width" that the format should take up. If the value's string does not fill up this many characters, then the padding specified by fill/alignment will be used to take up the required space.
This is true for all formatted types except string, which is truncated down to `precision` number of chars and then all of `fill`, `align` and `width` fields are completely ignored.
For example: `format!("{:/^10.8}", "1234567890);` emits "12345678". In the contrast Python version works as the expected:
```python
>>> '{:/^10.8}'.format('1234567890')
'/12345678/'
```
This commit gives back the `Python` behavior by changing the `precision` field meaning to the truncation and nothing more. The result string *will* be prepended/appended up to the `width` field with the proper `fill` char.
__However, this is the breaking change, I admit.__ Feel free to close it, but otherwise it should be mentioned in the `std::fmt` documentation somewhere near of `fill/align/width` fields description.
Rollup merge of #34910 - alexcrichton:hard-float-mips, r=brson
rustc: Remove soft-float from MIPS targets
Right now two MIPS targets in the compiler, `mips-unknown-linux-{gnu,musl}` both
generate object files using the soft-float ABI through LLVM by default. This is
also expressed as the `-C soft-float` codegen option and otherwise isn't used
for any other target in the compiler. This option was added quite some time ago
(back in #9617), and nowadays it's more appropriate to be done through a codegen
option.
This is motivated by #34743 which necessitated an upgrade in the CMake
installation on our bots which necessitated an upgrade in the Ubuntu version
which invalidated the MIPS compilers we were using. The new MIPS compilers
(coming from Debian I believe) all have hard float enabled by default and soft
float support not built in. This meant that we couldn't upgrade the bots
until #34841 landed because otherwise we would fail to compile C code as the
`-msoft-float` option wouldn't work.
Unfortunately, though, this means that once we upgrade the bots the C code we're
compiling will be compiled for hard float and the Rust code will be compiled
for soft float, a bad mismatch! This PR remedies the situation such that Rust
will compile with hard float as well.
If this lands it will likely produce broken nightlies for a day or two while we
get around to upgrading the bots because the current C toolchain only produces
soft-float binaries, and now rust will be hard-float. Hopefully, though, the
upgrade can go smoothly!
Rollup merge of #34890 - oconnor663:addassign, r=brson
implement AddAssign for String
Currently `String` implements `Add` but not `AddAssign`. This PR fills in that gap.
I played around with having `AddAssign` (and `Add` and `push_str`) take `AsRef<str>` instead of `&str`, but it looks like that breaks arguments that implement `Deref<Target=str>` and not `AsRef<str>`. Comments in [`libcore/convert.rs`](https://github.com/rust-lang/rust/blob/master/src/libcore/convert.rs#L207-L213) make it sound like we could fix this with a blanket impl eventually. Does anyone know what's blocking that?
Rollup merge of #34828 - seanmonstar:into-opton, r=alexcrichton
core: impl From<T> for Option<T>
First, the semantics of this `impl` seem spot on. If I have a value `T`, and I wish to make a `Option<T>`, then `Option::from(val)` should always give `Some(val)`.
Second, this allows improvement for several APIs that currently take `Option<T>` as arguments. Consider:
projects / rust.git / log