Rollup of 11 pull requests #59293
Merged
Rollup of 11 pull requests #59293
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
Co-Authored-By: xfix <konrad@borowski.pw>
…);` and potentially instantiated at different types. (Updated to reflect changes in diagnostic output and compiletest infrastructure.)
…:…` in stdlib docs
The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.
This functionality was added in 1.35.0, not 1.34.0.
Add todo!() macro The primary use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro. EDIT: hide unpopular proposal about re-purposing unimplemented <details> However, instead of just replacing `unimplemented!()`, it gives it a more nuanced meaning: a thing which is intentionally left unimplemented and which should not be called at runtime. Usually, you'd like to prevent such cases statically, but sometimes you, for example, have to implement a trait only some methods of which are applicable. There are examples in the wild of code doing this thing, and in this case, the current message of `unimplemented`, "not *yet* implemented" is slightly misleading. With the addition of TODO, you have three nuanced choices for a `!`-returning macro (in addition to a good-old panic we all love): * todo!() * unreachable!() * unimplemented!() Here's a rough guideline what each one means: - `todo`: use it during development, as a "hole" or placeholder. It might be a good idea to add a pre-commit hook which checks that `todo` is not accidentally committed. - `unreachable!()`: use it when your code can statically guarantee that some situation can not happen. If you use a library and hit `unreachable!()` in the library's code, it's definitely a bug in the library. It's OK to have `unreachable!()` in the code base, although, if possible, it's better to replace it with compiler-verified exhaustive checks. - `unimplemented!()`: use it when the type checker forces you to handle some situation, but there's a contract that a callee must not actually call the code. If you use a library and hit `unimplemented!()`, it's probably a bug in your code, though it *could* be a bug in the library (or library docs) as well. It is ok-ish to see an `unimplemented!()` in real code, but it usually signifies a clunky, eyebrow-rising API. </details>
…constraints-on-bindings-too, r=nikomatsakis extra testing of how NLL handles wildcard type `_` test that wildcard type `_` is not duplicated by `type Foo<X> = (X, X);` and potentially instantiated at different types when used in type ascriptions in let bindings. (NLL's handling of this for the type ascription *expression form* is currently broken, or at least differs from what AST-borrowck does. I'll file a separate bug about that. Its not something critical to address since that expression is guarded by `#![feature(type_ascription)]`.) cc rust-lang#55748
dbg!() without parameters Fixes rust-lang#57845.
…r=SimonSapin Implement ExactSizeIterator for ToLowercase and ToUppercase
Clarify distinction between floor() and trunc() `floor()` rounds towards `-INF`, `trunc()` rounds towards 0. This PR clarifies this in the examples.
Fix a tiny error in documentation of std::pin. `new_unmoved` must be `mut` for passing to `std::mem::swap`.
Be more discerning on when to attempt suggesting a comma in a macro invocation Fix rust-lang#58796.
add self to mailmap
Replaced self-reflective explicit types with clearer `Self` or `Self::…` in stdlib docs Many docs examples use explicit types instead of the semantically more clear `Self`/`Self::…` aliases. By using the latter it's clear that the value's type depends on either `Self`, or an associated type of `Self`, instead of some constant type. It's also more consistent (and I'd argue correct), as the current docs aren't really consistent in this, as can be seen from the diff. This is a best effort PR, as I was basically going through the docs manually, looking for offending examples. I'm sure I missed a few. Gotta start somewhere.
…cell-map-split, r=cramertj,Centril Stabilize refcell_map_split feature Closes rust-lang#51476.
Run branch cleanup after copy prop This is preliminary work for rust-lang#59288 (comment) which gets rid of `if` in the HIR. cc @rust-lang/wg-mir-opt @Centril
|
@bors r+ p=11 |
|
📌 Commit 7f7829f has been approved by |
bors
added
the
S-waiting-on-bors
bors
added a commit
that referenced
this pull request
Mar 19, 2019
Rollup of 11 pull requests Successful merges: - #56348 (Add todo!() macro) - #57729 (extra testing of how NLL handles wildcard type `_`) - #57847 (dbg!() without parameters) - #58778 (Implement ExactSizeIterator for ToLowercase and ToUppercase) - #58812 (Clarify distinction between floor() and trunc()) - #58939 (Fix a tiny error in documentation of std::pin.) - #59116 (Be more discerning on when to attempt suggesting a comma in a macro invocation) - #59252 (add self to mailmap) - #59275 (Replaced self-reflective explicit types with clearer `Self` or `Self::…` in stdlib docs) - #59280 (Stabilize refcell_map_split feature) - #59290 (Run branch cleanup after copy prop) Failed merges: r? @ghost
|
☀️ Test successful - checks-travis, status-appveyor |
This was referenced Mar 19, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:
_#57729 (extra testing of how NLL handles wildcard type_)SelforSelf::…in stdlib docs #59275 (Replaced self-reflective explicit types with clearerSelforSelf::…in stdlib docs)Failed merges:
r? @ghost