Skip to content

Rollup of 8 pull requests #59695

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

Merged
merged 22 commits into from
Apr 4, 2019
Merged

Rollup of 8 pull requests #59695

merged 22 commits into from
Apr 4, 2019

Conversation

Centril
Copy link
Contributor

@Centril Centril commented Apr 4, 2019

Successful merges:

Failed merges:

r? @ghost

czipperz and others added 22 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
Make some of lexer's API private

Lexer is a `pub` type, so it feels wrong that its fields are just pub (I guess it wasn't exported initially), so let's minimize visibility.

Context: I am looking into extracting rust-lexer into a library, which can be shared by rust-analyzer and rustc. I hope that a simple interface like `fn next_token(src: &str) -> (TokenKind, usize)` would work, but to try this out I need to understand what is the current API of the lexer.
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=8

@bors
Copy link
Collaborator

bors commented Apr 4, 2019

📌 Commit 31c2f5d 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
bors added a commit that referenced this pull request Apr 4, 2019
Rollup of 8 pull requests

Successful merges:

 - #59470 (Document std::fs::File close behavior ignoring errors)
 - #59555 (update miri)
 - #59556 (update stdsimd)
 - #59596 (Forward formatter settings to bounds of `Range<T>` in `fmt::Debug` impl)
 - #59639 (Never return uninhabited values at all)
 - #59671 (Make some of lexer's API private)
 - #59685 (Add description for -Os and -Oz in rustc.1)
 - #59686 (Temporarily disable stack probing for gnux32.)

Failed merges:

r? @ghost
@bors
Copy link
Collaborator

bors commented Apr 4, 2019

⌛ Testing commit 31c2f5d with merge 52980d0...

@bors
Copy link
Collaborator

bors commented Apr 4, 2019

☀️ Test successful - checks-travis, status-appveyor
Approved by: Centril
Pushing 52980d0 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Apr 4, 2019
@bors bors merged commit 31c2f5d into rust-lang:master Apr 4, 2019
@rust-highfive
Copy link
Contributor

📣 Toolstate changed by #59695!

Tested on commit 52980d0.
Direct link to PR: #59695

🎉 miri on windows: build-fail → test-pass (cc @oli-obk @RalfJung @eddyb, @rust-lang/infra).
🎉 miri on linux: build-fail → test-pass (cc @oli-obk @RalfJung @eddyb, @rust-lang/infra).

rust-highfive added a commit to rust-lang-nursery/rust-toolstate that referenced this pull request Apr 4, 2019
Tested on commit rust-lang/rust@52980d0.
Direct link to PR: <rust-lang/rust#59695>

🎉 miri on windows: build-fail → test-pass (cc @oli-obk @RalfJung @eddyb, @rust-lang/infra).
🎉 miri on linux: build-fail → test-pass (cc @oli-obk @RalfJung @eddyb, @rust-lang/infra).
@Centril Centril deleted the rollup-88qffc2 branch April 4, 2019 19:04
@Centril Centril added the rollup A PR which is a rollup label Oct 2, 2019
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
merged-by-bors This PR was explicitly merged by bors. 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.

10 participants