Rollup merge of #59740 - cuviper:folded-extend, r=scottmcm
Use for_each to extend collections
This updates the `Extend` implementations to use `for_each` for many
collections: `BinaryHeap`, `BTreeMap`, `BTreeSet`, `LinkedList`, `Path`,
`TokenStream`, `VecDeque`, and `Wtf8Buf`.
Folding with `for_each` enables better performance than a `for`-loop for
some iterators, especially if they can just forward to internal
iterators, like `Chain` and `FlatMap` do.
Auto merge of #59710 - alexcrichton:llvm-9-compat, r=sanxiyn
rustc: Start implementing compat with LLVM 9
This commit doesn't actually migrate to LLVM 9, but it brings our own
C++ bindings in line with LLVM 9 and able to compile against tip of
tree. The changes made were:
* The `MainSubprogram` flag for debuginfo moved between flag types.
* Iteration of archive members was tweaked slightly and we have to
construct the two iterators before constructing the returned
`RustArchiveIterator` value.
* The `getOrInsertFunction` binding now returns a wrapper which we use
`getCallee()` on to get the value we're interested in.
Rollup merge of #59727 - alexcrichton:wasi-apis, r=fitzgen
wasi: Use shared API for preopened fds
This commit updates the wasi target with supported added in
CraneStation/wasi-sysroot#10. That function allows both C and Rust to
cooperate in how preopened files are managed, enabling us to learn about
propened files through the same interface. The `open_parent` function in
the wasi `fs` module was updated to avoid its own initialization of a
global preopened map and instead delegate to libc to perform this
functionality.
This should both be more robust into the future in terms of handling
path logic as well as ensuring the propened map is correctly set up at
process boot time. This does currently require some unfortunate
allocations on our side, but if that becomes an issue we can always
paper over those in time!
This removes a misplaced assertion. The function containing the assertion is actually only ever called for upstream crates that are not considered for LTO, so we don't care whether upstream code has been merged in by LTO or not.
Rollup merge of #58894 - GuillaumeGomez:invalid-lifetime-bounds, r=estebank
Fix invalid bounds string generation in rustdoc
Fixes #58737.
Very weird and I'm not sure this is the best fix around. However, trying to fix it beforehand seems overly complicated compared to the gain (in `clean`, it wouldn't change anything since we **have to** return something so that wouldn't work, and in `hir`, I'm afraid I'd break something else for very little gain).
Also, I wasn't able to make a small code to reproduce the issue. The only way to test is to document `crossbeam` directly and check the `Scope` struct...
Josh Stone [Fri, 5 Apr 2019 21:51:07 +0000 (14:51 -0700)]
Use for_each to extend collections
This updates the `Extend` implementations to use `for_each` for many
collections: `BinaryHeap`, `BTreeMap`, `BTreeSet`, `LinkedList`, `Path`,
`TokenStream`, `VecDeque`, and `Wtf8Buf`.
Folding with `for_each` enables better performance than a `for`-loop for
some iterators, especially if they can just forward to internal
iterators, like `Chain` and `FlatMap` do.
This is a rebase of S-blocked-closed PR #55431 to current master. LLVM has moved forward since then, so maybe we can check whether the new LLVM 8.0 version unblocked this work.
Alex Crichton [Fri, 5 Apr 2019 13:37:03 +0000 (06:37 -0700)]
wasi: Use shared API for preopened fds
This commit updates the wasi target with supported added in
CraneStation/wasi-sysroot#10. That function allows both C and Rust to
cooperate in how preopened files are managed, enabling us to learn about
propened files through the same interface. The `open_parent` function in
the wasi `fs` module was updated to avoid its own initialization of a
global preopened map and instead delegate to libc to perform this
functionality.
This should both be more robust into the future in terms of handling
path logic as well as ensuring the propened map is correctly set up at
process boot time. This does currently require some unfortunate
allocations on our side, but if that becomes an issue we can always
paper over those in time!
Alex Crichton [Thu, 4 Apr 2019 20:05:41 +0000 (13:05 -0700)]
rustc: Start implementing compat with LLVM 9
This commit doesn't actually migrate to LLVM 9, but it brings our own
C++ bindings in line with LLVM 9 and able to compile against tip of
tree. The changes made were:
* The `MainSubprogram` flag for debuginfo moved between flag types.
* Iteration of archive members was tweaked slightly and we have to
construct the two iterators before constructing the returned
`RustArchiveIterator` value.
* The `getOrInsertFunction` binding now returns a wrapper which we use
`getCallee()` on to get the value we're interested in.
Auto merge of #59076 - dtolnay:comma, r=alexcrichton
Include trailing comma in multiline Debug representation
This PR changes the behavior of [`Formatter::debug_struct`](https://doc.rust-lang.org/std/fmt/struct.Formatter.html#method.debug_struct), [`debug_tuple`](https://doc.rust-lang.org/std/fmt/struct.Formatter.html#method.debug_tuple), [`debug_list`](https://doc.rust-lang.org/std/fmt/struct.Formatter.html#method.debug_list), [`debug_set`](https://doc.rust-lang.org/std/fmt/struct.Formatter.html#method.debug_set), and [`debug_map`](https://doc.rust-lang.org/std/fmt/struct.Formatter.html#method.debug_map) to render trailing commas in `{:#?}` mode, which is the dominant style in modern Rust code.
#### Before:
```console
Language {
name: "Rust",
trailing_commas: false
}
```
#### After:
```console
Language {
name: "Rust",
trailing_commas: true,
}
```
David Tolnay [Wed, 3 Apr 2019 14:30:08 +0000 (07:30 -0700)]
Include trailing comma in multiline Debug representation
This commit changes the behavior of Formatter::debug_struct,
debug_tuple, debug_list, debug_set, and debug_map to render trailing
commas in {:#?} mode, which is the dominant style in modern Rust code.
Auto merge of #59721 - Centril:rollup-ieam9ke, r=Centril
Rollup of 5 pull requests
Successful merges:
- #59665 (improve worst-case performance of HashSet.is_subset)
- #59687 (cleanup shebang handling in the lexer)
- #59690 (Mark unix::ffi::OsStrExt methods as inline)
- #59702 (Use declare_lint_pass! and impl_lint_pass! in more places)
- #59712 (wasm32: Default to a "static" relocation model)
Rollup merge of #59712 - alexcrichton:wasm-static-not-pic, r=eddyb
wasm32: Default to a "static" relocation model
LLVM 9 is adding support for a "pic" relocation model for wasm code,
which is quite different than the current model. In order to preserve
the mode of compilation that we have today default to "static" to ensure
that we don't accidentally start creating experimental relocatable
binaries.
Rollup merge of #59665 - ssomers:hashset_revisited, r=KodrAus
improve worst-case performance of HashSet.is_subset
One more simple optimization opportunity for HashSet that was applied in BTreeSet in #59186 (and wasn't in #57043). Already covered by the existing unit test.
Auto merge of #59681 - dtolnay:cargo, r=alexcrichton
Update cargo
20 commits in 63231f438a2b5b84ccf319a5de22343ee0316323..6f3e9c367abb497c64f360c3839dab5e74928d5c
2019-03-27 12:26:45 +0000 to 2019-04-04 14:11:33 +0000
- Fix Init for Fossil SCM project (rust-lang/cargo#6792)
- Fix member_manifest_version_error accessing the network (rust-lang/cargo#6799)
- Don't include email if it is empty (rust-lang/cargo#6802)
- Fix unused import warning (rust-lang/cargo#6807)
- Add some help and documentation for unstable flags (rust-lang/cargo#6791)
- Allow `cargo doc --open` with multiple packages (rust-lang/cargo#6803)
- Allow `cargo install --path P` to load config from P (rust-lang/cargo#6804)
- Add more suggestions on how to deal with excluding a package from a workspace (rust-lang/cargo#6805)
- Warn on version req with metadata (rust-lang/cargo#6806)
- cargo install: Be more restrictive about cli flags (rust-lang/cargo#6801)
- Support force-pushed repos with git-fetch-with-cli (rust-lang/cargo#6800)
- Cargo clippy (rust-lang/cargo#6759)
- Don't include metadata in wasm binary examples (rust-lang/cargo#6812)
- Update glossary for `feature` (rust-lang/cargo#6809)
- Include proc-macros in `build-override` (rust-lang/cargo#6811)
- Resolver: A dep is equivalent to one of the things it can resolve to (rust-lang/cargo#6776)
- Add some docs for `Downloads` (rust-lang/cargo#6815)
- Resolve: Be less strict while offline (rust-lang/cargo#6814)
- Accept trailing comma in test of impl Debug for PackageId (rust-lang/cargo#6818)
- Fix doc link (rust-lang/cargo#6820)
<br>
I specifically care about "Accept trailing comma in test of impl Debug for PackageId (rust-lang/cargo#6818)" to unblock https://github.com/rust-lang/rust/pull/59076.
Auto merge of #59643 - alexcrichton:wasi-symbols, r=sanxiyn
std: Upgrade `compiler_builtins` to fix wasi linkage
Turns out we needed to exclude a number of math functions on the
`wasm32-unknown-wasi` target, and this was fixed in 0.1.9 of
compiler-builtins and this is pulling in the fix to libstd's own build.
Alex Crichton [Thu, 4 Apr 2019 20:23:42 +0000 (13:23 -0700)]
wasm32: Default to a "static" relocation model
LLVM 9 is adding support for a "pic" relocation model for wasm code,
which is quite different than the current model. In order to preserve
the mode of compilation that we have today default to "static" to ensure
that we don't accidentally start creating experimental relocatable
binaries.
Alex Crichton [Tue, 2 Apr 2019 20:38:51 +0000 (13:38 -0700)]
std: Upgrade `compiler_builtins` to fix wasi linkage
Turns out we needed to exclude a number of math functions on the
`wasm32-unknown-wasi` target, and this was fixed in 0.1.9 of
compiler-builtins and this is pulling in the fix to libstd's own build.
Auto merge of #59676 - alexcrichton:osx-deadlock, r=sfackler
std: Avoid usage of `Once` in `Instant`
This commit removes usage of `Once` from the internal implementation of
time utilities on OSX and Windows. It turns out that we accidentally hit
a deadlock today (#59020) via events that look like:
* A thread invokes `park_timeout`
* Internally, only on OSX, `park_timeout` calls `Instant::elapsed`
* Inside of `Instant::elapsed` on OSX we enter a `Once` to initialize
global timer data
* Inside of `Once`, it attempts to `park`
This means on the same stack frame, when there's contention, we're
calling `park` from inside `park_timeout`, causing a deadlock!
The solution implemented in this commit was to remove usage of `Once`
and instead just do a small dance with atomics. There's no real need we
need to guarantee that the global information is only learned once, only
that it's only *stored* once. This implementation may have multiple
threads invoke `mach_timebase_info`, but only one will store the global
information which will amortize the cost for all other threads.
A similar fix has been applied to windows to be uniform across our
implementations, but looking at the code on Windows no deadlock was
possible. This is purely just a consistency update for Windows and in
theory a slightly leaner implementation.
Alex Crichton [Wed, 3 Apr 2019 19:18:38 +0000 (12:18 -0700)]
std: Avoid usage of `Once` in `Instant`
This commit removes usage of `Once` from the internal implementation of
time utilities on OSX and Windows. It turns out that we accidentally hit
a deadlock today (#59020) via events that look like:
* A thread invokes `park_timeout`
* Internally, only on OSX, `park_timeout` calls `Instant::elapsed`
* Inside of `Instant::elapsed` on OSX we enter a `Once` to initialize
global timer data
* Inside of `Once`, it attempts to `park`
This means on the same stack frame, when there's contention, we're
calling `park` from inside `park_timeout`, causing a deadlock!
The solution implemented in this commit was to remove usage of `Once`
and instead just do a small dance with atomics. There's no real need we
need to guarantee that the global information is only learned once, only
that it's only *stored* once. This implementation may have multiple
threads invoke `mach_timebase_info`, but only one will store the global
information which will amortize the cost for all other threads.
A similar fix has been applied to windows to be uniform across our
implementations, but looking at the code on Windows no deadlock was
possible. This is purely just a consistency update for Windows and in
theory a slightly leaner implementation.
Lexer is a `pub` type, so it feels wrong that its fields are just pub (I guess it wasn't exported initially), so let's minimize visibility.
Context: I am looking into extracting rust-lexer into a library, which can be shared by rust-analyzer and rustc. I hope that a simple interface like `fn next_token(src: &str) -> (TokenKind, usize)` would work, but to try this out I need to understand what is the current API of the lexer.
Rollup merge of #59639 - cuviper:ignore-uninhabited, r=eddyb
Never return uninhabited values at all
Functions with uninhabited return values are already marked `noreturn`,
but we were still generating return instructions for this. When running
with `-C passes=lint`, LLVM prints:
Unusual: Return statement in function with noreturn attribute
The LLVM manual makes a stronger statement about `noreturn` though:
> This produces undefined behavior at runtime if the function ever does
dynamically return.
We now emit an `abort` anywhere that would have tried to return an
uninhabited value.
Rollup merge of #59596 - LukasKalbertodt:fix-range-fmt, r=Kimundi
Forward formatter settings to bounds of `Range<T>` in `fmt::Debug` impl
Before this change, formatter settings were lost when printing a `Range`. For example, printing a `Range<f32>` with `{:.2?}` would not apply the precision modifier when printing the floats. Now the `Debug` impls look a bit more verbose, but modifier are not lost.
---
I assume the exact output of `Debug` impls in `std` cannot be relied on by users and thus can change, right?
Auto merge of #59619 - alexcrichton:wasi-fs, r=fitzgen
wasi: Implement more of the standard library
This commit fills out more of the `wasm32-unknown-wasi` target's standard library, notably the `std::fs` module and all of its internals. A few tweaks were made along the way to non-`fs` modules, but the last commit contains the bulk of the work which is to wire up all APIs to their equivalent on WASI targets instead of unconditionally returning "unsupported". After this some basic filesystem operations and such should all be working in WASI!
Auto merge of #59684 - Centril:rollup-n7pnare, r=Centril
Rollup of 6 pull requests
Successful merges:
- #59316 (Internal lints take 2)
- #59663 (Be more direct about borrow contract)
- #59664 (Updated the documentation of spin_loop and spin_loop_hint)
- #59666 (Updated the environment description in rustc.)
- #59669 (Reduce repetition in librustc(_lint) wrt. impl LintPass by using macros)
- #59677 (rustfix coverage: Skip UI tests with non-json error-format)
Rollup merge of #59677 - phansch:rustfix_coverage_handle_other_error_formats, r=oli-obk
rustfix coverage: Skip UI tests with non-json error-format
When using the `rustfix-coverage` flag, some tests currently fail
because they define a different error-format than `json`.
The current implementation crashes when encountering those tests. Since
we don't care about non-json test output when collecting the coverage
data, we handle those tests by returning an empty `Vec` instead.
Rollup merge of #59664 - DevQps:improve-yield-spinlock-docs, r=alexcrichton
Updated the documentation of spin_loop and spin_loop_hint
# Description
- Updated the description of `core::hints::spin_loop`
- Updated the description of `core::async::spin_loop_hint`
Both documentation is rewritten to better reflect when one should prefer using a busy-wait spin-loop (and the `spin_loop` and `spin_loop_hint` functions) over `yield_now`. It also dives a little bit deeper on what the function actually does.
Rollup merge of #59663 - matklad:borrow, r=dtolnay
Be more direct about borrow contract
I always was confused by the difference between Borrow and AsRef, despite the fact that I've read all available docs at least a dozen of times.
I finally grokked the difference between the two when I realized the Borrow invariant:
> If you implement Borrow, you **must** make sure that Eq, Ord and Hash implementations are equivalent for borrowed and owned data
My problem was that this invariant is not stated explicitly in documentation, and instead some vague and philosophical notions are used.
So I suggest to mention the requirements of `Borrow` very explicitly: instead of "use Borrow when X and use AsRef when Y", let's phrase this as `Borrow` differs from `AsRef` in `W`, so that's why `Borrow` is for `X` and `AsRef` is for `Y`.
Note that this change could be seen as tightening contract of the Borrow. Let's say Alice has written the following code:
impl Borrow<str> for Person {
fn borrow(&self) -> &str { self.first_name.as_str() }
}
```
Now Bob uses this `Person` struct, puts it into `HashMap` and tries to look it up using `&str` for the first name. Bob's code naturally fails.
The question is, who is to blame: Alice, who has written the impl, or Bob, who uses the HashMap. If I read the current docs literally, I would say that `Bob` is to blame: `Eq` and `Hash` bounds appear on HashMap, so it is the HashMap which requires that they are consistent. By using a type for which the `Borrow` impl does not yield well-behaved `Eq`, Bob is violating contract of HashMap.
If, as this PR proposes, we unconditionally require that Eq & friends for borrow should be valid, then the blame shifts to Alice, which I think is more reasonable.
Josh Stone [Wed, 3 Apr 2019 22:44:49 +0000 (15:44 -0700)]
Never return uninhabited values at all
Functions with uninhabited return values are already marked `noreturn`,
but we were still generating return instructions for this. When running
with `-C passes=lint`, LLVM prints:
Unusual: Return statement in function with noreturn attribute
The LLVM manual makes a stronger statement about `noreturn` though:
> This produces undefined behavior at runtime if the function ever does
dynamically return.
We now emit an `abort` anywhere that would have tried to return an
uninhabited value.
Philipp Hansch [Wed, 3 Apr 2019 19:30:57 +0000 (21:30 +0200)]
rustfix coverage: Skip UI tests with non-json error-format
When using the `rustfix-coverage` flag, some tests currently fail
because they define a different error-format than `json`.
The current implementation crashes when encountering those tests. Since
we don't care about non-json test output when collecting the coverage
data, we handle those tests by returning an empty `Vec` instead.
projects / rust.git / log