"Dual impls" are impls that are both type implementations and trait
implementations. They can lead to ambiguity and so this patch removes them
from the language.
This also enforces coherence rules. Without this patch, records can implement
traits not defined in the current crate. This patch fixes this, and updates
all of rustc to adhere to the new enforcement. Most of this patch is fixing
rustc to obey the coherence rules, which involves converting a bunch of records
to structs.
1. In the first case, the previous code was failing during type inference
due to mismatched structure. Fix is to use the X structure at both
points in the code.
2. In the second case, a naive transcription that subsitutes *nothing*
in for the omitted statements signified by "..." will actually
compile without an error. Furthermore, any pure code could also be
substituted for the ellipsis and the code would compile (as the
text already states). So to make the example more illustrative, it
would be better to include an impure callback, which makes the
potential for aliasing immediately obvious to the reader.
1. The section on trait definitions of static methods should include
a trait with a static method in the generated document.
2. The section on trait inheritance had a expression that appears
nonsensical ("let mycircle = @mycircle") in the generated document.
The text would be clearer (IMO) if we continued with the running
example of CircleStruct.
Ubuntu's clang packages have additional information appended to the end of
the version.
- Building Rust v0.5 with clang v3.0-6ubuntu3 fails.
- Building Rust v0.5 and incoming with clang v3.1-5ppa (backported from Debian)
works.
Closes#4441.
For every call to the read() function the internal buffer was copied
into a new buffer (minus the bytes copied into the result buffer). When
the internal buffer is large enough, this severely affects performance,
especially when read_line() is used which calls read_byte() (which calls
read()) for each read byte.
For line oriented I/O this wasn't all that bad, because the internal
buffers usually never were very big. The effect is much more visible
once the buffer grows larger.
Now we always first look into the internal buffer and copy as many bytes
as possible (and desired) into the result buffer. If we need more, we
call the socket read function and use the result as the new internal
buffer, then continue to copy from the (new) internal buffer, and so on.