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.
The default versions (atomic_load and atomic_store) are sequentially consistent.
The atomic_load_acq intrinsic acquires as described in [1].
The atomic_store_rel intrinsic releases as described in [1].
[1]: http://llvm.org/docs/Atomics.html
r? @nikomatsakis In #6319, several people mentioned they ran into a "computing
fictitious type" ICE in trans. This turns out to be because some
of my recent changes to typeck::check::_match resulted in type errors
getting reported with ty_err as the expected type, which meant the errors
were suppressed, and typechecking incorrectly succeeded (since the errors
weren't recorded).
Changed the error messages in these cases not to use an expected type at all,
rather, printing out a string describing the type that was expected (which is
what the code originally did). The result is a bit repetitive and the
proliferation of error-reporting functions in typeck::infer is a bit annoying,
but I thought it was important to fix this now; more cleanup can happen later.
In #6319, several people mentioned they ran into a "computing
fictitious type" ICE in trans. This turns out to be because some
of my recent changes to typeck::check::_match resulted in type errors
getting reported with ty_err as the expected type, which meant the errors
were suppressed, and typechecking incorrectly succeeded (since the errors
weren't recorded).
Changed the error messages in these cases not to use an expected type at all,
rather, printing out a string describing the type that was expected (which is
what the code originally did). The result is a bit repetitive and the
proliferation of error-reporting functions in typeck::infer is a bit annoying,
but I thought it was important to fix this now; more cleanup can happen later.
**Caveat**: With the current commit, this check only works for `match`s, the checks (incorrectly) do not run for patterns in `let`s, and invalid/unsafe code compiles.
I don't know how to fix this, I experimented with some things to try to make let patterns and match patterns run on the same code (since this would presumably fix many of the other unsoundness issues of let-patterns, e.g. #6225), but I don't understand enough of the code. (I think I heard someone talking about a fix for `let` being in progress?)
Fixes#6344 and #6341.
This allows macros to create tests and benchmarks.
This is possibly unsound (I've got no idea, but it seemed to work), and being able to programmatically generate benchmarks to compare several implementations of similar algorithms is nice.
This fixes the issue described in #4202.
From what I understood of the code, when we reexport a trait in a submodule using e.g. "pub use foo::SomeTrait", we were not previously making an effort to reexport the static methods on that trait.
I'm new to the Rust code base (and the Rust language itself) so my approach may not be kosher, but this patch works by changing the encoder to include the static methods associated with traits.
I couldn't see any tests for this area of the code, so I didn't really have any examples to go by. If tests are needed, I'm happy to work through that if I can get some assistance to do so.
Closes#6183.
The first commit changes the compiler's method of treating a `for` loop, and all the remaining commits are just dealing with the fallout.
The biggest fallout was the `IterBytes` trait, although it's really a whole lot nicer now because all of the `iter_bytes_XX` methods are just and-ed together. Sadly there was a huge amount of stuff that's `cfg(stage0)` gated, but whoever lands the next snapshot is going to have a lot of fun deleting all this code!
&str can be turned into @~str on demand, using to_owned(), so for
strings, we can create a specialized interner that accepts &str for
intern() and find() but stores and returns @~str.
This improves error reporting for the following class of imports:
```rust
use foo::bar;
```
Where foo, the topmost module, is unresolved. It now results in:
```text
/tmp/foo.rs:1:4: 1:7 error: unresolved import. perhapsyou forgot an 'extern mod foo'?
/tmp/foo.rs:1 use foo::bar;
^~~
/tmp/foo.rs:1:4: 1:12 error: failed to resolve import: foo::bar
/tmp/foo.rs:1 use foo::bar;
^~~~~~~~
error: failed to resolve imports
error: aborting due to 3 previous errors
```
This is the first of a series of changes I plan on making to unresolved name error messages.
Use a bitset to represent built-in bounds. There are several places in the language where only builtin bounds (aka kinds) will be accepted, e.g. on closures, destructor type parameters perhaps, and on trait types.
r? @brson
