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 8 pull requests #67949

Closed
wants to merge 20 commits into from

Conversation

Dylan-DPC-zz
Copy link

Successful merges:

Failed merges:

r? @ghost

dtolnay and others added 20 commits January 4, 2020 12:35
We see multiple cases inside rustc and ecosystem code where ThreadId is
transmuted to u64, exploiting the underlying detail. This is suboptimal
(can break unexpectedly if we change things in std).

It is unlikely that ThreadId will ever need to be larger than u64 --
creating even 2^32 threads over the course of a program is quite hard,
2^64 is even harder. As such, we do not choose to return a larger sized
type (e.g. u128). If we choose to shrink ThreadId in the future, or
otherwise change its internals, it is likely that a mapping to u64 will
still be applicable (though may become more complex).
…excrichton

Add an unstable conversion from thread ID to u64

We see multiple cases inside rustc and ecosystem code where ThreadId is
transmuted to u64, exploiting the underlying detail. This is suboptimal
(can break unexpectedly if we change things in std).

It is unlikely that ThreadId will ever need to be larger than u64 --
creating even 2^32 threads over the course of a program is quite hard,
2^64 is even harder. As such, we do not choose to return a larger sized
type (e.g. u128). If we choose to shrink ThreadId in the future, or
otherwise change its internals, it is likely that a mapping to u64 will
still be applicable (though may become more complex).

I will file a tracking issue as soon as this is loosely approved.
Omit underscore constants from rustdoc

Underscore constants from rust-lang/rfcs#2526 / rust-lang#54912 do not correspond to a nameable item and so are never useful in documentation.
<br>

#### Before:

> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<img src="https://user-images.githubusercontent.com/1940490/71771409-0427cc80-2eef-11ea-8b7d-d9c74a873e7e.png" width="60%">

#### After:

> Not that.
…r=GuillaumeGomez

rustdoc: HTML escape const values

r? @GuillaumeGomez
Formatting an example for method Vec.retain
fire "non_camel_case_types" for associated types

Fixes rust-lang#67920.
@Dylan-DPC-zz
Copy link
Author

@bors r+ rollup=never p=8

@bors
Copy link
Contributor

bors commented Jan 6, 2020

📌 Commit f725e9f has been approved by Dylan-DPC

@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 Jan 6, 2020
@Dylan-DPC-zz Dylan-DPC-zz added the rollup A PR which is a rollup label Jan 6, 2020
@bors
Copy link
Contributor

bors commented Jan 6, 2020

⌛ Testing commit f725e9f with merge c533d154b2a35e6fe8daecee18f552583b767d3a...

@bors
Copy link
Contributor

bors commented Jan 7, 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 Jan 7, 2020
@Dylan-DPC-zz
Copy link
Author

Looks spurious but superseded by the other rollup

@Dylan-DPC-zz Dylan-DPC-zz deleted the rollup-1fpbwo9 branch January 7, 2020 06:20
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.

10 participants