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.
Auto merge of #28182 - jackwilsonv:patch-2, r=steveklabnik
r? @steveklabnik
##### About the `struct` section specifically:
I wasn't sure how you'd feel about the first instance since it was originally capitalized, happy to change it back if you think that's better.
Also, I left 'tuple struct' as is since together it isn't a keyword. The first instance currently has single quotes but the others have nothing. I think that feels right.
##### Generally:
I'm working through the book now and I'm happy to keep updating this branch with any formatting tweaks or updates I find if that's easier for you guys, otherwise I'll just create smaller PRs as I go. Just let me know.
Ariel Ben-Yehuda [Mon, 24 Aug 2015 20:27:00 +0000 (23:27 +0300)]
consolidate type-variable handling in assemble_candidates
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.
Auto merge of #28130 - alexcrichton:fix-msvc-static-tls-dtor, r=brson
Running TLS destructors for a MSVC Windows binary requires the linker doesn't
elide the `_tls_used` or `__tls_used` symbols (depending on the architecture).
This is currently achieved via a `#[link_args]` hack but this only works for
dynamically linked binaries because the link arguments aren't propagated to
statically linked binaries.
This commit alters the strategy to instead emit a volatile load from those
symbols so LLVM can't elide it, forcing the reference to the symbol to stay
alive as long as the callback function stays alive (which we've made sure of
with the `#[linkage]` attribute).
Alex Crichton [Mon, 31 Aug 2015 17:28:07 +0000 (10:28 -0700)]
std: Run TLS destructors in a statically linked binary
Running TLS destructors for a MSVC Windows binary requires the linker doesn't
elide the `_tls_used` or `__tls_used` symbols (depending on the architecture).
This is currently achieved via a `#[link_args]` hack but this only works for
dynamically linked binaries because the link arguments aren't propagated to
statically linked binaries.
This commit alters the strategy to instead emit a volatile load from those
symbols so LLVM can't elide it, forcing the reference to the symbol to stay
alive as long as the callback function stays alive (which we've made sure of
with the `#[linkage]` attribute).
projects / rust.git / log