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.
Auto merge of #5769 - robojumper:match_like_matches_macro, r=phansch
new lint: match_like_matches_macro
Suggests using the `matches!` macro from `std` where appropriate.
`redundant_pattern_matching` has been moved into the `matches` pass to allow suppressing the suggestion where `is_some` and friends are a better replacement.
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.
Christian Duerr [Fri, 26 Jun 2020 15:03:10 +0000 (17:03 +0200)]
Move range_minus_one to pedantic
This moves the range_minus_one lint to the pedantic category, so there
will not be any warnings emitted by default. This should work around
problems where the suggestion is impossible to resolve due to the range
consumer only accepting a specific range implementation, rather than the
`RangeBounds` trait (see #3307).
While it is possible to work around this by extracting the boundary into
a variable, I don't think clippy should encourage people to disable or
work around lints, but instead the lints should be fixable. So hopefully
this will help until a proper implementation checks what the range is
used for.
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).
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`
This change creates a new Docker image, "dist-x86_64-illumos", and sets
things up to build the full set of "dist" packages for illumos hosts, so
that illumos users can use "rustup" to install packages. It also
adjusts the manifest builder to expect complete toolchains for this
platform.
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.
Tom Eccles [Wed, 8 Jul 2020 20:57:57 +0000 (21:57 +0100)]
ci: fix context for disabled docker images
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.
Tom Eccles [Wed, 8 Jul 2020 18:23:51 +0000 (19:23 +0100)]
ci: disabled: riscv: minimise docker overlays
Suggested by @bjorn3
Every RUN command creates a new overlay on top of the image as of before
the RUN command. Using fewer RUN commands prevents intermediate overlays
(which in this case would have contained the entire Linux source tree).
Auto merge of #74153 - ehuss:fix-bootstrap-test-librustc, r=Mark-Simulacrum
Fix x.py test for librustc crates.
#73352 introduced a bug where `x.py test src/librustc_ast` would fail to actually run the tests. The issue is that `krate` and `all_krates` were changed to return relative paths. This caused the code to do a test of "relative_path ends with absolute path" which is always false. The solution is to swap that around.
The change to `Crate` isn't necessary, it just simplifies the code and makes it uniform with `CrateLibrustc`.
There don't seem to be any other compiletests that are 1) building a standalone "no_core" create and then 2) trying to link against it. There seems to be a platform-specific limitation in doing so:
```
2020-07-08T16:07:42.9419409Z = note: Creating library D:\a\rust\rust\build\i686-pc-windows-msvc\test\rustdoc\intra-link-prim-methods-external-core\auxiliary\my_core.dll.lib and object D:\a\rust\rust\build\i686-pc-windows-msvc\test\rustdoc\intra-link-prim-methods-external-core\auxiliary\my_core.dll.exp
2020-07-08T16:07:42.9419810Z LINK : error LNK2001: unresolved external symbol __DllMainCRTStartup@12
2020-07-08T16:07:42.9420032Z D:\a\rust\rust\build\i686-pc-windows-msvc\test\rustdoc\intra-link-prim-methods-external-core\auxiliary\my_core.dll : fatal error LNK1120: 1 unresolved externals
```
Possibly this could be resolved by adding a `__DllMainCRTStartup` or `__DllMainCRTStartup@12` symbol in an architecture- and platform-specific way.
Arlo Siemsen [Thu, 2 Jul 2020 17:45:10 +0000 (10:45 -0700)]
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, this change also adds the `--target` option
to specify the target triple. MSVC compilers do not require this, since there
is a separate compiler binary for cross-compilation.
Auto merge of #74124 - ehuss:fix-doc-dry-run-up-to-date, r=Mark-Simulacrum
Fix occasional bootstrap panic in docs.
I am occasionally running into this panic when running `x.py`:
> thread 'main' panicked at 'source "/Users/eric/Proj/rust/rust/build/x86_64-apple-darwin/md-doc/unstable-book" failed to get metadata: No such file or directory (os error 2)', src/build_helper/lib.rs:173:19
I have not been able to figure out the exact sequence of commands that leads to this error (I tried for quite a while to reproduce it). I think it may involve updating my tree, but I am uncertain. An artificial way to trigger it is to build the documentation, and then delete the `md-doc` directory manually.
The cause is that bootstrap does a "dry run" before every command, and in this case `up_to_date` panics because the destination exists (`build/x86_64-apple-darwin/doc/unstable-book/index.html `) but the source does not (`build/x86_64-apple-darwin/md-doc/unstable-book`).
I am uncertain if it is important that the last line `builder.run(…)` needs to be called during the dry run. This patch seems to fix the issue, though.
Dennis Hamester [Wed, 8 Jul 2020 05:39:49 +0000 (07:39 +0200)]
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.
projects / rust.git / log