These few commits address a few existing issues:
* #5469 - adding regression tests for `rusti`. This adds unit tests to the `rusti.rc` file (which needed some reorganization of the Makefile, see the first commit message). These are super-simple right now, and sadly can't test the output of the tests. I worked for a bit on making a compiletest version of the rusti tests, but I ended up hitting something which blocked me, although I've forgotten it by this point.
* #5937 - regression test added, and it's fixed
* #5803 - just doesn't appear to happen any more
* #5784 - it's no longer broken, and it no longer spits out warnings about unused variables.
I also did some investigation into #5774, and you may want to read the comment I left on the bug. The gist of the situation is that C++ exceptions across JIT code don't look like they're working, even though they [should be working](3aa1122ec2/src/rustllvm/RustWrapper.cpp (L387)). If anyone has any insight on this, that would be awesome!
* They didn't work before, because the location of the tests caused the
'sysroot' option to crate lookup to be wrong for finding the correct stage's
core/std libraries. This moves the compiled tests from the $host/test
directory into a $host/$stage/test directory. This means that the sysroot will
be correct and the core/std libraries can actually be found
* The LLVM bindings apparently aren't threadsafe, so we can't run multiple tests
in parallel.
This closes#5204 and #6421.
This also removes the `vecs_implicitly_copyable` lint (although now reading #6421, this may not be desired?). If we want to leave it in, it at least removes it from the compiler.
fail!() used to require owned strings but can handle static strings
now. Also, it can pass its arguments to fmt!() on its own, no need for
the caller to call fmt!() itself.
fail!() used to require owned strings but can handle static strings
now. Also, it can pass its arguments to fmt!() on its own, no need for
the caller to call fmt!() itself.
Also fix up all the fallout elsewhere throughout core. It's really nice being
able to have the prelude.
I'm not quite sure how resolution works with traits, but it seems to me like the public imports at the top-level of the core crate were leaking into the sub-crates, but that could also be working as intended. Regardless, things compile without the re-exports now.
r? @pcwalton
* Move `SharedMutableState`, `LittleLock`, and `Exclusive` from `core::unstable` to `core::unstable::sync`
* Modernize the `SharedMutableState` interface with methods
* Rename `SharedMutableState` to `UnsafeAtomicRcBox` to match `RcBox`.
When trying to import nonexistent items from existing modules, specify that
that is what happened, rather than just reporting "unresolved name".
Ideally the error would be reported on the span of the import... but I do not see a way to get a span there. Help appreciated 😄
This pull request adds 4 atomic intrinsics to the compiler, in preparation for #5042.
* `atomic_load(src: &int) -> int` performs an atomic sequentially consistent load.
* `atomic_load_acq(src: &int) -> int` performs an atomic acquiring load.
* `atomic_store(dst: &mut int, val: int)` performs an atomic sequentially consistent store.
* `atomic_store_rel(dst: &mut int, val: int)` performs an atomic releasing store.
For more information about the whole acquire/release thing: http://llvm.org/docs/Atomics.html
r?
Every unresolved import is reported. An additional error message isn't useful
and obscures (imo) the real errors: I need to take it into account when
looking at the error count.
