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 9 pull requests #71464

Closed
wants to merge 26 commits into from
Closed

Conversation

JohnTitor
Copy link
Member

Successful merges:

Failed merges:

r? @ghost

mark-i-m and others added 26 commits April 19, 2020 16:49
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.
@JohnTitor
Copy link
Member Author

@bors r+ p=9 rollup=never

@bors
Copy link
Contributor

bors commented Apr 23, 2020

📌 Commit e20df27 has been approved by JohnTitor

@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 Apr 23, 2020
@JohnTitor JohnTitor added the rollup A PR which is a rollup label Apr 23, 2020
@Dylan-DPC-zz
Copy link

recreating

@Mark-Simulacrum
Copy link
Member

@bors r-

I corrected #71439 which is contained in this so please recreate.

@bors 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
@JohnTitor JohnTitor deleted the rollup-esd9vjy branch April 23, 2020 14:02
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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.