Auto merge of #28331 - semarie:openbsd-configure-egcc, r=alexcrichton
under OpenBSD, it could be have present multiples versions of gcc compiler:
- gcc-4.2 (with patchs) : c/c++ compiler present in `/usr/bin`. It is unusable to build recent LLVM (so rustc too).
- gcc/g++ -4.9 : c/c++ compiler, installed as third-party with "ports" mechanism. The compiler is installed in `/usr/local` as `egcc` (and `eg++`).
this PR adds probing for `egcc` for `CFG_GCC`, if the first probed `gcc` is too old. It will set `CC` and `CXX` too, in order to pass the variables to LLVM configure if builded.
please note this PR is a first step in order to build rustc under OpenBSD with unpatched tree.
The phrase 'academic research' rubs me the wrong way. I have some concern about the role of this page and think it could be expanded to more than just academic papers and cleaned up a lot.
Auto merge of #28250 - durka:patch-7, r=steveklabnik
I took a stab at fixing #28064. Not sure if this all-features-in-one-example approach is the right one. Also I completely made up the terms "star globbing" and "brace expansion globbing" -- they are just called "glob-like syntax" in the reference.
Auto merge of #28297 - lifthrasiir:rustdoc-html-tweaks, r=alexcrichton
I have tested the result with w3m and I believe this is better than the current template. In detail:
- `section.sidebar` -> `nav.sidebar`, also added an unordered list.
- `div#help` -> `aside#help`, also added a hidden heading.
- The current crate is now emphasized in the sidebar.
Auto merge of #28198 - alexcrichton:from-raw-mut, r=aturon
Conventionally in C `*mut T` is a transfer of ownership where `*const T` is a
loan, so `*mut T` is likely the more appropriate return type for these
functions. Additionally, this more closely mirrors the APIs on `Box` for this
sort of functionality.
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!
Kang Seonghoon [Tue, 8 Sep 2015 15:46:44 +0000 (00:46 +0900)]
rustdoc: Tweak the main template and CSS for semantic mark-up.
- section.sidebar -> nav.sidebar, also added an unordered list.
- div#help -> aside#help, also added a hidden heading.
- the current crate is now emphasized in the sidebar.
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
projects / rust.git / log