- 15 2月, 2014 19 次提交
-
-
由 Brian Anderson 提交于
-
由 Brian Anderson 提交于
-
由 Brian Anderson 提交于
Because the build system treats Makefile.in and the .mk files slightly differently (.in is copied, .mk are included), this makes the system more uniform. Fewer build system changes will require a complete reconfigure.
-
由 Brian Anderson 提交于
This way of doing snapshots hasn't been used since 2011.
-
由 Brian Anderson 提交于
'make help' is implemented in a fairly ridiculous way, using awk to parse comments out of Makefile.in and displaying them.
-
由 bors 提交于
-
由 Kevin Ballard 提交于
-
由 Kevin Ballard 提交于
-
由 bors 提交于
Strip trait impls for types that are stripped either due to the strip-hidden or strip-private passes. This fixes the search index including trait methods on stripped structs (which breaks searching), and it also removes private types from the implementors list of a trait. Fixes #9981 and #11439.
-
由 bors 提交于
The last commit has the closed PRs
-
由 Kevin Ballard 提交于
-
由 Kevin Ballard 提交于
-
由 Alex Crichton 提交于
PRs closed as part of this: Closes #12212 r=alexcrichton Closes #12215 r=brson Closes #12246 r=pcwalton Closes #12247 r=cmr Closes #12251 r=brson Closes #12255 r=alexcrichton Closes #12257 r=alexcrichton Closes #12258 r=huonw Closes #12259 r=huonw Closes #12263 r=kballard Closes #12269 r=alexcrichton
-
由 Corey Richardson 提交于
-
由 Kevin Ballard 提交于
In the strip-hidden pass, record all types that were stripped, and make a second pass stripping all impls of traits for these types.
-
由 Kevin Ballard 提交于
In strip-private, also strip impls of traits for private types. This fixes the search index so searching for "drop", "eq", etc doesn't throw an exception.
-
由 Alex Crichton 提交于
Currently when you run `make -jN` it's likely that you'll remove compiler-rt and then it won't get cp'd back into the right place. I believe the reason for this is that the compiler-rt library target never got updated so make decided it never needed to copy the files back into place. The files were all there at the beginning of `make`, but then we may clean out the stage0 versions if we unzip the snapshot again.
-
由 bors 提交于
This will hopefully bring us closer to #11937. We're still using gcc's idea of "startup files", but this should prevent us from leaking in dependencies that we don't quite want (libgcc for example once compiler-rt is what we use).
-
由 Alex Crichton 提交于
This will hopefully bring us closer to #11937. We're still using gcc's idea of "startup files", but this should prevent us from leaking in dependencies that we don't quite want (libgcc for example once compiler-rt is what we use).
-
- 14 2月, 2014 21 次提交
-
-
由 Eduard Burtescu 提交于
-
由 Steven Fackler 提交于
Now that fold_item can return multiple items, this is pretty trivial. It also recursively expands generated items so ItemDecorators can generate items that are tagged with ItemDecorators! Closes #4913
-
由 Edward Wang 提交于
-
由 HeroesGrave 提交于
-
由 Dave Hodder 提交于
-
由 Flavio Percoco 提交于
-
由 Eduard Burtescu 提交于
-
由 Alex Crichton 提交于
When tests fail, their stdout and stderr is printed as part of the summary, but this helps suppress failure messages from #[should_fail] tests and generally clean up the output of the test runner.
-
由 lpy 提交于
-
由 bors 提交于
Includes an upstream commit by pcwalton to improve codegen of our enums getting moved around. This also introduces a new commit on top of our stack of patches to fix a mingw32 build issue. I have submitted the patch upstream: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140210/204653.html I verified that this builds on the try bots, which amazes me because I think that c++11 is turned on now, but I guess we're still lucky! Closes #10613 (pcwalton's patch landed) Closes #11992 (llvm has removed these options)
-
由 Alex Crichton 提交于
Includes an upstream commit by pcwalton to improve codegen of our enums getting moved around.
-
由 bors 提交于
The old method of building up a list of items and threading it through all of the decorators was unwieldy and not really scalable as non-deriving ItemDecorators become possible. The API is now that the decorator gets an immutable reference to the item it's attached to, and a callback that it can pass new items to. If we want to add syntax extensions that can modify the item they're attached to, we can add that later, but I think it'll have to be separate from ItemDecorator to avoid strange ordering issues. @huonw
-
由 bors 提交于
Fix some fall out from the big command line option changes.
-
由 bors 提交于
Any single-threaded task benchmark will spend a good chunk of time in `kqueue()` on osx and `epoll()` on linux, and the reason for this is that each time a task is terminated it will hit the syscall. When a task terminates, it context switches back to the scheduler thread, and the scheduler thread falls out of `run_sched_once` whenever it figures out that it did some work. If we know that `epoll()` will return nothing, then we can continue to do work locally (only while there's work to be done). We must fall back to `epoll()` whenever there's active I/O in order to check whether it's ready or not, but without that (which is largely the case in benchmarks), we can prevent the costly syscall and can get a nice speedup. I've separated the commits into preparation for this change and then the change itself, the last commit message has more details.
-
由 bors 提交于
-
由 Eduard Burtescu 提交于
-
由 Steven Fackler 提交于
The old method of building up a list of items and threading it through all of the decorators was unwieldy and not really scalable as non-deriving ItemDecorators become possible. The API is now that the decorator gets an immutable reference to the item it's attached to, and a callback that it can pass new items to. If we want to add syntax extensions that can modify the item they're attached to, we can add that later, but I think it'll have to be separate from ItemDecorator to avoid strange ordering issues.
-
由 bors 提交于
Android bot has been having some problems. A few details in the commits.
-
由 Brian Anderson 提交于
These seem to be causing iloops on the bots. Let's rather see the errors.
-
由 Brian Anderson 提交于
This is an attempt to isolate test failures on the bots. It may also eliminate problems with the emulators breaking by reducing the chance of OOM.
-
由 bors 提交于
These commits pick off some low-hanging fruit which were slowing down spawning green threads. The major speedup comes from fixing a bug in stack caching where we never used any cached stacks! The program I used to benchmark is at the end. It was compiled with `rustc --opt-level=3 bench.rs --test` and run as `RUST_THREADS=1 ./bench --bench`. I chose to use `RUST_THREADS=1` due to #11730 as the profiles I was getting interfered too much when all the schedulers were in play (and shouldn't be after #11730 is fixed). All of the units below are in ns/iter as reported by `--bench` (lower is better). | | green | native | raw | | ------------- | ----- | ------ | ------ | | osx before | 12699 | 24030 | 19734 | | linux before | 10223 | 125983 | 122647 | | osx after | 3847 | 25771 | 20835 | | linux after | 2631 | 135398 | 122765 | Note that this is *not* a benchmark of spawning green tasks vs native tasks. I put in the native numbers just to get a ballpark of where green tasks are. This is benchmark is *clearly* benefiting from stack caching. Also, OSX is clearly not 5x faster than linux, I think my VM is just much slower. All in all, this ended up being a nice 4x speedup for spawning a green task when you're using a cached stack. ```rust extern mod extra; extern mod native; use std::rt::thread::Thread; #[bench] fn green(bh: &mut extra::test::BenchHarness) { let (p, c) = SharedChan::new(); bh.iter(|| { let c = c.clone(); spawn(proc() { c.send(()); }); p.recv(); }); } #[bench] fn native(bh: &mut extra::test::BenchHarness) { let (p, c) = SharedChan::new(); bh.iter(|| { let c = c.clone(); native::task::spawn(proc() { c.send(()); }); p.recv(); }); } #[bench] fn raw(bh: &mut extra::test::BenchHarness) { bh.iter(|| { Thread::start(proc() {}).join() }); } ```
-