Optimize is_ascii for str and [u8].
This optimizes the `is_ascii` function for `[u8]` and `str`. I've been surprised this wasn't done for a while, so I just did it.
Benchmarks comparing before/after look like:
```
test ascii::long_readonly::is_ascii_slice_iter_all ... bench: 174 ns/iter (+/- 79) = 40172 MB/s
test ascii::long_readonly::is_ascii_slice_libcore ... bench: 16 ns/iter (+/- 5) = 436875 MB/s
test ascii::medium_readonly::is_ascii_slice_iter_all ... bench: 12 ns/iter (+/- 3) = 2666 MB/s
test ascii::medium_readonly::is_ascii_slice_libcore ... bench: 2 ns/iter (+/- 0) = 16000 MB/s
test ascii::short_readonly::is_ascii_slice_iter_all ... bench: 3 ns/iter (+/- 0) = 2333 MB/s
test ascii::short_readonly::is_ascii_slice_libcore ... bench: 4 ns/iter (+/- 0) = 1750 MB/s
```
(Taken on a x86_64 macbook 2.9 GHz Intel Core i9 with 6 cores)
Where `is_ascii_slice_iter_all` is the old version, and `is_ascii_slice_libcore` is the new.
I tried to document the code well, so hopefully it's understandable. It has fairly exhaustive tests ensuring size/align doesn't get violated -- because `miri` doesn't really help a lot for this sort of code right now, I tried to `debug_assert` all the safety invariants I'm depending on. (Of course, none of them are required for correctness or soundness -- just allows us to test that this sort of pointer manipulation is sound and such).
Anyway, thanks. Let me know if you have questions/desired changes.
debuginfo: Mangle tuples to be natvis friendly, typedef basic types
These changes are meant to unblock rust-lang/rust#70052 "Update hashbrown to 0.8.0" by allowing the use of `tuple<u64, u64>` as a .natvis expression in MSVC style debuggers (MSVC, WinDbg, CDB, etc.)
* f8eb81b does the actual mangling of `(u64, u64)` -> `tuple<u64, 64>`
* 24a728a allows `u64` to resolve (fixing `$T1` / `$T2` when used to visualize `HashMap<u64, u64, ...>`)
Stabilize `transmute` in constants and statics but not const fn
cc #53605 (leaving issue open so we can add `transmute` to `const fn` later)
Previous attempt: #64011
r? @RalfJung
cc @rust-lang/wg-const-eval
Fix disabled dockerfiles
When the dockerfiles were moved into the host-x86_64 directory, paths
for COPY commands were updated with the new host-x86_64/ prefix. This
suggested that the intended context was src/ci/docker. However, the context
for disabled docker images was src/ci/docker/host-x86_64. This broke the new
paths and prevented src/ci/docker/scripts from being included in the
context at all.
This commit corrects this context allowing docker to find the files it
needs for COPY commands.
Also includes a quick fix to riscv recommended by @bjorn3
Update rust-installer to latest version
This pulls in a fix for the install script on some tr(1) implementations,
as well as an update to use `anyhow` instead of `failure` for error
handling.
Only add CFGuard on `windows-msvc` targets
As @ollie27 pointed out in #73893, the `cfguard` module flag causes incorrect behavior on `windows-gnu` targets. This patch restricts rustc to only add this flag for `windows-msvc` targets (this may need to be changed if other linkers gain support for CFGuard).
Use str::strip* in bootstrap
This is technically a breaking change, replacing the use of `trim_start_matches` with `strip_prefix`. However, because in `rustc -Vv` output there are no lines starting with multiple "release:", this should go unnoticed in practice.
Add VecDeque::range* methods
This patch adds `VecDeque::range` and `VecDeque::range_mut` to provide
iterators over a sub-range of a `VecDeque`. This behavior can be
emulated with `skip` and `take`, but directly providing a `Range` is
more ergonomic. This also partially makes up for `VecDeque`'s lack of
`SliceIndex` support.
Add `read_exact_at` and `write_all_at` to WASI's `FileExt`
This adds `read_exact_at` and `write_all_at` to WASI's `FileExt`,
similar to the Unix versions of the same names.
adjust ub-enum test to be endianess-independent
@cuviper noted that our test fails on "other" endianess systems (I never know which is which^^), so let's fix that.
Stabilize casts and coercions to `&[T]` in const fn
Part of #64992
There was never a reason to not stabilize this, we just accidentally prevented them when we implemented the `min_const_fn` feature that gave us `const fn` on stable. This PR stabilizes these casts (which are already stable in `const` outside `const fn`), while keeping all other unsizing casts (so `T` -> `dyn Trait`) unstable within const fn.
These casts have no forward compatibility concerns with any future features for const eval and users were able to use them under the `const_fn` feature gate already since at least the miri merger, possibly longer.
r? @rust-lang/lang
Add core::future::{poll_fn, PollFn}
This is a sibling PR to #70834, adding `future::poll_fn`. This is a small helper function that helps bridge the gap between "poll state machines" and "async/await". It was first introduced in [futures@0.1.7](https://docs.rs/futures/0.1.7/futures/future/fn.poll_fn.html) in December of 2016, and has been tried and tested as part of the ecosystem for the past 3.5 years.
## Implementation
Much of the same reasoning from #70834 applies: by returning a concrete struct rather than an `async fn` we get to mark the future as `Unpin`. It also becomes named which allows storing it in structs without boxing. This implementation has been modified from the implementation in `futures-rs`.
## References
- [`futures::future::poll_fn`](https://docs.rs/futures/0.3.5/futures/future/fn.poll_fn.html)
- [`async_std::future::poll_fn`](https://docs.rs/async-std/1.5.0/async_std/future/fn.poll_fn.html)
Accept tuple.0.0 as tuple indexing (take 2)
If we expect something identifier-like when parsing a field name after `.`, but encounter a float token, we break that float token into parts, similarly to how we break `&&` into `&` `&`, or `<<` into `<` `<`, etc.
An alternative to https://github.com/rust-lang/rust/pull/70420.
Gate GHA on everything but macOS
The macOS spurious failure started happening again. As we discussed during the infra team meeting, this gates on everything but macOS.
r? @Mark-Simulacrum
In our GitHub Actions setup macOS is too unreliable to gate on it, but
the other builders work fine. This commit splits the macOS builders into
a separate job (called auto-fallible), allowing us to gate on the auto
job without failing due to macOS spurious failures.
Tweak `::` -> `:` typo heuristic and reduce verbosity
Do not trigger on correct type ascription expressions with trailing
operators and _do_ trigger on likely path typos where a turbofish is
used.
On likely path typos, remove note explaining type ascription.
Clean up indentation.
r? @petrochenkov
Avoid "blacklist"
Other terms are more inclusive and precise.
Clippy still has a lint named "blacklisted-name", but renaming it would
be a breaking change, so is left for future work.
The target configuration option "abi-blacklist" has been depreciated and
renamed to "unsupported-abis". The old name continues to work.
Update cargo
6 commits in fede83ccf973457de319ba6fa0e36ead454d2e20..4f74d9b2a771c58b7ef4906b2668afd075bc8081
2020-07-02 21:51:34 +0000 to 2020-07-08 17:13:00 +0000
- Disable long_file_names test if not supported on Windows. (rust-lang/cargo#8469)
- Add support for deserializing enums in config files (rust-lang/cargo#8454)
- Write GNU tar files, supporting long names. (rust-lang/cargo#8453)
- Don't overwrite existing `rustdoc` args with --document-private-items (rust-lang/cargo#8449)
- Add some help about rustup's +toolchain syntax. (rust-lang/cargo#8455)
- Update metadata man page. (rust-lang/cargo#8451)
Eliminate confusing "globals" terminology.
There are some structures that are called "globals", but are they global
to a compilation session, and not truly global. I have always found this
highly confusing, so this commit renames them as "session globals" and
adds a comment explaining things.
Also, the commit fixes an unnecessary nesting of `set()` calls
`src/librustc_errors/json/tests.rs`
r? @Aaron1011
Use relative path for local links to primitives
Else, links to `char::foo` would point into `/path/to/src/libcore/std/primitive.char.html#method.foo`.
Split out from #73804.
Use for<'tcx> fn pointers in Providers, instead of having Providers<'tcx>.
In order to work around normalization-under-HRTB (for `provide!` in `rustc_metadata`), we ended up with this:
```rust
struct Providers<'tcx> {
type_of: fn(TyCtxt<'tcx>, DefId) -> Ty<'tcx>,
// ...
}
```
But what I initially wanted to do, IIRC, was this:
```rust
struct Providers {
type_of: for<'tcx> fn(TyCtxt<'tcx>, DefId) -> Ty<'tcx>,
// ...
}
```
This PR moves to the latter, for the simple reason that only the latter allows keeping a `Providers` value, or a subset of its `fn` pointer fields, around in a `static` or `thread_local!`, which can be really useful for custom drivers that override queries.
(@jyn514 and I came across a concrete usecase of that in `rustdoc`)
The `provide!` macro in `rustc_metadata` is fixed by making the query key/value types available as type aliases under `ty::query::query_{keys,values}`, not just associated types (this is the first commit).
r? @nikomatsakis
Do not trigger on correct type ascription expressions with trailing
operators and _do_ trigger on likely path typos where a turbofish is
used.
On likely path typos, remove note explaining type ascription.
Manish Goregaokar