Document `From` implementations #51753

gruberb · 2018-06-24T07:46:31Z

This PR is solves part of #51430. It's my first PR, so I might need some guidance from @skade (as already mentioned in the issue).

The purpose of the PR is to document the impl From inside path.rs and answering the questions:

What does it convert?
Does it allocate memory?
How expensive are the allocations?

I gave it a first shot, though an experienced rust developer might want to look over it.

pietroalbini · 2018-06-24T16:25:28Z

Restarted the Travis CI build, the failure was caused by the crates.io outage.

pietroalbini · 2018-06-24T16:32:26Z

Assigning someone from the libs team. r? @sfackler

skade

First of all @gruberb, thanks a lot!

I marked a couple of things. They are mostly the things why I think this is a good exercise :)!

I've also got things to discuss: I think it would be good to call pure type conversions "free", while things that go from one management structure to another (e.g. OsString -> OsStr) the way you are currently doing things (in-place).

@steveklabnik would you be up for some language clarification?

skade · 2018-06-24T20:03:45Z

src/libstd/path.rs

@@ -1419,20 +1423,28 @@ impl<'a, T: ?Sized + AsRef<OsStr>> From<&'a T> for PathBuf {

 #[stable(feature = "rust1", since = "1.0.0")]
 impl From<OsString> for PathBuf {
+    /// Converts a `OsString` into a `PathBuf`.
+    /// This conversion copies the data.
+    /// This conversion does allocate memory.
    fn from(s: OsString) -> PathBuf {
        PathBuf { inner: s }


Interestingly, this does not allocate memory. This is free.

PathBuf is a wrapper around OsString. If you have a struct with just one field, its memory structure is the same as the field itself. The Compiler "sees" through this and knows that turning OsString into a PathBuf is effectively a no-op.

See https://godbolt.org/g/1PBCTY (using String, as an example, but the principle is the same). If you have a close look at the blue and orange part, this just sets up for returning the previously allocated String. It doesn't even call the implementation!

Thanks a lot for the explanation, was a while since I looked at Assembler. Do you have a general set of tools you use for investigating memory allocation? I sort of did all over the place with no real plan.

skade · 2018-06-24T20:04:33Z

src/libstd/path.rs

@@ -1419,20 +1423,28 @@ impl<'a, T: ?Sized + AsRef<OsStr>> From<&'a T> for PathBuf {

 #[stable(feature = "rust1", since = "1.0.0")]
 impl From<OsString> for PathBuf {
+    /// Converts a `OsString` into a `PathBuf`.


I'm not sure if we need this sentence, but let's hear opinions. It's basically restating the code already says.

The format is generally "summary sentence, then other stuff". If you want other stuff, you need a summary. I'm not sure how else you'd summarize this. TL;DR it's fine.

skade · 2018-06-24T20:06:22Z

src/libstd/path.rs

    fn from(s: OsString) -> PathBuf {
        PathBuf { inner: s }
    }
 }

 #[stable(feature = "from_path_buf_for_os_string", since = "1.14.0")]
 impl From<PathBuf> for OsString {
+    /// Converts a `PathBuf` into a `OsString`.
+    /// This conversion copies the data.
+    /// This conversion does allocate memory.


Same here, but the other way around: Unwrapping a wrapper is free!

https://godbolt.org/g/Aoe8Q1

skade · 2018-06-24T20:14:26Z

src/libstd/path.rs

    fn from(path_buf : PathBuf) -> OsString {
        path_buf.inner
    }
 }

 #[stable(feature = "rust1", since = "1.0.0")]
 impl From<String> for PathBuf {
+    /// Converts a `String` into a `PathBuf`.
+    /// This conversion does not allocate memory


Have you investigated this for all platforms? I just did a cursory review, and it's true for Unix and Windows.

It should be the same for all of them.

skade · 2018-06-24T20:15:24Z

src/libstd/path.rs

+    /// Converts a `PathBuf` into a `Arc<Path>`.
+    /// This conversion happens in place.
+    /// This conversion does not allocate memory.
+    /// This function is unsafe. Data can't be moved from this reference.


How is this function unsafe? It isn't marked as such.

Hm, I was thinking because of line 1542. It calls internally an unsafe function. But I guess if the calling method is safe, then it doesn't matter if it calls unsafe internally?

Yes, Rust practice is to assume that the unsafety is contained in the block. Calling the function unsafe declares that people need to fulfil certain conditions before calling the function to ensure it can be safely called.

The reasoning behind that is that otherwise, everything would be transitively unsafe.

skade · 2018-06-24T20:15:37Z

src/libstd/path.rs

+    /// Converts a `PathBuf` into a `Arc<Path>`.
+    /// This conversion happens in place.
+    /// This conversion does not allocate memory.
+    /// This function is unsafe. Data can't be moved from this reference.


skade · 2018-06-24T20:16:18Z

src/libstd/path.rs

+    /// Converts a `PathBuf` into a `Rc<Path>`.
+    /// This conversion happens in place.
+    /// This conversion does not allocate memory.
+    /// This function is unsafe. Data can't be moved from this reference.


stokhos · 2018-06-29T19:03:00Z

Ping from triage @sfackler , will you have time to review this?

sfackler · 2018-06-30T13:58:21Z

I'll defer to the docs team.

r? @steveklabnik

stokhos · 2018-07-06T19:51:39Z

Ping from triage @steveklabnik @rust-lang/docs guys, this PR needs your review.

frewsxcv · 2018-07-08T12:06:29Z

src/libstd/path.rs

    fn from(boxed: Box<Path>) -> PathBuf {
        boxed.into_path_buf()
    }
 }

 #[stable(feature = "box_from_path_buf", since = "1.20.0")]
 impl From<PathBuf> for Box<Path> {
+    /// Converts a `PathBuf` into a `Box<Path>`.
+    /// This conversion does not allocate memory


Question for @rust-lang/docs: should we start specifying allocation behavior in the docs, like this line? I forgot if we've discussed this already in the past. Also FWIW, doesn't look like we specify allocation behavior in the docs for the underlying into_boxed_path method.

I think this would be a good idea. Rust is meant to be memory efficient, therefore, having allocation behavior precisions seems like a must have.

I think in many cases we'll need to check in with @rust-lang/libs but in obvious cases like this, it's meant to do so and so should be.

Convertion from an extensible container like PathBuf to a fixed size like Box<Path> doesn't necessarily explicitly allocate memory but it does use shrink_to_fit which attempts to shrink the allocation of PathBuf to precisely match the Path in question. Most of the time this doesn't allocate memory, but to be safe it's probably best to avoid accidentally providing a guarantee that this doesn't allocate.

@alexcrichton Should we add this in the docs or remove them all together?

Nah I think having them is fine so long as it's clear that currently it's unlikely to reallocate/allocate memory, but this isn't necessarily guaranteed in the future

frewsxcv · 2018-07-08T12:08:08Z

src/libstd/path.rs

@@ -1529,6 +1542,9 @@ impl From<PathBuf> for Arc<Path> {

 #[stable(feature = "shared_from_slice2", since = "1.24.0")]
 impl<'a> From<&'a Path> for Arc<Path> {
+    /// Converts a `PathBuf` into a `Arc<Path>`.
+    /// This conversion happens in place.


I don't think we need to specify in the docs which functions are marked inline, rustdoc already renders the #[inline] attribute if I recall correctly.

It does indeed so unneeded.

So I assume I can delete this comment then and rustdoc is adding an #[inline] or should I add it?

Actually, I take it back, #[inline] is _not_currently rendered by rustdoc. Hmmm

https://doc.rust-lang.org/nightly/std/vec/struct.Vec.html#method.new

It should be though! I open an issue for it.

"in place" sounds different than "this function is marked inline" to me; we should find a better wording if it's not, or remove it if it is supposed to communicate that.

gruberb · 2018-07-20T08:52:41Z

@skade What should I add/change to finish this one?

src/libstd/path.rs

steveklabnik · 2018-07-23T13:08:52Z

src/libstd/path.rs

    fn from(boxed: Box<Path>) -> PathBuf {
        boxed.into_path_buf()
    }
 }

 #[stable(feature = "box_from_path_buf", since = "1.20.0")]
 impl From<PathBuf> for Box<Path> {
+    /// Converts a `PathBuf` into a `Box<Path>`.
+    /// This conversion does not allocate memory


I think in many cases we'll need to check in with @rust-lang/libs but in obvious cases like this, it's meant to do so and so should be.

steveklabnik · 2018-07-23T13:09:40Z

src/libstd/path.rs

@@ -1419,20 +1423,28 @@ impl<'a, T: ?Sized + AsRef<OsStr>> From<&'a T> for PathBuf {

 #[stable(feature = "rust1", since = "1.0.0")]
 impl From<OsString> for PathBuf {
+    /// Converts a `OsString` into a `PathBuf`.


The format is generally "summary sentence, then other stuff". If you want other stuff, you need a summary. I'm not sure how else you'd summarize this. TL;DR it's fine.

steveklabnik · 2018-07-23T13:09:54Z

src/libstd/path.rs

    fn from(path_buf : PathBuf) -> OsString {
        path_buf.inner
    }
 }

 #[stable(feature = "rust1", since = "1.0.0")]
 impl From<String> for PathBuf {
+    /// Converts a `String` into a `PathBuf`.
+    /// This conversion does not allocate memory


It should be the same for all of them.

steveklabnik · 2018-07-23T13:10:13Z

src/libstd/path.rs

@@ -1520,6 +1530,9 @@ impl<'a> From<Cow<'a, Path>> for PathBuf {

 #[stable(feature = "shared_from_slice2", since = "1.24.0")]
 impl From<PathBuf> for Arc<Path> {
+    /// Converts a `PathBuf` into a `Arc<Path>`.
+    /// This conversion happens in place.
+    /// This conversion does not allocate memory.


Because this one is logically three parts, you'll need two blank lines to separate them out here

steveklabnik · 2018-07-23T13:11:05Z

src/libstd/path.rs

@@ -1529,6 +1542,9 @@ impl From<PathBuf> for Arc<Path> {

 #[stable(feature = "shared_from_slice2", since = "1.24.0")]
 impl<'a> From<&'a Path> for Arc<Path> {
+    /// Converts a `PathBuf` into a `Arc<Path>`.
+    /// This conversion happens in place.


"in place" sounds different than "this function is marked inline" to me; we should find a better wording if it's not, or remove it if it is supposed to communicate that.

steveklabnik · 2018-07-23T13:11:34Z

@gruberb sorry for taking a while here! I'll try to stay on top of this PR better :)

pietroalbini · 2018-07-30T17:19:28Z

Ping from triage @steveklabnik! This PR needs your review.

steveklabnik

@alexcrichton left a comment that we can't guarantee that these don't allocate, so I think we have to remove all of that

gruberb · 2018-08-03T09:20:54Z

@steveklabnik So it's still valuable according to #51753 (comment). Any ideas on the next steps?

TimNN · 2018-08-07T17:33:26Z

Ping from triage @steveklabnik. It looks like it's a bit unclear on how this PR should be changed. (Should mention of allocations be removed or just clarified that the behavior may change in the future?) Could you clarify?

pietroalbini · 2018-08-27T15:29:00Z

Ping from triage! This PR needs a review, can @steveklabnik or someone else from @rust-lang/docs review this?

QuietMisdreavus · 2018-08-27T20:06:12Z

Taking a look at these, i'm concerned with the statements being applied to a few impls. There seems to be a misunderstanding of the underlying mechanisms (and i don't blame you, this pile of implementation details goes all over the place and impressively deep) that has caused the resulting documentation to get out of sync with its implementation.

The comments about conversions happening "in place" are misleading, because that's not what's implied by the #[inline] attribute. If i'm looking for the allocation characteristics of a conversion, if i see "in place" i assume that there is neither an allocation nor a data copy.

Let's break down the (current) behavior for the impls in question, because i believe several of them are making incorrect statements:

impl From<OsString> for PathBuf, impl From<PathBuf> for OsString, impl From<Box<Path>> for PathBuf
- These are effectively pointer conversions, so i would say these happen "in place", without allocating memory:
  
  This conversion does not allocate or copy memory.
impl From<PathBuf> for Box<Path>
- The memory characteristics of this one depend on how shrink_to_fit is handled by the allocator. Based on discussion in this thread, this shouldn't allocate or copy most of the time, but i'm not comfortable making an absolute statement on it. This one can probably be rephrased to something like:
  
  This conversion currently should not allocate memory, but this behavior is not guaranteed on all platforms or in all future versions.
impl From<String> for PathBuf
- This one is sketchy, as it really depends on how the String -> OsString conversion goes. On Unix and Windows, these look like pointer conversions (take the Vec<u8> out of the String and put it into an OsString based on the UTF-8 guarantees of String), but does this apply to all platforms? I'm not comfortable making a blanket statement here. Here's my idea of a decent statement for this one:
  
  ~~On Unix and Windows, this conversion currently should not allocate memory, but this behavior is not guaranteed on all platforms or in all future versions.~~
  
  ~~(Am i reading the Windows implementation correctly? The use of the WTF-8 buffer and the direct conversion from a Vec<u8> seems to contradict the statement in OsString's documentation.)~~
  
  Based on @SimonSapin's confirmation below, and a rereading of the OsString docs, i'm comfortable using this phrasing for this conversion:
  
  This conversion does not allocate or copy memory.
impl From<PathBuf> for Arc<Path>, impl<'a> From<&'a Path> for Arc<Path>, impl From<PathBuf> for Rc<Path> (and the impl<'a> From<&'a Path> for Rc<Path> that you missed right below)
- These all definitely allocate memory and copy data into the new buffer. The Arc/Rc backing buffers need to hold the item's reference count(s), so a new buffer needs to be created each time. This may be an implementation detail that we may or may not actually want to expose, but to say that these conversions don't allocate memory is incorrect. They could be rephrased to something like:
  
  Converts a (source type) into a (target type) by copying the Path data into a new (Arc/Rc) buffer.

SimonSapin · 2018-08-28T04:14:06Z

impl From<String> for PathBuf
On Unix and Windows, these look like pointer conversions […], but does this apply to all platforms?

TL;DR: I can confirm that this is only a pointer conversion on all platforms.

The intended design is that the encoding of OsString is always a superset of UTF-8 (which is String’s encoding). Specifically, on currently-supported platforms, either arbitrary bytes or WTF-8. In other words, the set of values of OsString is a superset of the set of values of String, with common values having the same memory representation.

This intent is to some extent already locked in by stable APIs:

impl From<String> for OsString. This conversion being infallible (not returning a Result) implies that all String values can be represented somehow as OsString.
OsString::to_str(&self) -> Option<&str> (through Deref<Target = OsStr>). The signature returning a borrow implies that at least some values have a memory representation compatible with UTF-8. I think the documentation requires that all values that can, do.

steveklabnik · 2018-09-05T15:53:07Z

@bors: r? QuietMisdreavus

GuillaumeGomez · 2018-09-06T08:12:17Z

Also, please add examples.

rust-highfive · 2018-11-21T12:54:07Z

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

travis_time:end:101a4afc:start=1542804044339965845,finish=1542804046879266452,duration=2539300607
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#Pull-Requests-and-Security-Restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
Setting environment variables from .travis.yml
$ export IMAGE=x86_64-gnu-llvm-5.0
---
[00:04:06] tidy error: /checkout/src/libstd/path.rs:1412: trailing whitespace
[00:04:07] some tidy checks failed
[00:04:07] 
[00:04:07] 
[00:04:07] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/tidy" "/checkout/src" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "--no-vendor" "--quiet"
[00:04:07] 
[00:04:07] 
[00:04:07] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:04:07] Build completed unsuccessfully in 0:00:58
[00:04:07] Build completed unsuccessfully in 0:00:58
[00:04:07] make: *** [tidy] Error 1
[00:04:07] Makefile:79: recipe for target 'tidy' failed
The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:2f63ee00
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
Wed Nov 21 12:45:03 UTC 2018
---
travis_time:end:08074933:start=1542804304403494753,finish=1542804304408999905,duration=5505152
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:02834ec8
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:12807180
travis_time:start:12807180
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:32bf1824
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

TimNN · 2018-11-27T18:14:48Z

Ping from triage @QuietMisdreavus: It looks like this PR is now ready for your review!

Centril · 2018-12-01T16:01:38Z

Ping from triage: @rust-lang/docs -- can anyone drive this PR to completion?

QuietMisdreavus

One last nit, then this looks good to go! Thanks for sticking through with this!

src/libstd/path.rs

gruberb · 2018-12-04T09:13:20Z

Ping @QuietMisdreavus: added the comment slash!

QuietMisdreavus

Thanks so much for sticking with this! Sorry that it turned out to be a bigger deal than anticipated; some things turn out to be a little complicated to document! 😅

QuietMisdreavus · 2018-12-04T15:09:13Z

I think, given the rest of the discussion, that the docs currently in the PR are fine to merge. If you want to come back and add some examples to these docs like @GuillaumeGomez suggested, you can make a new PR once this lands. This PR is old enough that i don't want to hold it up any longer - what's here is good enough to add as-is.

@bors r+ rollup

bors · 2018-12-04T15:09:15Z

📌 Commit 450a8a6 has been approved by QuietMisdreavus

@skade

…ibstdpath, r=QuietMisdreavus Document `From` implementations This PR is solves part of rust-lang#51430. It's my first PR, so I might need some guidance from @skade (as already mentioned in the issue). The purpose of the PR is to document the `impl From` inside `path.rs` and answering the questions: - What does it convert? - Does it allocate memory? - How expensive are the allocations? I gave it a first shot, though an experienced rust developer might want to look over it.

@skade

…ibstdpath, r=QuietMisdreavus Document `From` implementations This PR is solves part of rust-lang#51430. It's my first PR, so I might need some guidance from @skade (as already mentioned in the issue). The purpose of the PR is to document the `impl From` inside `path.rs` and answering the questions: - What does it convert? - Does it allocate memory? - How expensive are the allocations? I gave it a first shot, though an experienced rust developer might want to look over it.

@skade

…ibstdpath, r=QuietMisdreavus Document `From` implementations This PR is solves part of rust-lang#51430. It's my first PR, so I might need some guidance from @skade (as already mentioned in the issue). The purpose of the PR is to document the `impl From` inside `path.rs` and answering the questions: - What does it convert? - Does it allocate memory? - How expensive are the allocations? I gave it a first shot, though an experienced rust developer might want to look over it.

@skade

…ibstdpath, r=QuietMisdreavus Document `From` implementations This PR is solves part of rust-lang#51430. It's my first PR, so I might need some guidance from @skade (as already mentioned in the issue). The purpose of the PR is to document the `impl From` inside `path.rs` and answering the questions: - What does it convert? - Does it allocate memory? - How expensive are the allocations? I gave it a first shot, though an experienced rust developer might want to look over it.

@ghost

Rollup of 15 pull requests Successful merges: - #51753 (Document `From` implementations) - #55563 (Improve no result found sentence in doc search) - #55987 (Add Weak.ptr_eq) - #56119 (Utilize `?` instead of `return None`.) - #56372 (Refer to the second borrow as the "second borrow" in E0501.rs) - #56388 (More MIR borrow check cleanup) - #56424 (Mention raw-ident syntax) - #56452 (Remove redundant clones) - #56456 (Handle existential types in dead code analysis) - #56466 (data_structures: remove tuple_slice) - #56476 (Fix invalid line number match) - #56497 (cleanup: remove static lifetimes from consts in libstd) - #56498 (Fix line numbers display) - #56523 (Added a bare-bones eslint config (removing jslint)) - #56538 (Use inner iterator may_have_side_effect for Cloned) Failed merges: r? @ghost

This comment has been minimized.

Sign in to view

pietroalbini added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 24, 2018

rust-highfive assigned sfackler Jun 24, 2018

skade suggested changes Jun 24, 2018

View reviewed changes

rust-highfive assigned steveklabnik and unassigned sfackler Jun 30, 2018

stokhos added the A-docs Area: documentation for any part of the project, including the compiler, standard library, and tools label Jul 6, 2018

frewsxcv reviewed Jul 8, 2018

View reviewed changes

steveklabnik suggested changes Jul 23, 2018

View reviewed changes

steveklabnik approved these changes Jul 30, 2018

View reviewed changes

steveklabnik suggested changes Jul 30, 2018

View reviewed changes

pietroalbini added S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 27, 2018

Mark-Simulacrum added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). labels Nov 15, 2018

Remove trailing whitespace

7933628

TimNN added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 27, 2018

Centril added S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 1, 2018

QuietMisdreavus reviewed Dec 3, 2018

View reviewed changes

src/libstd/path.rs Outdated Show resolved Hide resolved

Add extra comment slash

450a8a6

QuietMisdreavus approved these changes Dec 4, 2018

View reviewed changes

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). labels Dec 4, 2018

GuillaumeGomez mentioned this pull request Dec 4, 2018

Rollup of 15 pull requests #56521

Closed

GuillaumeGomez mentioned this pull request Dec 5, 2018

Rollup of 19 pull requests #56531

Closed

pietroalbini mentioned this pull request Dec 5, 2018

Rollup of 25 pull requests #56547

Closed

pietroalbini mentioned this pull request Dec 5, 2018

Rollup of 15 pull requests #56549

Merged

bors merged commit 450a8a6 into rust-lang:master Dec 6, 2018

Document From implementations #51753

Document From implementations #51753

Conversation

gruberb commented Jun 24, 2018

This comment has been minimized.

pietroalbini commented Jun 24, 2018

pietroalbini commented Jun 24, 2018

skade left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gruberb Jun 25, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stokhos commented Jun 29, 2018

sfackler commented Jun 30, 2018

stokhos commented Jul 6, 2018

Choose a reason for hiding this comment

GuillaumeGomez Jul 8, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gruberb commented Jul 20, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

steveklabnik commented Jul 23, 2018

pietroalbini commented Jul 30, 2018

steveklabnik left a comment

Choose a reason for hiding this comment

gruberb commented Aug 3, 2018

TimNN commented Aug 7, 2018

pietroalbini commented Aug 27, 2018

QuietMisdreavus commented Aug 27, 2018 • edited Loading

SimonSapin commented Aug 28, 2018

steveklabnik commented Sep 5, 2018 • edited Loading

GuillaumeGomez commented Sep 6, 2018

rust-highfive commented Nov 21, 2018

TimNN commented Nov 27, 2018

Centril commented Dec 1, 2018

QuietMisdreavus left a comment

Choose a reason for hiding this comment

gruberb commented Dec 4, 2018

QuietMisdreavus left a comment

Choose a reason for hiding this comment

QuietMisdreavus commented Dec 4, 2018

bors commented Dec 4, 2018

Document `From` implementations #51753

Document `From` implementations #51753

skade left a comment •

edited

Loading

gruberb Jun 25, 2018 •

edited

Loading

GuillaumeGomez Jul 8, 2018 •

edited

Loading

QuietMisdreavus commented Aug 27, 2018 •

edited

Loading

steveklabnik commented Sep 5, 2018 •

edited

Loading