Skip to content

Rollup of 9 pull requests - #73064

Closed
RalfJung wants to merge 23 commits into
rust-lang:masterfrom
RalfJung:rollup-gli87bk
Closed

Rollup of 9 pull requests#73064
RalfJung wants to merge 23 commits into
rust-lang:masterfrom
RalfJung:rollup-gli87bk

Conversation

@RalfJung

Copy link
Copy Markdown
Member

Successful merges:

Failed merges:

r? @ghost

RalfJungand others added 23 commits May 2, 2020 12:13
LLVM 10 includes a009a60 which will
print value numbers for unnamed func args.
Update these tests to be in line with the referenced clang tests.
It isn't clear to me if this is a bug or not, hence the FIXME
Currently, the `Debug` impl for `proc_macro::Span` just prints out
the byte range. This can make debugging proc macros (either as a crate
author or as a compiler developer) very frustrating, since neither the
actual filename nor the `SyntaxContext` is displayed.
This commit adds a perma-unstable flag `-Z span-debug`. When enabled,
the `Debug` impl for `proc_macro::Span` simply forwards directly to
`rustc_span::Span`. Once rust-lang#72618 is merged, this will start displaying
actual line numbers.
While `Debug` impls are not subject to Rust's normal stability
guarnatees, we probably shouldn't expose any additional information on
stable until `#![feature(proc_macro_span)]` is stabilized. Otherwise,
we would be providing a 'backdoor' way to access information that's
supposed be behind unstable APIs.
de-promote Duration::from_secs
In rust-lang#67531, we removed the `rustc_promotable` attribute from a bunch of `Duration` methods, but not from `Duration::from_secs`. This makes the current list of promotable functions the following (courtesy of @ecstatic-morse):
* `INT::min_value`, `INT::max_value`
* `std::mem::size_of`, `std::mem::align_of`
* `RangeInclusive::new` (backing `x..=y`)
* `std::ptr::null`, `std::ptr::null_mut`
* `RawWaker::new`, `RawWakerVTable::new` ???
* `Duration::from_secs`
I feel like the last one stands out a bit here -- the rest are all very core language primitives, and `RawWaker` has a strong motivation for getting a `'static` vtable. But a `&'static Duration`? That seems unlikely. So I propose we no longer promote calls to `Duration::from_secs`, which is what this PR does.
rust-lang#67531 saw zero regressions and I am not aware of anyone complaining that this broke their (non-cratered) code, so I consider it likely the same will be true here, but of course we'd do a crater run.
See [this document](https://github.com/rust-lang/const-eval/blob/master/promotion.md) for some more background on promotion and rust-lang/const-eval#19 for some of the concerns around promoting function calls.
…matsakis
Make `PolyTraitRef::self_ty` return `Binder<Ty>`
This came up during review of rust-lang#71618. The current implementation is the same as a call to `skip_binder` but harder to audit. Make it preserve binding levels and add a call to `skip_binder` at all use sites so they can be audited as part of rust-lang#72507.
linker: Add a linker rerun hack for gcc versions not supporting -static-pie
Which mirrors the existing `-no-pie` linker rerun hack, but the logic is a bit more elaborated in this case.
If the linker (gcc or clang) errors on `-static-pie` we rerun in with `-static` instead.
We must also replace CRT objects corresponding to `-static-pie` with ones corresponding to `-static` in this case.
(One sanity check for CRT objects in target specs is also added as a drive-by fix.)
To do in the future: refactor all linker rerun hacks into separate functions and share more code with `add_(pre,post)_link_objects`.
This PR accompanies rust-lang#71804 and unblocks rust-lang#70740.
…stebank
Be more careful around ty::Error in generators
cc rust-lang#72685
(doesn't close it because it's missing a reproduction to use as a test case)
r? @estebank
…rochenkov
Add `-Z span-debug` to allow for easier debugging of proc macros
Currently, the `Debug` impl for `proc_macro::Span` just prints out
the byte range. This can make debugging proc macros (either as a crate
author or as a compiler developer) very frustrating, since neither the
actual filename nor the `SyntaxContext` is displayed.
This commit adds a perma-unstable flag `-Z span-debug`. When enabled,
the `Debug` impl for `proc_macro::Span` simply forwards directly to
`rustc_span::Span`. Once rust-lang#72618 is merged, this will start displaying
actual line numbers.
While `Debug` impls are not subject to Rust's normal stability
guarnatees, we probably shouldn't expose any additional information on
stable until `#![feature(proc_macro_span)]` is stabilized. Otherwise,
we would be providing a 'backdoor' way to access information that's
supposed be behind unstable APIs.
…70924, r=nikomatsakis
run-make regression test for issue rust-lang#70924.
Sometime after my PR rust-lang#72767 (to fix issue rust-lang#70924) landed, I realized that I *could* make a local regression test, thanks to `rustc --print sysroot`: I can make a fresh "copy" (really mostly symlinks) of the sysroot, and then modify it to recreate the terms of this bug.
…atsakis
Fix codegen tests for RISC-V
Some codegen tests didn't seem relevant (e.g. unsupported annotations).
The RISC-V abi tests were broken by LLVM 10, c872dcf fixes that (cc: @msizanoen1)
I'm not sure about skipping catch-unwind.rs and included that change here mostly as a request for comment - I can't tell if that's a bug.
…u16, r=sfackler
impl ToSocketAddrs for (String, u16)
This adds a convenience impl of `ToSocketAddrs for (String, u16)`. When authoring HTTP services it's common to take command line options for `host` and `port` and parse them into `String` and `u16` respectively. Consider the following program:
```rust
#[derive(Debug, StructOpt)]
struct Config {
host: String,
port: u16,
}
async fn main() -> io::Result<()> {
let config = Config::from_args();
let stream = TcpStream::connect((&*config.host, config.port))?; // &* is not ideal
// ...
}
```
Networking is a pretty common starting point for people new to Rust, and seeing `&*` in basic examples can be confusing. Even as someone that has experience with networking in Rust I tend to forget that `String` can't be passed directly there. Instead with this patch we can omit the `&*` conversion and pass `host` directly:
```rust
#[derive(Debug, StructOpt)]
struct Config {
host: String,
port: u16,
}
async fn main() -> io::Result<()> {
let config = Config::from_args();
let stream = TcpStream::connect((config.host, config.port))?; // no more conversions!
// ...
}
```
I think should be an easy and small ergonomics improvement for networking. Thanks!
@RalfJung

Copy link
Copy Markdown
MemberAuthor

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

@bors

bors commented Jun 6, 2020

Copy link
Copy Markdown
Collaborator

📌 Commit 5c3bc43 has been approved by RalfJung

@rustbotrustbot added the rollup A PR which is a rollup label Jun 6, 2020
@borsbors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Jun 6, 2020
@bors

bors commented Jun 6, 2020

Copy link
Copy Markdown
Collaborator

⌛ Testing commit 5c3bc43 with merge 595f91a5c15e6aac6144c898f845874295716790...

@bors

bors commented Jun 6, 2020

Copy link
Copy Markdown
Collaborator

💔 Test failed - checks-azure

@borsbors 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 Jun 6, 2020
@RalfJung

Copy link
Copy Markdown
MemberAuthor

What the, it's the same failure again?!???

@RalfJungRalfJung closed this Jun 6, 2020
@RalfJung
RalfJung deleted the rollup-gli87bk branch June 6, 2020 19:59
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

rollupA PR which is a rollupS-waiting-on-reviewStatus: Awaiting review from the assignee but also interested parties.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

11 participants

@RalfJung@bors@rustbot@petrochenkov@jonas-schievink@ecstatic-morse@tblah@pnkfelix@Aaron1011@yoshuawuyts@lcnr