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

Merged
merged 26 commits into from
Aug 16, 2020
Merged

Rollup of 10 pull requests #75609

merged 26 commits into from
Aug 16, 2020

Conversation

tmandry
Copy link
Member

@tmandry tmandry commented Aug 16, 2020

Successful merges:

Failed merges:

r? @ghost

ayazhafiz and others added 26 commits July 9, 2020 19:21
Previously the existence of bodies inside a foreign function block would
cause a panic in the hir `NodeCollector` during its collection of crate
bodies to compute a crate hash:

https://github.com/rust-lang/rust/blob/e59b08e62ea691916d2f063cac5aab4634128022/src/librustc_middle/hir/map/collector.rs#L154-L158

The collector walks the hir tree and creates a map of hir nodes, then
attaching bodies in the crate to their owner in the map. For a code like

```rust
extern "C" {
    fn f() {
        fn g() {}
    }
}
```

The crate bodies include the body of the function `g`. But foreign
functions cannot have bodies, and while the parser AST permits a foreign
function to have a body, the hir doesn't. This means that the body of
`f` is not present in the hir, and so neither is `g`. So when the
`NodeCollector` finishes the walking the hir, it has no record of `g`,
cannot find an owner for the body of `g` it sees in the crate bodies,
and blows up.

Why do the crate bodies include the body of `g`? The AST walker has a
need a for walking function bodies, and FFIs share the same AST node as
functions in other contexts.

There are at least two options to fix this:

- Don't unwrap the map entry for an hir node in the `NodeCollector`
- Modifier the ast->hir lowering visitor to ignore foreign function
  blocks

I don't think the first is preferrable, since we want to know when we
can't find a body for an hir node that we thought had one (dropping this
information may lead to an invalid hash). So this commit implements the
second option.

Closes rust-lang#74120
This forwards the caller span to `Handler::delay_span_bug`
Co-authored-by: Joshua Nelson <joshua@yottadb.com>
Release Notes:

```
v1.38.47: 10/02/2019
--------------------
 - Add support for FETCH API in WASM backend. This doesn't support FETCH in the
   main thread (`USE_FETCH_WORKER=0` is enforced). rust-lang#9490
 - Redefine errno values to be consistent with wasi. This will let us avoid
   needing to convert the values back and forth as we use more wasi APIs.
   This is an ABI change, which should not be noticeable from user code
   unless you use errno defines (like EAGAIN) *and* keep around binaries
   compiled with an older version that you link against. In that case, you
   should rebuild them. See rust-lang#9545.
 - Removed build option `-s ONLY_MY_CODE` as we now have much better solutions
   for that, like building to a wasm object file or using `STANDALONE_WASM`
   etc. (see
   https://github.com/emscripten-core/emscripten/wiki/WebAssembly-Standalone).
 - Emscripten now supports the config file (.emscripten) being placed in the
   emscripten directory rather that the current user's home directory.
   See rust-lang#9543
```
Don't visit foreign function bodies when lowering ast to hir

Previously the existence of bodies inside a foreign function block would
cause a panic in the hir `NodeCollector` during its collection of crate
bodies to compute a crate hash:

https://github.com/rust-lang/rust/blob/e59b08e62ea691916d2f063cac5aab4634128022/src/librustc_middle/hir/map/collector.rs#L154-L158

The collector walks the hir tree and creates a map of hir nodes, then
attaching bodies in the crate to their owner in the map. For a code like

```rust
extern "C" {
    fn f() {
        fn g() {}
    }
}
```

The crate bodies include the body of the function `g`. But foreign
functions cannot have bodies, and while the parser AST permits a foreign
function to have a body, the hir doesn't. This means that the body of
`f` is not present in the hir, and so neither is `g`. So when the
`NodeCollector` finishes the walking the hir, it has no record of `g`,
cannot find an owner for the body of `g` it sees in the crate bodies,
and blows up.

Why do the crate bodies include the body of `g`? The AST walker has a
need a for walking function bodies, and FFIs share the same AST node as
functions in other contexts.

There are at least two options to fix this:

- Don't unwrap the map entry for an hir node in the `NodeCollector`
- Modifier the ast->hir lowering visitor to ignore foreign function
  blocks

I don't think the first is preferrable, since we want to know when we
can't find a body for an hir node that we thought had one (dropping this
information may lead to an invalid hash). So this commit implements the
second option.

Closes rust-lang#74120
…matsakis

rustc_typeck: construct {Closure,Generator}Substs more directly.

We've previously not had a way to create `{Closure,Generator}Substs` other than instantiating all generics as inference variables and unifying the inference types (extracted using the regular `{Closure,Generator}Substs` accessors), with the actual types.

With this PR, those hacks, and assumptions about the order of closure/generator-specific components, are replaced with a simple API where the base `Substs` are combined with the additional information into a `{Closure,Generator}Substs`.
This might also be faster than relying inference, although probably not by much.

r? @nikomatsakis cc rust-lang#53488 @blitzerr
Use LocalDefId instead of HirId for reachable_set elements.

The only `HirId`s being tracked there that don't have matching `DefId`s are local variables, and that's an accident from rust-lang#44316 (where I preserved the old behavior, even if nothing relied on reachability tracking local variables).
Move DelaySpanBugEmitted to ty::context

This makes it even hard to abuse.

r? @eddyb

cc @LeSeulArtichaut as this will probably conflict with your PR :/
Add regression test for issue-66768

Fixes rust-lang#66768

This is fixed by rust-lang#70452 (in particular, https://github.com/rust-lang/rust/pull/70452/files#diff-53aef089a36a8e2ed07627fc8915fe63R1763) and I'm not sure it's worth to add this test (i.e. the tests in rust-lang#70452 are enough), so r? @eddyb to confirm it.
…ler, r=eddyb

Add #[track_caller] to `Session::delay_span_bug`

This forwards the caller span to `Handler::delay_span_bug`
…int, r=dtolnay

Move to intra-doc links for /library/core/src/hint.rs

Helps with rust-lang#75080.

@rustbot modify labels: T-doc, A-intra-doc-links, T-rustdoc
pin docs: add some forward references

@nagisa had some questions about pinning that were answered in the docs, which they did not realize because that discussion is below the examples. I still think it makes sense to introduce the examples before that discussion, since it give the discussion something concrete to refer to, but this PR adds some forward references so people don't think the examples conclude the docs.

@nagisa do you think this would have helped?
Bump minor version of emsdk to 1.38.47

Release Notes:

```
v1.38.47: 10/02/2019
--------------------
 - Add support for FETCH API in WASM backend. This doesn't support FETCH in the
   main thread (`USE_FETCH_WORKER=0` is enforced). rust-lang#9490
 - Redefine errno values to be consistent with wasi. This will let us avoid
   needing to convert the values back and forth as we use more wasi APIs.
   This is an ABI change, which should not be noticeable from user code
   unless you use errno defines (like EAGAIN) *and* keep around binaries
   compiled with an older version that you link against. In that case, you
   should rebuild them. See rust-lang#9545.
 - Removed build option `-s ONLY_MY_CODE` as we now have much better solutions
   for that, like building to a wasm object file or using `STANDALONE_WASM`
   etc. (see
   https://github.com/emscripten-core/emscripten/wiki/WebAssembly-Standalone).
 - Emscripten now supports the config file (.emscripten) being placed in the
   emscripten directory rather that the current user's home directory.
   See rust-lang#9543
```

Motivated by changes to errno values which are currently out of sync with those
in libc crate which uses wasi values already. Helps with rust-lang#72808 and rust-lang#75532.
Switch to intra-doc links in /sys/windows/ext/{ffi,fs,process}.rs

Partial fix for rust-lang#75080

@rustbot modify labels: T-doc, A-intra-doc-links, T-rustdoc

r? @jyn514
@tmandry
Copy link
Member Author

tmandry commented Aug 16, 2020

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

@bors
Copy link
Contributor

bors commented Aug 16, 2020

📌 Commit e46b1ef has been approved by tmandry

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

bors commented Aug 16, 2020

⌛ Testing commit e46b1ef with merge 7e6d6e5...

@bors
Copy link
Contributor

bors commented Aug 16, 2020

☀️ Test successful - checks-actions, checks-azure
Approved by: tmandry
Pushing 7e6d6e5 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Aug 16, 2020
@bors bors merged commit 7e6d6e5 into rust-lang:master Aug 16, 2020
@cuviper cuviper added this to the 1.47.0 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.