This will make the types more readable in the documentation, since the letters correspond with what you should either be sending or expecting to receive.
`TotalEq` is now just an assertion about the `Eq` impl of a
type (i.e. `==` is a total equality if a type implements `TotalEq`) so
the extra method is just confusing.
Also, a new method magically appeared as a hack to allow deriving to
assert that the contents of a struct/enum are also TotalEq, because the
deriving infrastructure makes it very hard to do anything but create a
trait method. (You didn't hear about this horrible work-around from me
:(.)
Fixes#12992
Store compressed bitcode files in rlibs with a different extension. Compression doesn't interfere with --emit=bc.
Regression test compares outputs.
`Vec` is now used for the internal buffer instead of `~[]`. Some module
level documentation somehow ended up attached to `BufferedReader` so I
fixed that as well.
This needs to be removed as part of removing `~[T]`. Partial type hints
are now allowed, and will remove the need to add a version of this
method for `Vec<T>`. For now, this involves a few workarounds for
partial type hints not completely working.
`Vec` is now used for the internal buffer instead of `~[]`. Some module
level documentation somehow ended up attached to `BufferedReader` so I
fixed that as well.
This commit removes the `get()` method from `Ref` and `RefMut` in favor of the `*` operator, and removes all usage of the `deref()` function manually from rustc, favoring using `*` instead.
Some of the code is a little wacky, but that's due to either #13044 or #13042
It's possible for a reader to have a short read, and there's no reason the task
should fail in this scenario. By using fill(), this has a stronger guarantee
that the buffer will get filled with data.
I've found a common use case being to fill a slice (not an owned vector)
completely with bytes. It's posible for short reads to happen, and if you're
trying to get an exact number of bytes then this helper will be useful.
`FormatMessageW()` is called by `std::os::last_os_error()` to convert
errno into string, but the function may fail on non-english locale.
I don't know why it fails, but anyway it's better to return errno
than to `fail!()` in the case.
Fixes#13075Fixes#13073
`FormatMessageW()` is called by `std::os::last_os_error()` to convert
errno into string, but the function may fail on non-english locale.
I don't know why it fails, but anyway it's better to return errno
than to `fail!()` in the case.
Fixes#13075Fixes#13073
This is a very minor edit to the tutorial section on references.
Reading this section for the first time, I stumbled on the phrase "a reference can be borrowed to any object." Its meaning was clear enough once I got it, but I had to re-read it a couple of times to parse it correctly. Something about the passive voice plus the way "reference to any object" is split up by the verb phrase. How about this instead?
These are superfluous now that we have fixed rvalue lifetimes and Deref.
I'd also like to kill off `get` and `set`, but that'll be a large change so I want to make sure that we actually want to do that first.
The OSX bots have been deadlocking recently in the rustdoc tests. I have only
been able to rarely reproduce the deadlock on my local setup. When reproduced,
it looks like the child process is spinning on the malloc mutex, which I
presume is locked with no other threads to unlock it.
I'm not convinced that this is what's happening, because OSX should protect
against this with pthread_atfork by default. Regardless, running as little code
as possible in the child after fork() is normally a good idea anyway, so this
commit moves all allocation to the parent process to run before the child
executes.
After running 6k iterations of rustdoc tests, this deadlocked twice before, and
after 20k iterations afterwards, it never deadlocked. I draw the conclusion that
this is either sweeping the bug under the rug, or it did indeed fix the
underlying problem.
These methods can be mistaken for general "read some bytes" utilities when
they're actually only meant for reading an exact number of bytes. By renaming
them it's much clearer about what they're doing without having to read the
documentation.
Closes#12892
