Rollup merge of #74147 - dennis-hamester:fix/issue-74134, r=jyn514
rustdoc: Allow linking from private items to private types
Fixes #74134
After PR #72771 this would trigger an intra_doc_link_resolution_failure warning
when rustdoc is invoked without --document-private-items. Links from private
items to private types are however never actually generated in that case and
thus shouldn't produce a warning. These links are in fact a very useful tool to
document crate internals.
Tests are added for all 4 combinations of public/private items and link
targets. Test 1 is the case mentioned above and fails without this commit. Tests
2 - 4 passed before already but are added nonetheless to prevent regressions.
Rollup merge of #74046 - ehuss:deny-warnings-caching, r=Mark-Simulacrum
Fix caching issue when building tools.
This fixes a problem with tool builds not being cached properly.
#73297 changed it so that Clippy will participate in the "deny warnings" setting. Unfortunately this causes a problem because Clippy shares the build directory with other tools which do not participate in "deny warnings". Because Cargo does not independently cache artifacts based on different RUSTFLAGS settings, it causes all the shared dependencies to get rebuilt if Clippy ever gets built.
The solution here is to stop using RUSTFLAGS, and just sneak the settings in through the rustc wrapper. Cargo won't know about the different settings, so it will not bust the cache. This should be safe since lint settings on dependencies are ignored. This is how things used to work in the past before #64316.
Alternate solutions:
* Treat Clippy as a "submodule" and don't enforce warnings on it. This was the behavior before #73297. The consequence is that if a warning sneaks into clippy, that the clippy maintainers will need to fix it when they sync clippy back to the clippy repo.
* Just deny warnings on all tools (removing the in-tree/submodule distinction). This is tempting, but with some issues (cc #52336):
* Adding or changing warnings in rustc can be difficult to land because tools have to be updated if they trip the warning. In practice, this isn't too bad. Cargo (and rustfmt) already runs with `deny(warnings)`, so this has been the de-facto standard already (although they do not use the extra lints like `unused_lifetimes`).
* Teach Cargo to add flags to the workspace members, but not dependencies.
* Teach Cargo to add flags without fingerprinting them?
* Teach Cargo to independently cache different RUSTFLAGS artifacts (this was [reverted](https://github.com/rust-lang/cargo/pull/7417) due to complications). This would also unnecessarily rebuild dependencies, but would avoid cache thrashing.
* Teach Cargo about lint settings.
Auto merge of #74245 - Manishearth:rollup-r0xq9dn, r=Manishearth
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)
Rollup merge of #74241 - RalfJung:miri, r=RalfJung
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).
Rollup merge of #74167 - jclulow:illumos-linker-eh-frame-hdr-fix, r=petrochenkov
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.
Rollup merge of #74116 - arlosi:aarch64build, r=pietroalbini
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
(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.
Rollup merge of #73715 - MaulingMonkey:pr-natvis-tuples, r=Amanieu
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, ...>`)
Rollup merge of #74161 - tblah:riscv64gc-dockerfile-improvment, 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
Rollup merge of #74145 - michaelforney:rust-installer, r=Mark-Simulacrum
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.
Rollup merge of #74103 - ajpaverd:cfguard-msvc-only, r=nikomatsakis
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).
Rollup merge of #74100 - lzutao:strip-bootstrap, r=Mark-Simulacrum
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.
Rollup merge of #74099 - jonhoo:deque-range, r=dtolnay
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.
Rollup merge of #73887 - DutchGhost:master, r=oli-obk
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.
Rollup merge of #73862 - oli-obk:const_array_to_slice, r=RalfJung
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.
Rollup merge of #72303 - yoshuawuyts:future-poll-fn, r=dtolnay
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`.
Rollup merge of #71322 - petrochenkov:tuple00, r=nikomatsakis
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.
Pietro Albini [Mon, 15 Jun 2020 13:12:43 +0000 (15:12 +0200)]
ci: allow gating gha on everything but macOS
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.
Auto merge of #74195 - Manishearth:rollup-h3m0sl8, r=Manishearth
Rollup of 14 pull requests
Successful merges:
- #73292 (Fixing broken link for the Eq trait)
- #73791 (Allow for parentheses after macro intra-doc-links)
- #74070 ( Use for<'tcx> fn pointers in Providers, instead of having Providers<'tcx>.)
- #74077 (Use relative path for local links to primitives)
- #74079 (Eliminate confusing "globals" terminology.)
- #74107 (Hide `&mut self` methods from Deref in sidebar if there are no `DerefMut` impl for the type.)
- #74136 (Fix broken link in rustdocdoc)
- #74137 (Update cargo)
- #74142 (Liballoc use vec instead of vector)
- #74143 (Try remove unneeded ToString import in liballoc slice)
- #74146 (update miri)
- #74150 (Avoid "blacklist")
- #74184 (Add docs for intra-doc-links)
- #74188 (Tweak `::` -> `:` typo heuristic and reduce verbosity)
Rollup merge of #74137 - ehuss:update-cargo, r=ehuss
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)
Rollup merge of #74079 - nnethercote:session-globals, r=nikomatsakis
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`
Rollup merge of #74070 - eddyb:forall-tcx-providers, r=nikomatsakis
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).
projects / rust.git / log