The ARM equivalents of the AArch64 are annoyingly more complicated (and some of the AArch64 ones are too).
I think I've got exposed all the x86 intrinsics from SSE to AVX2 now (at least, the ones that LLVM implements as callable intrinsics).
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
Also, fix a few whitespace issues in build.rs.
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).
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.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1212-line-endings.mdCloses#28032
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.
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.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1212-line-endings.mdCloses#28032
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
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.
r? @steveklabnik
@bors: r+ rollup
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.
This adds missing `?` marks to productions for loops and break/continue.
It also adds missing option label to while let loop.
Note that '[' foo ']' means grouping in BNF, and '?' is used for possible missing items.
r? @steveklabnik
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.
r? @nikomatsakis
