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

Closed
wants to merge 34 commits into from

Conversation

Manishearth
Copy link
Member

Successful merges:

Failed merges:

r? @ghost

JamieCunliffe and others added 30 commits June 30, 2020 09:58
Implement the va args in codegen for AAPCS, this will be used as the
default va_args implementation for AArch64 rather than the va_args
llvm-ir as it currently is.

Copyright (c) 2020, Arm Limited.
This makes extract_lldb_version has the same version type like
extract_gdb_version.

This is technically a breaking change for rustc-dev users.
But note that rustc-dev is a nightly component.
Also the alignment should only be done on general register types as
per the AAPCS so fixed that issue.

Copyright (c) 2020, Arm Limited.
…ers to functions

This patch extends the existing `type_i8p` method so that it requires an
explicit address space to be specified. Before this patch, the
`type_i8p` method implcitily assumed the default address space, which is
not a safe transformation on all targets, namely AVR.

The Rust compiler already has support for tracking the "instruction
address space" on a per-target basis. This patch extends the code
generation routines so that an address space must always be specified.

In my estimation, around 15% of the callers of `type_i8p` produced
invalid code on AVR due to the loss of address space prior to LLVM final
code generation. This would lead to unavoidable assertion errors
relating to invalid bitcasts.

With this patch, the address space is always either 1) explicitly set to
the instruction address space because the logic is dealing with functions
which must be placed there, or 2) explicitly set to the default address
space 0 because the logic can only operate on data space pointers and thus
we keep the existing semantics of assuming the default, "data" address space.
…tated with the correct space

Before this patch, a function pointer stored within an aggregate like a
struct or an enum would always have the default address space `0`.

This patch removes this assumption and instead, introspects the inner
type being pointed at, storing the target address space in the PointeeInfo
struct so that downstream users may query it.
…e, r=nagisa

[AVR] Correctly set the pointer address space when constructing pointers to functions

NOTE: Pull request iterations:

* https://github.com/dylanmckay/rust/releases/tag/avr-use-correct-addrspace.0
* https://github.com/dylanmckay/rust/releases/tag/avr-use-correct-addrspace.1
* https://github.com/dylanmckay/rust/releases/tag/avr-use-correct-addrspace.2

This patch extends the existing `type_i8p` method so that it requires an
explicit address space to be specified. Before this patch, the
`type_i8p` method implcitily assumed the default address space, which is
not a safe transformation on all targets, namely AVR.

The Rust compiler already has support for tracking the "instruction
address space" on a per-target basis. This patch extends the code
generation routines so that an address space must always be specified.

In my estimation, around 15% of the callers of `type_i8p` produced
invalid code on AVR due to the loss of address space prior to LLVM final
code generation. This would lead to unavoidable assertion errors
relating to invalid bitcasts.

With this patch, the address space is always either 1) explicitly preserved
from the input type, or 2) explicitly set to the instruction address
space because the logic is dealing with functions which must be placed
there, or 3) explicitly set to the default address space 0 because the
logic can only operate on data space pointers and thus we keep the
existing semantics of assuming the default, "data" address space.
va_args implementation for AAPCS.

Implement the va args in codegen for AAPCS, this will be used as the
default va_args implementation for AArch64 rather than the va_args
llvm-ir as it currently is.

This should fix the following issues:
rust-lang#56475
rust-lang#72579
…atsakis

Stabilize control-flow-guard codegen option

This is the stabilization PR discussed in rust-lang#68793. It converts the `-Z control-flow-guard` debugging option into a codegen option (`-C control-flow-guard`), and changes the associated tests.
compiletest: Rewrite extract_*_version functions

This makes extract_lldb_version has the same version type like
extract_gdb_version.
Guard against non-monomorphized type_id intrinsic call

This PR checks whether the type is sufficient monomorphized when calling type_id or type_name intrinsics. If the type is not sufficiently monomorphized, e.g. used in a pattern, the code will be rejected.

Fixes rust-lang#73976
Apply rust-lang#66379 to `*mut T` `as_ref`

rust-lang#66379 changed the documentation of `as_ref` on the type `*const T` and `as_mut` on the type `*mut T`, but it missed making that same change for `as_ref` on the type `*mut T`.
…dures-links, r=Mark-Simulacrum

Use forge links for prioritization procedure

r? @Mark-Simulacrum

cc @rust-lang/wg-prioritization
Update books

## reference

5 commits in 0ea7bc494f1289234d8800bb9185021e0ad946f0..b329ce37424874ad4db94f829a55807c6e21d2cb
2020-07-02 15:33:04 -0700 to 2020-07-20 08:54:08 -0700
- this '*' is unnecessary, and reduces readability (rust-lang/reference#853)
- Tiny typo fix (rust-lang/reference#849)
- Update const eval chapter to latest changes (rust-lang/reference#842)
- Document #[track_caller]. (rust-lang/reference#742)
- Document shebang restriction. (rust-lang/reference#823)

## book

2 commits in 84a31397b34f9d405df44f2899ff17a4828dba18..a914f2c7e5cdb771fa465de142381a51c53b580e
2020-07-04 10:50:18 -0500 to 2020-07-21 09:20:05 -0500
- Change misleading wording (rust-lang/book#2399)
- Improve wording to include Windows versions (rust-lang/book#2395)

## edition-guide

3 commits in 82bec5877c77cfad530ca11095db4456d757f668..bd6e4a9f59c5c1545f572266af77f5c7a5bad6d1
2020-06-03 08:56:02 -0500 to 2020-07-12 17:37:08 -0500
- update guide for 1.36 and 1.37 (rust-lang/edition-guide#217)
- Add contents for Rust 1.35 (rust-lang/edition-guide#216)
- update edition guide for Rust 1.34 (rust-lang/edition-guide#215)
@Manishearth
Copy link
Member Author

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

@bors
Copy link
Contributor

bors commented Jul 22, 2020

📌 Commit 5871ff4 has been approved by Manishearth

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

bors commented Jul 22, 2020

⌛ Testing commit 5871ff4 with merge 9b76013886e4ba45dab2e38539c055c34c2f1bde...

@bors
Copy link
Contributor

bors commented Jul 22, 2020

💔 Test failed - checks-azure

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jul 22, 2020
@Manishearth
Copy link
Member Author

@bors retry

network

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 22, 2020
@bors
Copy link
Contributor

bors commented Jul 22, 2020

⌛ Testing commit 5871ff4 with merge af7dadb7d1736a6feb21ffd6595902db52e1d40c...

@bors
Copy link
Contributor

bors commented Jul 22, 2020

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jul 22, 2020
@Manishearth
Copy link
Member Author

More zlib stream issues. Gonna remake the rollup once the azure pipelines PR lands

@bors
Copy link
Contributor

bors commented Jul 24, 2020

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

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-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.