Mark Rousskov [Thu, 26 Jul 2018 15:18:41 +0000 (09:18 -0600)]
Rollup merge of #52723 - alexcrichton:fix-extern-rename-ice, r=estebank
rustc: Register crates under their real names
Whenever we register a crate into the crate store, make sure to use the real
name mentioned in the metadata instead of the name mentioned in the `extern
crate` statement, as the statement can be wrong!
Mark Rousskov [Thu, 26 Jul 2018 15:18:40 +0000 (09:18 -0600)]
Rollup merge of #52721 - cramertj:try-poll, r=aturon
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<...>>>`).
Mark Rousskov [Thu, 26 Jul 2018 15:18:31 +0000 (09:18 -0600)]
Rollup merge of #52654 - alecmocatta:master, r=alexcrichton
Format linker args in a way that works for gcc and ld
Pass multiple linker arguments rather than concatenate with commas (fixes #52634).
`-l library` -> `-llibrary` to work with apple's ld.
To build with apple's ld I'm currently also passing `-C link-args="-arch x86_64 -macosx_version_min 10.13.0"`. I'll try and understand the latter flag better before PRing that.
This PR currently works for me. Hopefully CI will pick up any grievous ramifications in other toolchains?
Thanks to @alexcrichton for the pointer to the relevant code!
Mark Rousskov [Thu, 26 Jul 2018 15:18:30 +0000 (09:18 -0600)]
Rollup merge of #52649 - estebank:fmt-span, r=oli-obk
Point spans to inner elements of format strings
- Point at missing positional specifiers in string literal
```
error: invalid reference to positional arguments 3, 4 and 5 (there are 3 arguments)
--> $DIR/ifmt-bad-arg.rs:34:38
|
LL | format!("{name} {value} {} {} {} {} {} {}", 0, name=1, value=2);
| ^^ ^^ ^^
|
= note: positional arguments are zero-based
```
- Point at named formatting specifier in string literal
```
error: there is no argument named `foo`
--> $DIR/ifmt-bad-arg.rs:37:17
|
LL | format!("{} {foo} {} {bar} {}", 1, 2, 3);
| ^^^^^
```
- Update label for formatting string in "multiple unused formatting arguments" to be more correct
```
error: multiple unused formatting arguments
--> $DIR/ifmt-bad-arg.rs:42:17
|
LL | format!("", 1, 2); //~ ERROR: multiple unused formatting arguments
| -- ^ ^
| |
| multiple missing formatting specifiers
```
- When using `printf` string formatting, provide a structured suggestion instead of a note
```
error: multiple unused formatting arguments
--> $DIR/format-foreign.rs:12:30
|
LL | println!("%.*3$s %s!/n", "Hello,", "World", 4); //~ ERROR multiple unused formatting arguments
| -------------- ^^^^^^^^ ^^^^^^^ ^
| |
| multiple missing formatting specifiers
|
= note: printf formatting not supported; see the documentation for `std::fmt`
help: format specifiers in Rust are written using `{}`
|
LL | println!("{:.2$} {}!/n", "Hello,", "World", 4); //~ ERROR multiple unused formatting arguments
| ^^^^^^ ^^
```
Mark Rousskov [Thu, 26 Jul 2018 15:18:25 +0000 (09:18 -0600)]
Rollup merge of #52610 - MajorBreakfast:task-terminology, r=cramertj
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.
Alex Crichton [Thu, 26 Jul 2018 01:02:03 +0000 (18:02 -0700)]
rustc: Register crates under their real names
Whenever we register a crate into the crate store, make sure to use the real
name mentioned in the metadata instead of the name mentioned in the `extern
crate` statement, as the statement can be wrong!
Mark Rousskov [Tue, 24 Jul 2018 22:43:49 +0000 (16:43 -0600)]
Rollup merge of #52658 - Wallacoloo:topics/use-option-methods, r=cramertj
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.
Mark Rousskov [Tue, 24 Jul 2018 22:43:45 +0000 (16:43 -0600)]
Rollup merge of #52402 - crepererum:build_hasher_eq, r=sfackler
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`.
Mark Rousskov [Tue, 24 Jul 2018 22:43:44 +0000 (16:43 -0600)]
Rollup merge of #52391 - Amanieu:volatile_unaligned, r=alexcrichton
Add unaligned volatile intrinsics
Surprisingly enough, it turns out that unaligned volatile loads are actually useful for certain (very niche) types of lock-free code. I included unaligned volatile stores for completeness, but I currently do not know of any use cases for them.
These are only exposed as intrinsics for now. If they turn out to be useful in practice, we can work towards stabilizing them.
Auto merge of #52257 - steveklabnik:refactor-rustdoc, r=QuietMisdreavus
Refactor rustdoc
This is based on https://github.com/rust-lang/rust/pull/52194 and so shouldn't be merged until it gets merged.
Now that plugin functionality has been removed, let's kill PluginManager. Additionally, rustdoc now follows the standard cargo layout instead of dumping everything at the top level.
Auto merge of #52181 - QuietMisdreavus:panicked-tester, r=GuillaumeGomez
rustdoc: set panic output before starting compiler thread pool
When the compiler was updated to run on a thread pool, rustdoc's processing of compiler/doctest stderr/stdout was moved into each compiler thread. However, this caused output of the test to be lost if the test failed at *runtime* instead of compile time. This change sets up the `set_panic` call and output bomb before starting the compiler thread pool, so that the `Drop` call that writes back to the test's stdout happens after the test runs, not just after it compiles.
Auto merge of #52189 - cuviper:static-box-leak, r=bluss
doc: Clarify the lifetime returned by `Box::leak`
`Box::leak` mentions that it can return a `'static` reference, but it
wasn't immediately clear to me why it doesn't always do so. This is
because of the `T: 'a` constraint needed to form a valid reference, and
in general we want to be more flexible than requiring `T: 'static`.
This patch tries to clarify the relationship between `T` and `'a`.
- #52538 (Remove obsolete flags in the i586_musl Dockerfile)
- #52548 (Cursor: update docs to clarify Cursor only works with in-memory buffers)
- #52605 (Do not suggest using `to_owned()` on `&str += &str`)
- #52621 (Fix color detection for Windows msys terminals.)
- #52622 (Use MultiSpan in E0707 and E709)
- #52627 (Compile rustc before building tests for rustdoc)
- #52637 (Don't use NonNull::dangling as sentinel value in Rc, Arc)
- #52640 (Forget Waker when cloning LocalWaker)
- #52641 (Simplify 2 functions in rustc_mir/dataflow)
- #52642 (Replace a few expect+format combos with unwrap_or_else+panic)
Rollup merge of #52641 - ljedrz:mir_dataflow_misc, r=cramertj
Simplify 2 functions in rustc_mir/dataflow
- `graphviz::outgoing`: the `enumerate` only provides indices; use a range instead
- `DataflowState::interpret_set`: change a push loop to an iterator and remove the `each_bit` helper function
Rollup merge of #52640 - Thomasdezeeuw:fix-localwaker-clone, r=cramertj
Forget Waker when cloning LocalWaker
Since NonNull is Copy the inner field of the cloned Waker was copied for
use in the new LocalWaker, however this left Waker to be dropped. Which
means that when cloning LocalWaker would also erroneously call drop_raw.
This change forgets the Waker, rather then dropping it, leaving the
inner field to be used by the returned LocalWaker.
Rollup merge of #52538 - ljedrz:old_musl_i586_flags, r=kennytm
Remove obsolete flags in the i586_musl Dockerfile
Resolves an [outdated FIXME](https://github.com/rust-lang/rust/blob/ab8b961677ac5c74762dcea955aa0ff4d7fe4915/src/ci/docker/dist-i586-gnu-i586-i686-musl/Dockerfile#L45) in the Dockerfile for dist-i586-gnu-i586-i686-musl.
Auto merge of #52618 - alexcrichton:capture-more, r=petrochenkov
rustc: Implement tokenization of nested items
Ever plagued by #43081 the compiler can return surprising spans in situations
related to procedural macros. This is exhibited by #47983 where whenever a
procedural macro is invoked in a nested item context it would fail to have
correct span information.
While #43230 provided a "hack" to cache the token stream used for each item in
the compiler it's not a full-blown solution. This commit continues to extend
this "hack" a bit more to work for nested items.
Previously in the parser the `parse_item` method would collect the tokens for an
item into a cache on the item itself. It turned out, however, that nested items
were parsed through the `parse_item_` method, so they didn't receive similar
treatment. To remedy this situation the hook for collecting tokens was moved
into `parse_item_` instead of `parse_item`.
Afterwards the token collection scheme was updated to support nested collection
of tokens. This is implemented by tracking `TokenStream` tokens instead of
`TokenTree` to allow for collecting items into streams at intermediate layers
and having them interleaved in the upper layers.
projects / rust.git / log