Skip to content

Rollup of 7 pull requests #59694

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
wants to merge 19 commits into from
Closed

Conversation

Centril
Copy link
Contributor

@Centril Centril commented Apr 4, 2019

Successful merges:

Failed merges:

r? @ghost

czipperz and others added 19 commits March 27, 2019 16:37
Before this change, formatter settings were lost when printing a
`Range`. For example, printing a `Range<f32>` with `{:.2?}` would not
apply the precision modifier when printing the floats. Now the `Debug`
impls look a bit more verbose, but modifier are not lost.
Functions with uninhabited return values are already marked `noreturn`,
but we were still generating return instructions for this. When running
with `-C passes=lint`, LLVM prints:

    Unusual: Return statement in function with noreturn attribute

The LLVM manual makes a stronger statement about `noreturn` though:

> This produces undefined behavior at runtime if the function ever does
dynamically return.

We now emit an `abort` anywhere that would have tried to return an
uninhabited value.
…dtolnay

Document std::fs::File close behavior ignoring errors

Resolves rust-lang#52685
…mundi

Forward formatter settings to bounds of `Range<T>` in `fmt::Debug` impl

Before this change, formatter settings were lost when printing a `Range`. For example, printing a `Range<f32>` with `{:.2?}` would not apply the precision modifier when printing the floats. Now the `Debug` impls look a bit more verbose, but modifier are not lost.

---

I assume the exact output of `Debug` impls in `std` cannot be relied on by users and thus can change, right?
Never return uninhabited values at all

Functions with uninhabited return values are already marked `noreturn`,
but we were still generating return instructions for this. When running
with `-C passes=lint`, LLVM prints:

    Unusual: Return statement in function with noreturn attribute

The LLVM manual makes a stronger statement about `noreturn` though:

> This produces undefined behavior at runtime if the function ever does
dynamically return.

We now emit an `abort` anywhere that would have tried to return an
uninhabited value.

Fixes rust-lang#48227
cc rust-lang#7463 rust-lang#48229

r? @eddyb
Add description for -Os and -Oz in rustc.1
… r=luqmana

Temporarily disable stack probing for gnux32.
@Centril
Copy link
Contributor Author

Centril commented Apr 4, 2019

@bors r+ p=7

@bors
Copy link
Collaborator

bors commented Apr 4, 2019

📌 Commit 6ed6820 has been approved by Centril

@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 4, 2019
@Centril
Copy link
Contributor Author

Centril commented Apr 4, 2019

Added #59671.

@Centril Centril closed this Apr 4, 2019
@Centril Centril deleted the rollup-5u8su4s branch April 4, 2019 13:09
@Centril Centril added the rollup A PR which is a rollup label Oct 24, 2019
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants