-
Notifications
You must be signed in to change notification settings - Fork 13k
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 #65196
Merged
Merged
Rollup of 8 pull requests #65196
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
To make `new` method appear first in documentation.
Change-Id: I0c5c4d767be2647e6f017ae7bf83558c56dbca97
Change-Id: I0c5c4d767be2647e6f017ae7bf83558c56dbca97
Change-Id: I0c5c4d767be2647e6f017ae7bf83558c56dbca97
generics arguments.
Didn't find any bugs here, but you really don't want these to fall out of sync.
Existing code could overlook types/substitutions that are embedded in (e.g.) an unevaluated constant.
In such a case, the `Infer` is converted to a `Bound`
Also, make `-Zverbose` dump all info about constants.
…uppe rewrite documentation for unimplemented! to clarify use The current docs for `unimplemented!` seem to miss the point of this macro. > This can be useful if you are prototyping and are just looking to have your code type-check, or if you're implementing a trait that requires multiple methods, and you're only planning on using one of them. You could also return a `()` if you just want your code to type-check. I think `unimplemented!` is useful for when you want your program to exit when it reaches an unimplemented area. I rewrote the explanation and gave examples of both forms of this macro that I think clarify its use a little better.
syntax: more cleanups in item and function signature parsing Follow up to rust-lang#64910. Best read commit-by-commit. r? @estebank
Make `Cell::new` method come first in documentation Methods to create a thing usually comes first in `std` documentation, and `Cell` has been an exception. Also, `T: Copy` specialized methods should not be on top of the page. (This had led me to miss that most of its methods are not bounded by `Copy`...)
…-E0561, r=Centril Add long error explanation for E0561 Part of rust-lang#61137
Suggest dereferencing boolean reference when used in 'if' or 'while' Implements rust-lang#64557
…arkor Fix const generic arguments not displaying in types mismatch diagnostic Fixes rust-lang#61395
…ush-1, r=varkor fix bug in folding for constants These was a bug in the folding for constants that caused it to overlook bound regions. This branch includes some other little things that I did while trying to track the bug down. r? @oli-obk
…kruppe use 'invalid argument' for vxWorks vxWorks is using "invalid argument" instead of "Invalid argument" in reporting invalid options r? @rkruppe
@bors r+ p=8 rollup=never |
📌 Commit bc7df81 has been approved by |
bors
added
the
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
label
Oct 8, 2019
bors
added a commit
that referenced
this pull request
Oct 8, 2019
Rollup of 8 pull requests Successful merges: - #64726 (rewrite documentation for unimplemented! to clarify use) - #65040 (syntax: more cleanups in item and function signature parsing) - #65046 (Make `Cell::new` method come first in documentation) - #65098 (Add long error explanation for E0561) - #65150 (Suggest dereferencing boolean reference when used in 'if' or 'while') - #65154 (Fix const generic arguments not displaying in types mismatch diagnostic) - #65181 (fix bug in folding for constants) - #65187 (use 'invalid argument' for vxWorks) Failed merges: - #65179 (Add long error explanation for E0567) r? @ghost
☀️ Test successful - checks-azure |
This was referenced Oct 8, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in 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.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
Cell::new
method come first in documentation #65046 (MakeCell::new
method come first in documentation)Failed merges:
r? @ghost