Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 13 pull requests #74208

Closed
wants to merge 30 commits into from

Conversation

Manishearth
Copy link
Member

Successful merges:

Failed merges:

r? @ghost

RalfJung and others added 30 commits July 3, 2020 13:22
Co-authored-by: Teymour Aldridge <42674621+teymour-aldridge@users.noreply.github.com>
A function that has no prologue cannot be reasonably expected to support
debuginfo. In fact, the existing code (before this patch) would generate
invalid instructions that caused crashes. We can solve this easily by
just not emitting the debuginfo in this case.

Fixes rust-lang#42779
cc rust-lang#32408
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.
This adds `read_exact_at` and `write_all_at` to WASI's `FileExt`,
similar to the Unix versions of the same names.
Rename the existing read_at/write_at to read_vectored_at/write_vectored_at,
for consistency with libstd's read_vectored/write_vectored. And,
introduce new read_at/write_at functions which take a single buffer,
similar to all other targets which provide these functions, so this will
make it easier for applications to share code between WASI and other
targets.

Note that WASI's FileExt is currently unstable.
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.
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).
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.
As of rust-lang#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.
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.
Explain effects of debugging options from config.toml
…, r=alexcrichton

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.
Suppress debuginfo on naked function arguments

A function that has no prologue cannot be reasonably expected to support
debuginfo. In fact, the existing code (before this patch) would generate
invalid instructions that caused crashes. We can solve this easily by
just not emitting the debuginfo in this case.

Fixes rust-lang#42779
cc rust-lang#32408
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: rust-lang#72881
Requires LLVM change: rust-lang/llvm-project#67
…=Mark-Simulacrum

⬆️ 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?
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/reference#844)
- Fix name of trait for array indexing. (rust-lang/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)
…k-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.
…nt, 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
…-fix, r=petrochenkov

linker: illumos ld does not support --eh-frame-hdr

As of rust-lang#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.
…s, r=petrochenkov

Add a help to use `in_band_lifetimes` in nightly

Fixes rust-lang#73775
@Manishearth
Copy link
Member Author

@rustbot modify labels: +rollup
@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented Jul 10, 2020

📌 Commit 8ba2bfc has been approved by Manishearth

@rustbot rustbot added the rollup A PR which is a rollup label Jul 10, 2020
@bors
Copy link
Contributor

bors commented Jul 10, 2020

🌲 The tree is currently closed for pull requests below priority 5, this pull request will be tested once the tree is reopened

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Jul 10, 2020
@bors
Copy link
Contributor

bors commented Jul 10, 2020

⌛ Testing commit 8ba2bfc with merge 3fa59ca7b5a17009e5486684d06a98d696baad82...

@Manishearth
Copy link
Member Author

@pietroalbini looks like it's hanging on checking out the code at https://github.com/rust-lang-ci/rust/runs/856552047

@Manishearth
Copy link
Member Author

@bors retry yield

:/

@bors
Copy link
Contributor

bors commented Jul 10, 2020

⌛ Testing commit 8ba2bfc with merge 1751bcef6a24df68772e7545aa858f0201f3c2b3...

@Manishearth
Copy link
Member Author

@bors treeclosed- I'll be offline when this lands. Given that the rest of CI passed I expect it to land.

@Manishearth
Copy link
Member Author

looks like it's hanging on checking out the code at https://github.com/rust-lang-ci/rust/runs/856552047

And now that page shows that the build was interrupted. It was definitely stuck on "checking out the source code" when I cancelled it, and the expand button on "checking out the source code" wasn't working

@Manishearth
Copy link
Member Author

Actually, this might be an Actions bug:

image

The build is running, but there's still a spinny on "checkout the source code", and the expand button isn't working.

@eddyb
Copy link
Member

eddyb commented Jul 10, 2020

Looks like this is in the same situation now: https://github.com/rust-lang-ci/rust/runs/857062392

I've tried adding this to the <details> for "checkout the source code":

data-log-url="/rust-lang-ci/rust/commit/1751bcef6a24df68772e7545aa858f0201f3c2b3/checks/857062392/logs/3"

Which matches the pattern on the other steps (or in other builds), but it 404s grabbing that from the server.

So I'm guessing this is a server-side bug and the UI reflects that.

@bors
Copy link
Contributor

bors commented Jul 10, 2020

💥 Test timed out

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jul 10, 2020
@Manishearth Manishearth deleted the rollup-4hqp3d7 branch July 18, 2020 01:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet