Rollup of 6 pull requests #48307
Closed
Rollup of 6 pull requests #48307
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
Member
GuillaumeGomez
commented
Feb 17, 2018
GuillaumeGomez
commented
- Successful merges: Fix span of visibility #47799, Generate documentation for auto-trait impls #47833, Doc test command #48194, Add a warning to File about mutability. #48273, fix more typos found by codespell. #48275, Fix spelling in core::iter::repeat_with: s/not/note #48282
- Failed merges:
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
This span covers the whole visibility expression: e.g. `pub (in path)`.
… r=petrochenkov Fix span of visibility This PR 1. adds a closing parenthesis to the span of `Visibility::Crate` (e.g. `pub(crate)`). The current span only covers `pub(crate`. 2. adds a `span` field to `Visibility::Restricted`. This span covers the entire visibility expression (e.g. `pub (in self)`). Currently all we can have is a span for `Path`. This PR is motivated by the bug found in rustfmt (rust-lang/rustfmt#2398). The first change is a strict improvement IMHO. The second change may not be desirable, as it adds a field which is currently not used by the compiler.
…aumeGomez,QuietMisdreavus Generate documentation for auto-trait impls A new section is added to both both struct and trait doc pages. On struct/enum pages, a new 'Auto Trait Implementations' section displays any synthetic implementations for auto traits. Currently, this is only done for Send and Sync.  On trait pages, a new 'Auto Implementors' section displays all types which automatically implement the trait. Effectively, this is a list of all public types in the standard library.  Synthesized impls for a particular auto trait ('synthetic impls') take generic bounds into account. For example, a type ```rust struct Foo<T>(T) ``` will have 'impl<T> Send for Foo<T> where T: Send' generated for it. Manual implementations of auto traits are also taken into account. If we have the following types: ```rust struct Foo<T>(T) struct Wrapper<T>(Foo<T>) unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes this sound somehow ``` Then Wrapper will have the following impl generated: ```rust impl<T> Send for Wrapper<T> ``` reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send' to hold Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are taken into account by synthetic impls:  However, if a type can *never* implement a particular auto trait (e.g. `struct MyStruct<T>(*const T)`), then a negative impl will be generated (in this case, `impl<T> !Send for MyStruct<T>`) All of this means that a user should be able to copy-paste a syntheticimpl into their code, without any observable changes in behavior (assuming the rest of the program remains unchanged).
…Mark-Simulacrum Doc test command r? @Mark-Simulacrum
Add a warning to File about mutability. Fixes rust-lang#47708.
…arkor fix more typos found by codespell.
…th, r=kennytm Fix spelling in core::iter::repeat_with: s/not/note Fixes spelling error in rust-lang#48156 (comment). Tracking issue: rust-lang#48169
|
Some changes occurred in HTML/CSS. |
|
r? @frewsxcv (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
@bors: r+ p=6 |
|
📌 Commit 1825fbe has been approved by |
bors
added
S-waiting-on-bors
|
⌛ Testing commit 1825fbe with merge 977b948f822fe2a4a312840fba6da7017a618b88... |
|
💔 Test failed - status-travis |
bors
added
S-waiting-on-review
|
Legit. Caused by #47833 |
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.