Auto merge of #28173 - alexcrichton:llvm-37, r=brson
This updates the jemalloc and LLVM submodules to the recently released 4.0.0 and 3.7 versions. There's no breakage on the LLVM side of things because we had already been tracking the 3.7 release branch for awhile and no breakage was introduced, and jemalloc apparently is stable enough that nothing broke!
Auto merge of #28287 - llogiq:clippy, r=Manishearth
It's a large number of small improvements to the code, mostly readability-related, but removing closures and replacing `str::to_string()` with `.to_owned()` should also positively affect performance.
r? @Manishearth (once it compiles, of course :smile:)
Auto merge of #28285 - steveklabnik:split_at_idiom, r=arielb1
Generally, including everything that makes an unsafe block safe in the
block is good style. Since the assert! is what makes this safe, it
should go inside the block. I also added a few bits of whitespace.
This is of course, a little style thing, so no worries if we don't want this patch.
Steve Klabnik [Mon, 7 Sep 2015 14:16:57 +0000 (10:16 -0400)]
Use unsafe more idiomatically
Generally, including everything that makes an unsafe block safe in the
block is good style. Since the assert! is what makes this safe, it
should go inside the block. I also added a few bits of whitespace.
This PR contains a new crate, `rustc_mir`, which implements the MIR as specified in the RFC (more or less). There are no targeted unit tests at the moment, as I didn't decide what kind of infrastructure would be best and didn't take the time to implement it.
~~NB: In packaging up this PR, I realized that MIR construction code is not triggering for methods right now, I think it's only for fixed fns. I'll push a fix for this soon. Hopefully it doesn't stop any crates from building. :)~~ Fixed. Everything still seems to work.
However, the MIR construction code (`librustc_mir/build`) is intentionally quite distinct from the code which munges the compiler's data structures (`librustc_mir/tcx`). The interface between the two is the `HIR` trait (`librustc_mir/hir`). To avoid confusion with @nrc's work, perhaps a better name for this trait is warranted, although ultimately this trait *will* be connected to the HIR, I imagine, so in a way the name is perfect. Anyway, I'm open to suggestions. The initial motivation for this split was to allow for the MIR construction code to be unit-tested. But while I didn't end up writing unit tests (yet), I did find the split made the code immensely easier to think about, since the messiness of our existing system, with its myriad hashtables, punning, and so forth, is confined to one part, which simply transforms to a more fully explicit AST-like form. I tried to separate out the commits somewhat, but since this mostly new code, it mostly winds up coming in one fell swoop in the MIR commit.
Quick guide to the MIR crate:
- `repr.rs` defines the MIR itself; each MIR instance is parameterized by some HIR `H`
- `build/` is the MIR construction code, parameterized by a particular HIR
- `hir/` is the definition of the HIR interface
- `tcx/` is the impl of the HIR interface for the tcx
- `dump.rs` is the minimal compiler pass that invokes the HIR
One open question:
- In the HIR trait, I used exclusively struct-like variants. I found I like this more, since things have names. Should I convert the repr code?
```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