This modifies the `configure` to set `CFG_ENABLE_CLANG=1` if `gcc` is actually `clang`. This is needed because OS X's clang enables warning on unused command line arguments. Our build system suppresses this by default, but when `CFG_ENABLE_CLANGE=0`, we do not. This causes one of the tests to fail. This patch changes rust to directly use clang, which fixes the build failure.
Closes#10811
Apple replaced gcc with clang, but kept around a stub gcc to call
clang. This adds a check in `configure` to detect when gcc is
really clang, and switch to using clang in this situation.
Closes#10811.
This makes sure we always run benchmarks even if they are predicted to
take a long time, so that we have some non-zero time to display
(although the error bars may be huge for particularly slow benchmarks).
Fixes#9532.
The problem was that std::run::Process::new() was unwrap()ing the result
of std::io::process::Process::new(), which returns None in the case
where the io_error condition is raised to signal failure to start the
process.
Have std::run::Process::new() similarly return an Option\<run::Process\>
to reflect the fact that a subprocess might have failed to start. Update
utility functions run::process_status() and run::process_output() to
return Option\<ProcessExit\> and Option\<ProcessOutput\>, respectively.
Various parts of librustc and librustpkg needed to be updated to reflect
these API changes.
closes#10754
The problem was that std::run::Process::new() was unwrap()ing the result
of std::io::process::Process::new(), which returns None in the case
where the io_error condition is raised to signal failure to start the
process.
Have std::run::Process::new() similarly return an Option<run::Process>
to reflect the fact that a subprocess might have failed to start. Update
utility functions run::process_status() and run::process_output() to
return Option<ProcessExit> and Option<ProcessOutput>, respectively.
Various parts of librustc and librustpkg needed to be updated to reflect
these API changes.
closes#10754
rustpkg assumes library files to be in a directory called `lib`, but on Windows they are instead in the `bin` directory. This patch changes nothing on Unix system, since `libdir()` returns `"lib"` there.
improvements:
- no managed box
- no virtual calls
- no useless copy
- optimizations (bisect is slower, limit tests, BufferedWriter...)
- pass shootout test
- 10 times faster
rustdoc:
- fix search-bar layout
doc: CSS:
- switch to native pandoc toc depth
- rm some dead code
- clamp width to be readable (we're not Wikipedia!)
- don't background-color titles, it's bloating
- make syntax-highlighting colors inline with rust-lang.org
- space indents
@alexcrichton
When performing LTO, the rust compiler has an opportunity to completely strip
all landing pads in all dependent libraries. I've modified the LTO pass to
recognize the -Z no-landing-pads option when also running an LTO pass to flag
everything in LLVM as nothrow. I've verified that this prevents any and all
invoke instructions from being emitted.
I believe that this is one of our best options for moving forward with
accomodating use-cases where unwinding doesn't really make sense. This will
allow libraries to be built with landing pads by default but allow usage of them
in contexts where landing pads aren't necessary.
Turns out that one some platforms the ar/ranlib tool will die with an assertion
if the file being added doesn't actually have any symbols (or if it's just not
an object file presumably).
This functionality is already all exercised on the bots, it just turns out that
the bots don't have an ar tool which dies in this situation, so it's difficult
for me to add a test.
Closes#10907
This makes sure we always run benchmarks even if they are predicted to
take a long time, so that we have some non-zero time to display
(although the error bars may be huge for particularly slow benchmarks).
Fixes#9532.
