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 6 pull requests #73850

Closed
wants to merge 13 commits into from

Conversation

Dylan-DPC-zz
Copy link

Successful merges:

Failed merges:

r? @ghost

yoshuawuyts and others added 13 commits June 5, 2020 16:37
Use back-ticks instead of quotation marks in docs for the block comment
variant of TokenKind.
…ing_ones, r=Amanieu

stabilize leading_trailing_ones

This PR stabilizes the `leading_trailing_ones` feature. It's been available on nightly since the start of the year, and hasn't had any issues since. It seems unlikely we'll want to change this, so following up on @djc's suggestion in rust-lang#57969 (comment) I'd like to put forward this PR to stabilize the feature and make it part of `1.46.0`. Thanks!

cc/ @djc @rust-lang/libs
…LukasKalbertodt

Remap Windows ERROR_INVALID_PARAMETER to ErrorKind::InvalidInput from Other

I don't know if this is acceptable or how likely it is to break existing code, but it seem to me ERROR_INVALID_PARAMETER "The parameter is incorrect" should map to ErrorKind::InvalidInput "A parameter was incorrect". Previously this value fell through to ErrorKind::Other.

I can't speak for anyone but myself, but I instinctively thought it would be InvalidInput.
…Simulacrum

Remove defunct `-Z print-region-graph`
…thewjasper

Edit cursor.prev() method docs in lexer

Fix missing punctuation
…r=jonas-schievink

Fix markdown rendering in librustc_lexer docs

Use back-ticks instead of quotation marks in docs for the block comment variant of TokenKind.

## [Before](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/enum.TokenKind.html#variant.BlockComment) and after

<img width="1103" alt="Screen Shot 2020-06-28 at 1 22 30 PM" src="https://user-images.githubusercontent.com/19642016/85957562-446a8380-b943-11ea-913a-442cf7744083.png">

<img width="1015" alt="Screen Shot 2020-06-28 at 1 28 29 PM" src="https://user-images.githubusercontent.com/19642016/85957566-4af8fb00-b943-11ea-8fef-a09c1d586772.png">

## Question

For visual consistency, should we use back-ticks throughout the docs for these enum variants?
@Dylan-DPC-zz
Copy link
Author

@bors r+ rollup=never p=6

@bors
Copy link
Contributor

bors commented Jun 28, 2020

📌 Commit 101331e 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 Jun 28, 2020
@ecstatic-morse
Copy link
Contributor

ecstatic-morse commented Jun 28, 2020

@Manishearth I was encouraged by your efforts to move us away from small rollups with only trivial PRs. However, this one represents a return to the status quo. Is there a better way to enforce the rules for rollups?

@Dylan-DPC-zz
Copy link
Author

@ecstatic-morse i'm not sure or aware or such a discussion. We generally prefer smaller rollups as it's easier to bisect later if there's a problem and the queue is small enough

@ecstatic-morse
Copy link
Contributor

ecstatic-morse commented Jun 29, 2020

There's discussion in https://discord.com/channels/442252698964721669/629052535449190400/722335918408597515. All these PRs are either rollup=always or could have easily been marked rollup=always and all of them are tiny fixes except for the stabilization PR, which only needs to land before the beta branch. Point taken about the current size of the queue, but I don't think that 20 line rollups are a good habit.

@Dylan-DPC-zz
Copy link
Author

The queue was small when i rolled up

@Dylan-DPC-zz Dylan-DPC-zz deleted the rollup-bzmz5i9 branch June 29, 2020 00:19
@Manishearth
Copy link
Member

@Dylan-DPC In that case it is better to let harder-to-rollup PRs (#73456 , #73658, #73706) filter through, perhaps by prioritizing them. There is almost zero value to making a rollup PR that is full of "rollup=always or could have easily been marked rollup=always". Those should always piggyback with larger PRs. A good rule of thumb I have is to find 4-8 nontrivial PRs and then sprinkle in some rollup=always ones.

This has been pretty much standard operating procedure for rollups for ages, I'm not really happy to see a shift towards smaller, less substantial rollups. The goal is not to simply get the queue size down, the goal is to get things landed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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.

9 participants