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...
r? @QuietMisdreavus
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.
Unsized rvalues: implement boxed closure impls. (2nd try)
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.
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 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.
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.
Before:
Language {
name: "Rust",
trailing_commas: false
}
After:
Language {
name: "Rust",
trailing_commas: true,
}
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.
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.
r? @KodrAus
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.
ci: Update FreeBSD tarball downloads
These appear to have disappeared from the original server, so I acquired
the contents from a different mirror and uploaded them to our S3 bucket
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.
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.
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.
Closes#59020
A comment in one match arm make a blanket statement about "reads/reservations", but in fact the whole point of this PR is that reservations are *not* handled by that particular arm anymore.
