```rust
pub fn drain(&mut self) -> Drain<T> {
// Oops, setting it to 0 while we still need the old value!
self.len = 0;
unsafe {
Drain {
// len is used to create a &[T] from &self here,
// so we end up always creating an empty slice.
iter: RawValIter::new(&self),
vec: PhantomData,
}
}
}
```
A simple test to verify that Drain is broken can be found here:
https://play.rust-lang.org/?gist=30f579565e4bbf4836ce&version=nightly
And here's one with a fixed implementation:
https://play.rust-lang.org/?gist=2ec0c1a6dcf5defd7a53&version=nightly
```rust
pub fn drain(&mut self) -> Drain<T> {
// Oops, setting it to 0 while we still need the old value!
self.len = 0;
unsafe {
Drain {
// len is used to create a &[T] from &self here,
// so we end up always creating an empty slice.
iter: RawValIter::new(&self),
vec: PhantomData,
}
}
}
```
A simple test to verify that Drain is broken can be found here:
https://play.rust-lang.org/?gist=30f579565e4bbf4836ce&version=nightly
And here's one with a fixed implementation:
https://play.rust-lang.org/?gist=2ec0c1a6dcf5defd7a53&version=nightly
Auto merge of #28242 - Diggsey:msvc-backtrace, r=alexcrichton
Currently LLVM does not generate the debug info required to get complete backtraces even when functions are inlined, so that part of the `run-pass/backtrace-debuginfo.rs` test is disabled when targetting MSVC. At worst this results in missing stack frames where functions have been inlined.
Auto merge of #28240 - nhowell:master, r=steveklabnik
The Introduction page generated by rustbook used weird relative links
like "./getting-started.html" instead of just "getting-started.html"
like on the other pages. This adversely affected Windows builds the
worst, since it generated links like ".\getting-started.html" (note the
backslash). If you then try to upload the generated book to a webserver,
you end up with 404's. See this example of what is going on with the
Introduction page links and why this PR should fix it:
http://is.gd/fRUTXk
Compare the links on these two pages, for instance:
https://doc.rust-lang.org/nightly/book/
https://doc.rust-lang.org/nightly/book/getting-started.html
Nick Howell [Fri, 4 Sep 2015 21:00:33 +0000 (17:00 -0400)]
rustbook: Fix relative links on the Introduction page
The Introduction page generated by rustbook used weird relative links
like "./getting-started.html" instead of just "getting-started.html"
like on the other pages. This adversely affected Windows builds the
worst, since it generated links like ".\getting-started.html" (note the
backslash). If you then try to upload the generated book to a webserver,
you end up with 404's. See this example of what is going on with the
Introduction page links and why this PR should fix it:
http://is.gd/fRUTXk
Compare the links on these two pages, for instance:
https://doc.rust-lang.org/nightly/book/
https://doc.rust-lang.org/nightly/book/getting-started.html
Huon Wilson [Fri, 4 Sep 2015 00:00:11 +0000 (17:00 -0700)]
Support return aggregates in platform intrinsics.
This also involved adding `[TYPE;N]` syntax and aggregate indexing
support to the generator script: it's the only way to be able to have a
parameterised intrinsic that returns an aggregate, since one can't refer
to previous elements of the current aggregate (and that was harder to
implement).
Auto merge of #28034 - alexcrichton:new-lines, r=aturon
This commit is an implementation of [RFC 1212][rfc] which tweaks the behavior of
the `str::lines` and `BufRead::lines` iterators. Both iterators now account for
`\r\n` sequences in addition to `\n`, allowing for less surprising behavior
across platforms (especially in the `BufRead` case). Splitting *only* on the
`\n` character can still be achieved with `split('\n')` in both cases.
The `str::lines_any` function is also now deprecated as `str::lines` is a
drop-in replacement for it.
Auto merge of #28004 - Diggsey:win-backtrace, r=alexcrichton
Technically this could also be used for `windows-msvc` targets, as I believe they have *both* dwarf and pdb debug information, but I haven't enabled it there as it should really use the native windows APIs for that, instead of libbacktrace.
I wasn't exactly sure where I should put "gnu" specific stuff, so tell me if I should structure things differently.
This is still a WIP, and I haven't tested properly to make sure I haven't broken msvc/linux builds yet.
Alex Crichton [Thu, 27 Aug 2015 00:30:45 +0000 (17:30 -0700)]
std: Account for CRLF in {str, BufRead}::lines
This commit is an implementation of [RFC 1212][rfc] which tweaks the behavior of
the `str::lines` and `BufRead::lines` iterators. Both iterators now account for
`\r\n` sequences in addition to `\n`, allowing for less surprising behavior
across platforms (especially in the `BufRead` case). Splitting *only* on the
`\n` character can still be achieved with `split('\n')` in both cases.
The `str::lines_any` function is also now deprecated as `str::lines` is a
drop-in replacement for it.
Diggory Blake [Wed, 26 Aug 2015 00:44:55 +0000 (01:44 +0100)]
Add line numbers to windows-gnu backtraces
Fix formatting
Remove unused imports
Refactor
Fix msvc build
Fix line lengths
Formatting
Enable backtrace tests
Fix using directive on mac
pwd info
Work-around buildbot PWD bug, and fix libbacktrace configuration
Use alternative to `env -u` which is not supported on bitrig
Disable tests on 32-bit windows gnu
Steve Klabnik [Fri, 4 Sep 2015 00:10:07 +0000 (20:10 -0400)]
Rollup merge of #28205 - matklad:grammar-remove-proc, r=alexcrichton
As I understand, there are no proc closures in Rust any more. So this pr removes `procedure_type` production. It isn't used anywhere. The `proc` is still a keyword.
Steve Klabnik [Fri, 4 Sep 2015 00:10:07 +0000 (20:10 -0400)]
Rollup merge of #28203 - benschulz:book-deref-coercion, r=brson
I have two issues with the section "Deref and method calls" of the book's chapter "Deref coercions".
- (Minor) It says "In other words, these are the same two things in Rust:", followed by a code block in which no two things seem similar, much less the same. Presumably this sentence made more sense in a previous revision.
- The next paragraph conflates two concepts which, imho, should kept separate. They are
- deref coercion, i.e. inserting as many `*` as necessary and
- implicitly referencing the receiver, i.e. inserting a single `&` to satisfy the method's `self` parameter type.
I appreciate that with the proposed changes the example becomes very contrived, even for a foo-bar-baz one. However, the current exmplanation is just wrong.
Auto merge of #27984 - arielb1:misc-assemble-improvements, r=nikomatsakis
this resolves type-variables early in assemble_candidates and
bails out quickly if the self type is an inference variable (which would
fail anyway because of `assemble_candidates_from_projected_tys`).
In both these cases, `assemble_candidates_from_impls` would try to go
over all impls and match them, leading to O(`n*m`) performance. Fixing this
improves rustc type-checking performance by 10%. As type-checking is only
is 5% of compilation, this doesn't impact bootstrap times, but *does*
improve type-error-detection time which is nice.
Crates that have many dependencies and contain significant amounts of
generic functions could see a bigger perf boost. As a microbenchmark,
the crate generated by
```
echo '#![feature(rustc_private)]'
echo 'extern crate rustc_driver;'
for i in {1..1000}; do cat << _EOF_
pub fn foo$i<T>() {
let mut v = Vec::new();
let _w = v.clone();
v.push("");
}
_EOF_
done
```
sees performance improve from 7.2 to 1.4 seconds. I imagine many crates
would fall somewhere in-between.
Rollup merge of #28191 - llogiq:iter, r=Manishearth
Nothing too big, a few needless returns and a few closures eliminated (the latter may improve performance in some cases, at least compilation should be a bit faster).
Rollup merge of #28184 - xiaochuanyu:patch-1, r=alexcrichton
Originally in an example it reads as follows:
```rust
fn inverse<T>() -> T
// this is using ConvertTo as if it were "ConvertFrom<i32>"
where i32: ConvertTo<T> {
42.convert()
}
```
There was no mention of `ConvertFrom` elsewhere in the page other than in this comment. Is this supposed to be `ConvertTo<i64>` ?
I'm confused by this example.
projects / rust.git / log