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 #73668

Closed
wants to merge 35 commits into from

Conversation

Manishearth
Copy link
Member

Successful merges:

Failed merges:

r? @ghost

GuillaumeGomez and others added 30 commits May 30, 2020 15:36
I think it would be nice to mention this, so you don't have to dig through the src to look at the definition of new().
Replaced dummy values for hash and num_counters with computed values,
and refactored InstrumentCoverage pass to simplify injecting more
counters per function in upcoming versions.

Improved usage documentation and error messaging.
This is to prevent the miscompilation in rust-lang#73137 from reappearing.
Only runs with `-Zvalidate-mir`.
It turns out that this has not been working for who knows how long.
Previously:

```
pub fn h() { 1 + 2; }
```

After this change:

```
pub fn h() { loop {} }
```

This only affected the pass when run with the command line
pretty-printing option, so rustdoc was still replacing bodies with
`loop {}`.
This improves the output for issue rust-lang#72577, but there's still more work
to be done.

Currently, an overflow error during monomorphization results in an error
that points at the function we were unable to monomorphize. However, we
don't point at the call that caused the monomorphization to happen. In
the overflow occurs in a large recursive function, it may be difficult
to determine where the issue is.

This commit tracks and `Span` information during collection of
`MonoItem`s, which is used when emitting an overflow error. `MonoItem`
itself is unchanged, so this only affects
`src/librustc_mir/monomorphize/collector.rs`
This commit adds a query that allows the CoverageData to be pulled from
a call on tcx, avoiding the need to change the
`codegen_intrinsic_call()` signature (no need to pass in the FunctionCx
or any additional arguments.

The commit does not change where/when the CoverageData is computed. It's
still done in the `pass`, and saved in the MIR `Body`.

See discussion (in progress) here:
rust-lang#73488 (comment)
The mod uses both MIR bodies and HIR bodies, so I'm trying to maintain
consistency with these names.
Also added FIXME comments to note the possible need to accommodate
counter increment calls in source-based functions that differ from the
function context of the caller instance (e.g., inline functions).
This commit modernizes how rustc checks for whether the `atomics`
feature is enabled for the wasm target. The `sess.target_features` set
is consulted instead of fiddling around with dealing with various
aspects of LLVM and that syntax.
Mention that BTreeMap::new() doesn't allocate

I think it would be nice to mention this, so you don't have to dig through the src to look at the definition of new().
…ir, r=tmandry

Check for assignments between non-conflicting generator saved locals

This is to prevent future changes to the generator transform from reintroducing the problem that caused rust-lang#73137. Namely, a store between two generator saved locals whose storage does not conflict.

My ultimate goal is to introduce a modified version of rust-lang#71956 that handles this case properly.

r? @tmandry
…tmandry

code coverage foundation for hash and num_counters

This PR is the next iteration after PR rust-lang#73011 (which is still waiting on bors to merge).

@wesleywiser - PTAL
r? @tmandry

(FYI, I'm also working on injecting the coverage maps, in another branch, while waiting for these to merge.)

Thanks!
…morse

Fix -Z unpretty=everybody_loops

It turns out that this has not been working for who knows how long.
Previously:

```
pub fn h() { 1 + 2; }
```

After this change:

```
pub fn h() { loop { } }
```

This only affected the pass when run with the command line
pretty-printing option, so rustdoc was still replacing bodies with
`loop {}`.
… r=petrochenkov

Move remaining `NodeId` APIs from `Definitions` to `Resolver`

Implements rust-lang#73291 (comment)

TL;DR: it moves all fields that are only needed during name resolution passes into the `Resolver` and keep the rest in `Definitions`. This effectively enforces that all references to `NodeId`s are gone once HIR lowering is completed.

After this, the only remaining work for rust-lang#50928 should be to adjust the dev guide.

r? @petrochenkov
…err, r=ecstatic-morse

Point at the call span when overflow occurs during monomorphization

This improves the output for issue rust-lang#72577, but there's still more work
to be done.

Currently, an overflow error during monomorphization results in an error
that points at the function we were unable to monomorphize. However, we
don't point at the call that caused the monomorphization to happen. In
the overflow occurs in a large recursive function, it may be difficult
to determine where the issue is.

This commit tracks and `Span` information during collection of
`MonoItem`s, which is used when emitting an overflow error. `MonoItem`
itself is unchanged, so this only affects
`src/librustc_mir/monomorphize/collector.rs`
…ature, r=davidtwco

rustc: Modernize wasm checks for atomics

This commit modernizes how rustc checks for whether the `atomics`
feature is enabled for the wasm target. The `sess.target_features` set
is consulted instead of fiddling around with dealing with various
aspects of LLVM and that syntax.
@bors
Copy link
Contributor

bors commented Jun 24, 2020

☔ The latest upstream changes (presumably #73669) made this pull request unmergeable. Please resolve the merge conflicts.

@bors bors added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Jun 24, 2020
@Manishearth Manishearth deleted the rollup-kc36t0s branch July 18, 2020 01:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author.
Projects
None yet
Development

Successfully merging this pull request may close these issues.