-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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 9 pull requests #71464
Closed
Closed
Rollup of 9 pull requests #71464
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
make Map::def_kind take LocalDefId Co-Authored-By: Vadim Petrochenkov <vadim.petrochenkov@gmail.com> crates are DefKind::Mod
git gdb has moved to version 10. My build prints this as its --version: GNU gdb (GDB) 10.0.50.20200420-git Unfortunately this conflicts with this comment in compiletest: // We limit major to 1 digit, otherwise, on openSUSE, we parse the openSUSE version This patch changes the version parsing to follow the GNU coding standard, which accounts for both the openSUSE case as well as handling gdb 10. My debuginfo test run now says: NOTE: compiletest thinks it is using GDB with native rust support NOTE: compiletest thinks it is using GDB version 10000050 ... where previously it failed to find that gdb 10 had rust support.
The compiletest version-parsing tests failed after the previous patch. However, I don't believe these tests are correct, in that I don't think RHEL or CentOS ever put the gdb version number into parentheses. Instead they display like: GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-119.el7
rustfmt will (apparently) eat raw identifiers inside macros when formatting. This prevents that.
Add all remaining `DefKind`s. r? @eddyb or @Centril ~~I'm not sure if this is what you were thinking of. There are also a few places where I'm not sure what the correct choice is because I don't fully understand the meaning of some variants.~~ ~~In general, it feels a bit odd to add some of these as `DefKind`s (e.g. `Arm`) because they don't feel like definitions. Are there things that it makes sense not to add?~~
… r=cramertj Ignore -Zprofile when building compiler_builtins rust-lang#70846 made the `compiler_builtins` crate ignore the default codegen-units setting and instead always split each function into a different codegen unit. This unfortunately breaks `-Zprofile` which requires a single codegen unit per crate (see rust-lang#71283). You can notice this when building with `cargo -Zbuild-std` and `RUSTFLAGS` containing `-Zprofile`. This PR works around this issue by just ignoring `-Zprofile` for the `compiler-builtins` crate.
…bank Improve E0308 error message wording again Hello again, I recently did this PR: rust-lang#70242 I felt the error message could be further improved, so I made [a post on the Rust community forum](https://users.rust-lang.org/t/looking-for-feedback-on-an-improved-error-message-for-e0308/40004) to ask for feedback. (Also, there were some comments on my original PR that I took into consideration as well.) This PR is my attempt to take all the feedback into account and propose a better and simplified error message that should still be accurate. Its main benefit is having simpler grammar, and hopefully being easier to read and understand. Thanks to everyone who commented and gave feedback, and thank you for taking a look at this PR.
Let compiletest recognize gdb 10.x git gdb has moved to version 10. My build prints this as its --version: GNU gdb (GDB) 10.0.50.20200420-git Unfortunately this conflicts with this comment in compiletest: // We limit major to 1 digit, otherwise, on openSUSE, we parse the openSUSE version This patch changes the version parsing to follow the GNU coding standard, which accounts for both the openSUSE case as well as handling gdb 10. My debuginfo test run now says: NOTE: compiletest thinks it is using GDB with native rust support NOTE: compiletest thinks it is using GDB version 10000050 ... where previously it failed to find that gdb 10 had rust support.
…ark-Simulacrum Shrink GHA configuration This shrinks our GHA configuration by [taking advantage of two new features GitHub just announced](https://github.blog/2020-04-22-github-actions-community-momentum-enterprise-capabilities-and-developer-improvements/): * [Default values for `steps[].shell`](https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions#defaultsrun) * [Being able to include values in a matrix without having to duplicate the job names.](https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions#example-including-new-combinations) The configuration should be functionally equivalent to the previous one. r? @Mark-Simulacrum
…s-schievink Bump bootstrap compiler This bumps the bootstrap compiler and the rustfmt that x.py fmt uses.
Only use read_unaligned in transmute_copy if necessary I've noticed that this causes LLVM to generate poor code on targets that don't support unaligned memory accesses.
…RalfJung Remove outdated reference to interpreter snapshotting This should have been a part of rust-lang#70087. r? @RalfJung
…, r=RalfJung Inline some function docs in `core::ptr` Resolves rust-lang#64539.
@bors r+ p=9 rollup=never |
📌 Commit e20df27 has been approved by |
bors
added
the
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
label
Apr 23, 2020
recreating |
bors
added
S-waiting-on-author
Status: This is awaiting some action (such as code changes or more information) from the author.
and removed
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
labels
Apr 23, 2020
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-author
Status: This is awaiting some action (such as code changes or more information) from the author.
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:
DefKind
s. #70043 (Add all remainingDefKind
s.)core::ptr
#71454 (Inline some function docs incore::ptr
)Failed merges:
r? @ghost