Previously we were actually overwriting `CFG_{HOST,TARGET,BUILD}` with `CFG_{HOST,TARGET,BUILD}_TRIPLE(S)` since configure tested for the legacy one by checking if it was empty which would never be the case. That meant it wouldn't split up multiple triples and just treat it as one long triple.
This pull also fixes the rules that were changed when librustuv was added to use the right CFG_ vars and removes the legacy flags.
Allows an enum with a discriminant to use any of the primitive integer types to store it. By default the smallest usable type is chosen, but this can be overridden with an attribute: `#[repr(int)]` etc., or `#[repr(C)]` to match the target's C ABI for the equivalent C enum.
Also adds a lint pass for using non-FFI safe enums in extern declarations, checks that specified discriminants can be stored in the specified type if any, and fixes assorted code that was assuming int.
The actual fix would be to make rustpkg use `rustc::monitor` so it picks
up anything special that rustc needs, but for now let's keep the tests
from breaking.
There are a few reasons that this is a desirable move to take:
1. Proof of concept that a third party event loop is possible
2. Clear separation of responsibility between rt::io and the uv-backend
3. Enforce in the future that the event loop is "pluggable" and replacable
Here's a quick summary of the points of this pull request which make this
possible:
* Two new lang items were introduced: event_loop, and event_loop_factory.
The idea of a "factory" is to define a function which can be called with no
arguments and will return the new event loop as a trait object. This factory
is emitted to the crate map when building an executable. The factory doesn't
have to exist, and when it doesn't then an empty slot is in the crate map and
a basic event loop with no I/O support is provided to the runtime.
* When building an executable, then the rustuv crate will be linked by default
(providing a default implementation of the event loop) via a similar method to
injecting a dependency on libstd. This is currently the only location where
the rustuv crate is ever linked.
* There is a new #[no_uv] attribute (implied by #[no_std]) which denies
implicitly linking to rustuv by default
Closes#5019
This drops more of the old C++ runtime to rather be written in rust. A few
features were lost along the way, but hopefully not too many. The main loss is
that there are no longer backtraces associated with allocations (rust doesn't
have a way of acquiring those just yet). Other than that though, I believe that
the rest of the debugging utilities made their way over into rust.
Closes#8704
This drops more of the old C++ runtime to rather be written in rust. A few
features were lost along the way, but hopefully not too many. The main loss is
that there are no longer backtraces associated with allocations (rust doesn't
have a way of acquiring those just yet). Other than that though, I believe that
the rest of the debugging utilities made their way over into rust.
Closes#8704
api::install_pkg now accepts an argument that's a list of
(kind, path) dependency pairs. This allows custom package scripts to
declare C dependencies, as is demonstrated in
rustpkg::tests::test_c_dependency_ok.
Closes#6403
OS X 10.9's linker has a bug that results in it failing to preserve
DWARF unwind information when passed the -no_compact_unwind flag.
This flag is passed on OS X because the unwind information for
__morestack cannot be represented by the compact unwind format.
We can work around this problem by using a more targeted approach
to disabling compact unwind information. The OS X linker looks for
a particular pattern in the DWARF unwind information and will not
attempt to convert the unwind information to the compact format.
The pattern in question is the return address register being saved
twice to the same location.
Fixes#6849.
OS X 10.9's linker has a bug that results in it failing to preserve
DWARF unwind information when passed the -no_compact_unwind flag.
This flag is passed on OS X because the unwind information for
__morestack cannot be represented by the compact unwind format.
We can work around this problem by using a more targeted approach
to disabling compact unwind information. The OS X linker looks for
a particular pattern in the DWARF unwind information and will not
attempt to convert the unwind information to the compact format.
The pattern in question is the return address register being saved
twice to the same location.
Fixes#6849.
It seems like rusti has been removed, except for one reference in one Makefile. This reference breaks building rust on my computer because the "all-target" rule has rusti as a target.
~~~~
make: *** No rule to make target `x86_64-unknown-linux-gnu/stage2/bin/rusti', needed by `all-target-x86_64-unknown-linux-gnu-host-x86_64-unknown-linux-gnu'. Stop.
~~~~
Removing this line fixes things for me.
This commit re-introduces the functionality of __morestack in a way that it was
not originally anticipated. Rust does not currently have segmented stacks,
rather just large stack segments. We do not detect when these stack segments are
overrun currently, but this commit leverages __morestack in order to check this.
This commit purges a lot of the old __morestack and stack limit C++
functionality, migrating the necessary chunks to rust. The stack limit is now
entirely maintained in rust, and the "main logic bits" of __morestack are now
also implemented in rust as well.
I put my best effort into validating that this currently builds and runs successfully on osx and linux 32/64 bit, but I was unable to get this working on windows. We never did have unwinding through __morestack frames, and although I tried poking at it for a bit, I was unable to understand why we don't get unwinding right now.
A focus of this commit is to implement as much of the logic in rust as possible. This involved some liberal usage of `no_split_stack` in various locations, along with some use of the `asm!` macro (scary). I modified a bit of C++ to stop calling `record_sp_limit` because this is no longer defined in C++, rather in rust.
Another consequence of this commit is that `thread_local_storage::{get, set}` must both be flagged with `#[rust_stack]`. I've briefly looked at the implementations on osx/linux/windows to ensure that they're pretty small stacks, and I'm pretty sure that they're definitely less than 20K stacks, so we probably don't have a lot to worry about.
Other things worthy of note:
* The default stack size is now 4MB instead of 2MB. This is so that when we request 2MB to call a C function you don't immediately overflow because you have consumed any stack at all.
* `asm!` is actually pretty cool, maybe we could actually define context switching with it?
* I wanted to add links to the internet about all this jazz of storing information in TLS, but I was only able to find a link for the windows implementation. Otherwise my suggestion is just "disassemble on that arch and see what happens"
* I put my best effort forward on arm/mips to tweak __morestack correctly, we have no ability to test this so an extra set of eyes would be useful on these spots.
* This is all really tricky stuff, so I tried to put as many comments as I thought were necessary, but if anything is still unclear (or I completely forgot to take something into account), I'm willing to write more!
This commit resumes management of the stack boundaries and limits when switching
between tasks. This additionally leverages the __morestack function to run code
on "stack overflow". The current behavior is to abort the process, but this is
probably not the best behavior in the long term (for deails, see the comment I
wrote up in the stack exhaustion routine).
As discovered in #9925, it turns out that we weren't using jemalloc on most
platforms. Additionally, on some platforms we were using it incorrectly and
mismatching the libc version of malloc with the jemalloc version of malloc.
Additionally, it's not clear that using jemalloc is indeed a large performance
win in particular situtations. This could be due to building jemalloc
incorrectly, or possibly due to using jemalloc incorrectly, but it is unclear at
this time.
Until jemalloc can be confirmed to integrate correctly on all platforms and has
verifiable large performance wins on platforms as well, it shouldn't be part of
the default build process. It should still be available for use via the
LD_PRELOAD trick on various architectures, but using it as the default allocator
for everything would require guaranteeing that it works in all situtations,
which it currently doesn't.
Closes#9925
Sadly, there's a lack of resources for maintaining the `rust` tool,
and we decided in the 2013-10-08 Rust team meeting that it's better
to remove it altogether than to leave it in a broken state.
This deletion is without prejudice. If a person or people appear who
would like to maintain the tool, we will probably be happy to
resurrect it!
Closes#9775
This lets the C++ code in the rt handle the (slightly) tricky parts of
random number generation: e.g. error detection/handling, and using the
values of the `#define`d options to the various functions.
This will make sure that system files that rust binaries depend on in Windows get packaged into stage0 snapshots as well as into Windows installer.
Currently these include `libgcc_s_dw2-1.dll`, `libstdc++-6.dll` and `libpthread-2.dll`. Note that the latter will need to be changed to `pthreadGC2.dll` once Windows build bots get upgraded to mingw 4.0
Closes#9252Closes#5878Closes#9218Closes#5712
This change adds --soft-float option for generating
software floating point library calls.
It also implies using soft float ABI, that is the same as llc.
It is useful for targets that have no FPU.
This modifies the command-line usage of rustdoc to intake its own JSON output as
well as a rust source file. This also alters the command line from
`rustdoc input file` to `rustdoc file` with the input/output formats specified
as -r and -w, respectively.
When using a JSON input, no passes or plugins are re-run over the json, instead
the output is generated directly from the JSON that was provided. Passes and
plugins are still run on rust source input, however.
This change adds -Z soft-float option for generating
software floating point library calls.
It also implies using soft float ABI, that is the same as llc.
It is useful for targets that have no FPU.
They're getting smaller each time though!
The highlight of this round is source files in documentation. Still trying to figure out the best syntax-highlighting solution.
This purges doc/{std,extra} entirely during a `make clean` instead of just the
html files in some top level directories. This should help old documentation
from showing up on static.rust-lang.org
This purges doc/{std,extra} entirely during a `make clean` instead of just the
html files in some top level directories. This should help old documentation
from showing up on static.rust-lang.org
Three things in this commit:
1. Actually build the rustpkg tutorial. I didn't know I needed this when
I first wrote it.
2. Link to it rather than the manual from the
tutorial.
3. Update the headers: most of them were one level too deeply
nested.
Removes old rustdoc, moves rustdoc_ng into its place instead (plus drops the _ng
suffix). Also shreds all reference to rustdoc_ng from the Makefile rules.
This large commit implements and `html` output option for rustdoc_ng. The
executable has been altered to be invoked as "rustdoc_ng html <crate>" and
it will dump everything into the local "doc" directory. JSON can still be
generated by changing 'html' to 'json'.
This also fixes a number of bugs in rustdoc_ng relating to comment stripping,
along with some other various issues that I found along the way.
The `make doc` command has been altered to generate the new documentation into
the `doc/ng/$(CRATE)` directories.
Many people will be very confused that their debug! statements aren't working
when they first use rust only to learn that they should have been building with
`--cfg debug` the entire time. This inverts the meaning of the flag to instead
of enabling debug statements, now it disables debug statements.
This way the default behavior is a bit more reasonable, and requires less
end-user configuration. Furthermore, this turns on debug by default when
building the rustc compiler.
Some of the functions could be converted to rust, but the functions dealing with
signals were moved to rust_builtin.cpp instead (no reason to keep the original
file around for one function).
Closes#2674
Because less C++ is better C++!
Some of the functions could be converted to rust, but the functions dealing with
signals were moved to rust_builtin.cpp instead (no reason to keep the original
file around for one function).
Closes#2674
This patch fixes some errors of MIPS target, however, MIPS C ABI is still broken. I will send another PR to fix the problem.
Because MIPS target has no "generic" CPU name, I add --target-cpu and --target-feature to RUST_FLAGS. In order to workaround the "compact frame descriptions incompatible with DWARF2 .eh_frame" problem, the linker I used is CXX but not CC.
Now rustdoc_ng will be built as both a binary and a library (using the same
rules as all the other binaries that rust has). Furthermore, this will also
start building rustdoc_ng unit tests (and running them).
Note that some `rustdoc_ng` tests were removed, but @cmr says they weren't supposed to be there in the first place. The rustdoc_ng code should also be included in `make install` and `make dist` now.
This works by adding this directory to GCC include search path before mingw system headers directories,
so we can intercept their inclusions and add missing definitions without having to modify files in mingw/include.
Now rustdoc_ng will be built as both a binary and a library (using the same
rules as all the other binaries that rust has). Furthermore, this will also
start building rustdoc_ng unit tests (and running them).
This is a reopening of the libuv-upgrade part of #8645. Hopefully this won't
cause random segfaults all over the place. The windows regression in testing
should also be fixed (it shouldn't build the whole compiler twice).
A notable difference from before is that gyp is now a git submodule instead of
always git-cloned at make time. This allows bundling for releases more easily.
Closes#8850
The new glob tests created tmp/glob-tests as a directory, but the never removed
it. The `make clean` target then attempted to `rm -f` on this, but it couldn't
remove the directory. This both changes the clean target to `rm -rf` tmp files,
and also alters the tests to delete the directory that all the files are added
into.
This should make benchmarks easier to understand. But, it doesn't work.
BENCH_RS in mk/tests.mk has everything, from what I can tell in remake, but
only those that are direct children of src/test/bench get build and run.
@graydon, can you lend your expertise? I can't make heads or tails of this
makefile.
It turns out that gyp (libuv's new build system) wants x64 for a 64-bit x86
architecture and ia32 for a 32-bit architecture, so this performs the relevant
mapping and then invokes libuv's configure script with the appropriate target
architecture.
This can be verified by running make with VERBOSE=1 and seeing that beforehand
on a 64-bit build libuv was passed "-arch i386" and now it's passed
"-arch x86_64"
Closes#8826
The syntax of the script requires python < 3, and so does our build system so we
can just use CFG_PYTHON to run the script. This prevents build failures where
`python` is actually python3 or later.
