| Age | Commit message (Collapse) | Author | Lines |
|
|
|
|
|
|
|
|
|
|
|
Rollup of 10 pull requests
Successful merges:
- #72920 (Stabilize `transmute` in constants and statics but not const fn)
- #73715 (debuginfo: Mangle tuples to be natvis friendly, typedef basic types)
- #74066 (Optimize is_ascii for str and [u8].)
- #74116 (Fix cross compilation of LLVM to aarch64 Windows targets)
- #74167 (linker: illumos ld does not support --eh-frame-hdr)
- #74168 (Add a help to use `in_band_lifetimes` in nightly)
- #74197 (Reword incorrect `self` token suggestion)
- #74213 (Minor refactor for rustc_resolve diagnostics match)
- #74240 (Fix #74081 and add the test case from #74236)
- #74241 (update miri)
Failed merges:
r? @ghost
|
|
|
|
update miri
This incorporates https://github.com/rust-lang/miri/pull/1474. [Last time](https://github.com/rust-lang/rust/pull/74146) that change caused trouble but I fixed xargo since then and [now it should work](https://github.com/rust-lang/rust/pull/74146#issuecomment-657051446).
Cc @rust-lang/miri r? @ghost
|
|
Fix #74081 and add the test case from #74236
|
|
Minor refactor for rustc_resolve diagnostics match
Use `matches!` instead of old `if let`
|
|
Reword incorrect `self` token suggestion
|
|
Add a help to use `in_band_lifetimes` in nightly
Fixes #73775
|
|
linker: illumos ld does not support --eh-frame-hdr
As of rust-lang/rust#73564, the --eh-frame-hdr flag is unconditionally
passed to linkers on many platforms. The illumos link editor does not
currently support this flag.
The linker machinery in the Rust toolchain currently seems to use the
(potentially cross-compiled) target to choose linker flags, rather than
looking at what might be running on the build system. Disabling the
flag for all illumos/Solaris targets seems like the best we can do for
now without more serious surgery.
|
|
Fix cross compilation of LLVM to aarch64 Windows targets
When cross-compiling, the LLVM build system recurses to build tools that need to run on the host system. However, since we pass cmake defines to set the compiler and target, LLVM still compiles these tools for the target system, rather than the host. The tools then fail to execute during the LLVM build.
This change sets defines for the tools that need to run on the host (llvm-nm, llvm-tablegen, and llvm-config), so that the LLVM build does not attempt to build them, and instead relies on the tools already built.
If compiling with clang-cl, adds the `--target` option to specify the target triple. MSVC compilers do not require this, since there is a separate compiler binary for each cross-compilation target.
Related issue: #72881
Requires LLVM change: rust-lang/llvm-project#67
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
This to fix #74081.
|
|
|
|
As per the discussion in PR #74147, the 4 individual tests are replaced by a
single one.
The test is expanded to cover all 4 public/private cases, each with and without
--document-private-items.
|
|
|
|
Rollup of 19 pull requests
Successful merges:
- #71322 (Accept tuple.0.0 as tuple indexing (take 2))
- #72303 (Add core::future::{poll_fn, PollFn})
- #73862 (Stabilize casts and coercions to `&[T]` in const fn)
- #73887 (stabilize const mem::forget)
- #73989 (adjust ub-enum test to be endianess-independent)
- #74045 (Explain effects of debugging options from config.toml)
- #74076 (Add `read_exact_at` and `write_all_at` to WASI's `FileExt`)
- #74099 (Add VecDeque::range* methods)
- #74100 (Use str::strip* in bootstrap)
- #74103 (Only add CFGuard on `windows-msvc` targets)
- #74109 (Only allow `repr(i128/u128)` on enum)
- #74122 (Start-up clean-up)
- #74125 (Correctly mark the ending span of a match arm)
- #74127 (Avoid "whitelist")
- #74129 (:arrow_up: rust-analyzer)
- #74135 (Update books)
- #74145 (Update rust-installer to latest version)
- #74161 (Fix disabled dockerfiles)
- #74162 (take self by value in ToPredicate)
Failed merges:
r? @ghost
|
|
take self by value in ToPredicate
|
|
r=Mark-Simulacrum
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.
|
|
Update books
## book
3 commits in 4e7c00bece1544d409312ec93467beb62b5bd0cb..84a31397b34f9d405df44f2899ff17a4828dba18
2020-06-19 09:39:12 -0400 to 2020-07-04 10:50:18 -0500
- Update Windows install instructions (rust-lang/book#2389)
- Update ch01-02-hello-world.md (rust-lang/book#2386)
- bump mdbook version in github action (rust-lang/book#2380)
## reference
2 commits in 04d5d5d7ba624b6f5016298451f3a63d557f3260..0ea7bc494f1289234d8800bb9185021e0ad946f0
2020-06-16 15:08:05 -0700 to 2020-07-02 15:33:04 -0700
- Fix mis-capitalization of type name. (rust-lang-nursery/reference#844)
- Fix name of trait for array indexing. (rust-lang-nursery/reference#840)
## embedded-book
1 commits in 616962ad0dd80f34d8b802da038d0aed9dd691bb..94d9ea8460bcbbbfef1877b47cb930260b5849a7
2020-06-23 16:03:45 +0000 to 2020-07-05 14:17:40 +0000
- Note on transformation of static variables by attribute exception (rust-embedded/book#251)
## rust-by-example
1 commits in 6f94ccb48da6fa4ed0031290f21411cf789f7d5e..229c6945a26a53a751ffa4f9cb418388c00029d3
2020-06-20 17:51:30 -0300 to 2020-07-06 10:13:15 -0300
- Modify comments (rust-lang/rust-by-example#1359)
|
|
:arrow_up: rust-analyzer
This updates rust-analyzer submodule to the latest release.
I plan to do that every Monday after rust-analyzer release (about 16:00 CET).
This is semi-automated by https://github.com/rust-analyzer/rust-analyzer/pull/5253/files#diff-c06f6a9cbd0ad2421bcc2ddc28805457R77-R100.
Who would be the appropriate person to r? on Mondays?
|
|
Avoid "whitelist"
Other terms are more inclusive and precise.
|
|
Correctly mark the ending span of a match arm
Closes #74050
r? @matthewjasper
|
|
Start-up clean-up
r? @petrochenkov
|
|
Only allow `repr(i128/u128)` on enum
Fixes #74082
|
|
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.
|
|
Explain effects of debugging options from config.toml
|
|
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 const mem::forget
Stabilizes const `mem::forget` as implemented in https://github.com/rust-lang/rust/pull/69617 and tracked in https://github.com/rust-lang/rust/issues/69616.
Closes https://github.com/rust-lang/rust/issues/69616
|
|
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.
|
|
|
|
Other terms are more inclusive and precise.
|