Rollup of 9 pull requests #70132
Merged
Rollup of 9 pull requests #70132
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This didn't cause issues before since generator types were always considered to "need drop", leading to unwind paths (including a `Resume` block) always getting generated.
The indices do not matter here, and this fixes an index out of bounds panic when compiling a generator that can unwind but not return.
Co-Authored-By: bjorn3 <bjorn3@users.noreply.github.com>
Removed in rust-lang#69247 while this PR was waiting to merge.
This mitigates possible issues when signal stacks overflow, which could manifest as segfaults or in unlucky circumstances possible clobbering of other memory values as stack overflows tend to enable.
…ther also unmap the whole thing when cleaning up, rather than leaving a spare page floating around.
This commit fixes an issue when using `set_print` and friends, notably used by libtest, to avoid aborting the process if printing panics. This previously panicked due to borrowing a mutable `RefCell` twice, and this is worked around by borrowing these cells for less time, instead taking out and removing contents temporarily. Closes rust-lang#69558
Previously, metadata encoding used DUMMY_SP to represent any spans that referenced an 'imported' SourceFile - e.g. a SourceFile from an upstream dependency. These leads to sub-optimal error messages in certain cases (see the included test). This PR changes how we encode and decode spans in crate metadata. We encode spans in one of two ways: * 'Local' spans, which reference non-imported SourceFiles, are encoded exactly as before. * 'Foreign' spans, which reference imported SourceFiles, are encoded with the CrateNum of their 'originating' crate. Additionally, their 'lo' and 'high' values are rebased on top of the 'originating' crate, which allows them to be used with the SourceMap data encoded for that crate. The `ExternalSource` enum is renamed to `ExternalSourceKind`. There is now a struct called `ExternalSource`, which holds an `ExternalSourceKind` along with the original line number information for the file. This is used during `Span` serialization to rebase spans onto their 'owning' crate.
…ochenkov Properly handle Spans that reference imported SourceFiles Previously, metadata encoding used DUMMY_SP to represent any spans that referenced an 'imported' SourceFile - e.g. a SourceFile from an upstream dependency. This currently has no visible consequences, since these kinds of spans don't currently seem to be emitted anywhere. However, there's no reason that we couldn't start using such spans in diagnostics. This PR changes how we encode and decode spans in crate metadata. We encode spans in one of two ways: * 'Local' spans, which reference non-imported SourceFiles, are encoded exactly as before. * 'Foreign' spans, which reference imported SourceFiles, are encoded with the CrateNum of their 'originating' crate. Additionally, their 'lo' and 'high' values are rebased on top of the 'originating' crate, which allows them to be used with the SourceMap data encoded for that crate. To support this change, I've also made the following modifications: * `DefId` and related structs are now moved to `rustc_span`. This allows us to use a `CrateNum` inside `SourceFile`. `CrateNum` has special handling during deserialization (it gets remapped to be the proper `CrateNum` from the point of view of the current compilation session), so using a `CrateNum` instead of a plain integer 'workaround type' helps to simplify deserialization. * The `ExternalSource` enum is renamed to `ExternalSourceKind`. There is now a struct called `ExternalSource`, which holds an `ExternalSourceKind` along with the original line number information for the file. This is used during `Span` serialization to rebase spans onto their 'owning' crate.
rustc: don't resolve Instances which would produce malformed shims. There are some `InstanceDef` variants (shims and drop "glue") which contain a `Ty`, and that `Ty` is used in generating the shim MIR. But if that `Ty` mentions any generic parameters, the generated shim would refer to them (but they won't match the `Substs` of the `Instance`), or worse, generating the shim would fail because not enough of the type is known. Ideally we would always produce a "skeleton" of the type, e.g. `(_, _)` for dropping any tuples with two elements, or `Vec<_>` for dropping any `Vec` value, but that's a lot of work, and they would still not match the `Substs` of the `Instance` as it exists today, so `Instance` would probably need to change. By making `Instance::resolve` return `None` in the still-generic cases, we get behavior similar to specialization, where a default can only be used if there are no more generic parameters which would allow a more specialized `impl` to match. <hr/> This was found while testing the MIR inliner with rust-lang#68965, because it was trying to inline shims. cc @rust-lang/wg-mir-opt
…mulacrum tidy: Better license checks. This implements some improvements to the license checks in tidy: * Use `cargo_metadata` instead of parsing vendored crates. This allows license checks to run without vendoring enabled, and allows the checks to run on PR builds. * Check for stale entries. * Check that the licenses for exceptions are what we think they are. * Verify exceptions do not leak into the runtime. Closes rust-lang#62618 Closes rust-lang#62619 Closes rust-lang#63238 (I think) There are some substantive changes here. The follow licenses have changed from the original comments: * openssl BSD+advertising clause to Apache-2.0 * pest MPL2 to MIT/Apache-2.0 * smallvec MPL2 to MIT/Apache-2.0 * clippy lints MPL2 to MIT OR Apache-2.0
Smaller and more correct generator codegen This removes unnecessary panicking branches in the resume function when the generator can not return or unwind, respectively. Closes rust-lang#66100 It also addresses the correctness concerns wrt poisoning on unwind. These are not currently a soundness issue because any operation *inside* a generator that could possibly unwind will result in a cleanup path for dropping it, ultimately reaching a `Resume` terminator, which we already handled correctly. Future MIR optimizations might optimize that out, though. r? @Zoxc
…lacrum Regenerate tables for Unicode 13.0.0
…Mark-Simulacrum std: Don't abort process when printing panics in tests This commit fixes an issue when using `set_print` and friends, notably used by libtest, to avoid aborting the process if printing panics. This previously panicked due to borrowing a mutable `RefCell` twice, and this is worked around by borrowing these cells for less time, instead taking out and removing contents temporarily. Closes rust-lang#69558
unix: Set a guard page at the end of signal stacks This mitigates possible issues when signal stacks overflow, which could manifest as segfaults or in unlucky circumstances possible clobbering of other memory values as stack overflows tend to enable. I went ahead and made a PR for this because it's a pretty small change, though if I should open an issue/RFC for this and discuss there first I'll happily do so. I've also added some example programs that demonstrate the uncomfortably clobber-happy behavior we currently have, and the segfaults that could/should result instead, [here](https://github.com/iximeow/jubilant-train).
…kinnison [rustdoc] Improve visibility for code blocks warnings It appeared that a lot of people didn't notice when a code block was meant to fail compilation or wasn't tested at all. The changes here make the colors less transparent and the icon bigger. So before it looked like this:   And now it looks like this:   cc @rust-lang/rustdoc r? @kinnison
Use copy bound in atomic operations to generate simpler MIR
|
@bors r+ p=9 rollup=never |
|
📌 Commit 605bb61 has been approved by |
|
🌲 The tree is currently closed for pull requests below priority 5, this pull request will be tested once the tree is reopened |
bors
added
the
S-waiting-on-bors
|
☀️ Test successful - checks-azure |
This was referenced Mar 19, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
Failed merges:
r? @ghost