Peter Reid [Sat, 5 Sep 2015 02:10:39 +0000 (22:10 -0400)]
Fix for issue #28012: pow overflow inconsistency
Overflows in integer pow() computations would be missed if they
preceded a 0 bit of the exponent being processed. This made
calls such as 2i32.pow(1024) not trigger an overflow.
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.
projects / rust.git / log