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 10 pull requests #73954

Merged
merged 32 commits into from
Jul 2, 2020
Merged

Rollup of 10 pull requests #73954

merged 32 commits into from
Jul 2, 2020

Conversation

Manishearth
Copy link
Member

Successful merges:

Failed merges:

r? @ghost

petrochenkov and others added 30 commits June 27, 2020 12:36
Also adds back-ticks when referring to the contents of this collection.
added regions with counter expressions and counters.

Added codegen_llvm/coverageinfo mod for upcoming coverage map

Move coverage region collection to CodegenCx finalization

Moved from `query coverageinfo` (renamed from `query coverage_data`),
as discussed in the PR at:

rust-lang#73684 (comment)

Address merge conflict in MIR instrument_coverage test

The MIR test output format changed for int types.

moved debug messages out of block.rs

This makes the block.rs calls to add coverage mapping data to the
CodegenCx much more concise and readable.

move coverage intrinsic handling into llvm impl

I realized that having half of the coverage intrinsic handling in
`rustc_codegen_ssa` and half in `rustc_codegen_llvm` meant that any
non-llvm backend would be bound to the same decisions about how the
coverage-related MIR terminators should be handled.

To fix this, I moved the non-codegen portion of coverage intrinsic
handling into its own trait, and implemented it in `rustc_codegen_llvm`
alongside `codegen_intrinsic_call`.

I also added the (required?) stubs for the new intrinsics to
`IntrepretCx::emulate_intrinsic()`, to ensure calls to this function do
not fail if called with these new but known intrinsics.

address PR Feedback on 28 June 2020 2:48pm PDT
Emscripten's SDK recently bumped the version of NodeJS they shipped, but
our Dockerfile for the wasm32 builder hardcoded the version number. This
will cause consistent CI failures once the currently cached image is
rebuilt (either due to a change or due to the cache expiring).

This commit fixes the problem by finding the latest version of NodeJS in
the Emscripten SDK and symlinking it to a "latest" directory, which is
then added to the PATH.
Implement `slice_strip` feature

Tracking issue: rust-lang#73413
linker: Create GNU_EH_FRAME header by default when producing ELFs

Do it in a centralized way in `link.rs` instead of individual target specs.

The opt-out is `-Clink-arg=(-Wl,)--no-eh-frame-hdr` if necessary.

Fixes rust-lang#73451
cc rust-lang#73483
…ikomatsakis

Deny unsafe ops in unsafe fns in libcore

After `liballoc`, It's time for `libcore` :D

I planned to do this bit by bit to avoid having a big chunk of diffs, so to make reviews easier, and to make the unsafe blocks narrower and take the time to document them properly.

r? @nikomatsakis cc @RalfJung
…r=wesleywiser

add spans to injected coverage counters, extract with CoverageData query

This is the next iteration on the Rust Coverage implementation, and follows PR rust-lang#73488

@tmandry @wesleywiser

I came up with an approach for coverage spans, pushing them through the Call terminator as additional args so they can be extracted by the CoverageData query.

I'm using an IndexVec to store them in CoverageData such that there can be only one per index (even if parts of the MIR get duplicated during optimization).

If this approach works for you, I can quickly expand on this to build a separate IndexVec for counter expressions, using a separate call that will be ignored during code generation, but from which I can extract the counter expression values.

Let me know your thoughts. Thanks!

r? @tmandry

Rust compiler MCP rust-lang/compiler-team#278
Relevant issue: rust-lang#34701 - Implement support for LLVMs code coverage instrumentation
ast_pretty: Pass some token streams and trees by reference

Salvaged from an intermediate version of rust-lang#73345.
…jonas-schievink

Add newline to rustc MultiSpan docs

Also adds back-ticks when referring to the contents of this collection.
…k-Simulacrum

Compile rustdoc less often.

Previously rustdoc was built 3 times with `x.py test`:

1. stage2 (using stage1 compiler) for compiletest tests (stage1-tools copied to stage2).
2. stage1 (using stage0 compiler) for std crate tests (stage0-tools copied to stage1).
3. stage2 test (using stage2 compiler) for rustdoc crate tests and error_index_generator (stage2-tools).

This PR removes the majority of number 3, where it will instead use the stage1 compiler, which will share the artifacts from number 1.

This matches the behavior of the libstd crate tests. I don't think it is entirely necessary to run the tests using stage2.

At `-j2`, the last build step goes from about 300s to 70s on my machine. It's not a huge win, but shaving 4 minutes isn't bad.

The other two builds would be pretty difficult (or undesired or impossible) to unify. It looks like std tests use stage1 very intentionally (see `force_use_stage1` and its history), and compiletests use the top stage very intentionally.

Unfortunately the linkchecker builds all docs at stage2 (stage2-tools), which means a few build script artifacts are not shared. It's not really clear to me how to fix that (because it uses `default_doc`, there doesn't seem to be any control over the stages).

---

For `x.py doc`, rustdoc was previously built three times (with compiler-docs):

1. stage2 (using stage1 compiler) for normal documentation output (stage1-tools copied to stage2).
2. stage1 (using stage0 compiler) for compiler-docs
3. stage2 (using stage2 compiler) for error_index_generator (stage2-tools)

This PR combines these so that they consistently use the "top stage" rustdoc. I don't know why the compiler-docs was written to use stage minus one, but it seems better to be consistent across the doc steps.

---

I've tried to test this with a variety of commands (`x.py doc`, `x.py test`, different `--stage` flags, `full-bootstrap`, setting `--target`, etc.) to try to make sure there aren't significant regressions here. It's tricky since there are so many variables, and this stuff is difficult for me to fully understand.

Closes rust-lang#70799 (I think)
Fix wasm32 being broken due to a NodeJS version bump

Emscripten's SDK [recently bumped the version of NodeJS they shipped](emscripten-core/emsdk#529), but our Dockerfile for the wasm32 builder hardcoded the version number. This will cause consistent CI failures once the currently cached image is rebuilt (either due to a change or due to the cache expiring).

This PR fixes the problem by finding the latest version of NodeJS in the Emscripten SDK and symlinking it to a "latest" directory, which is then added to the `PATH`.
Changes required for rustc/cargo to build for iOS targets

cargo, rustc, clippy, rust-src, and rust-analysis successfully build for `aarch64-apple-ios` with these changes.

NOTE: cargo required arm64-ios openssl/libcurl to be linked.

![image](https://user-images.githubusercontent.com/65794972/86178510-75d78080-baf6-11ea-9c17-b74bd6c85272.png)
![image](https://user-images.githubusercontent.com/65794972/86178525-7bcd6180-baf6-11ea-9974-f99980cbdb24.png)
Optimise fast path of checked_ops with `unlikely`

This PR marks paths returning `None` in checked_ops as unlikely to improvde codegen.

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

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

@bors
Copy link
Contributor

bors commented Jul 2, 2020

📌 Commit 4f536f2 has been approved by Manishearth

@rustbot rustbot added the rollup A PR which is a rollup label Jul 2, 2020
@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 2, 2020
@bors
Copy link
Contributor

bors commented Jul 2, 2020

⌛ Testing commit 4f536f2 with merge 9d992d49d8c27429fd1218c504f67bb43b315b77...

@bors
Copy link
Contributor

bors commented Jul 2, 2020

💔 Test failed - checks-azure

@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 2, 2020
@Manishearth
Copy link
Member Author

@bors retry

more network nonsense

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 2, 2020
@bors
Copy link
Contributor

bors commented Jul 2, 2020

⌛ Testing commit 4f536f2 with merge 8a6d434...

@bors
Copy link
Contributor

bors commented Jul 2, 2020

☀️ Test successful - checks-actions, checks-azure
Approved by: Manishearth
Pushing 8a6d434 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jul 2, 2020
@bors bors merged commit 8a6d434 into rust-lang:master Jul 2, 2020
@Manishearth Manishearth deleted the rollup-8qvh170 branch July 18, 2020 01:14
@cuviper cuviper added this to the 1.46 milestone May 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.