| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
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.
|
|
This is part of the numeric trait reform tracked on issue #4819
|
|
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.
|
|
uninit() would result in potentially running a destructor on arbitrary
memory if the Ord implementation throws
|
|
|
|
|
|
|
|
- vec.rs :add 'each2_mut function'
- testsuit : run-pass/vec-each2_mut.rs
|
|
uninit() would result in potentially running a destructor on arbitrary
memory if the Ord implementation throws
|
|
Also fix up all the fallout elsewhere throughout core. It's really nice being
able to have the prelude.
|
|
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`.
|
|
r? @graydon
|
|
|
|
|
|
|
|
|
|
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 :smile:
|
|
|
|
|
|
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?
|
|
|
|
|
|
__attribute__((...)).
|
|
When trying to import nonexistent items from existing modules, specify that
that is what happened, rather than just reporting "unresolved name".
|
|
Instead link against the built libraries and directly invoke those.
Closes #5387
|
|
|
|
|
|
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.
|
|
|
|
|
|
literals (possibly with a minus).
This had very minimal fallout.
|
|
|
|
|
|
In this commit I added a useful utility type, named Void, that encapsulates the
doable but annoying job of creating an uninhabited type. As well, a function on
that type, named absurd, was created which is useful for ignoring the result of
matching on that type. No unit tests were created because it is not possible to
create an instance of this type to test the usage of.
This type is useful because it is like NonCopyable in that it can be used to
create a type with special characteristics without special bloat. For instance,
instead of typing pub struct PhantomType { priv contents : () } for each void
type one may want to use one can simply type pub struct PhantomType (Void);.
This type make such special cases much easier to write.
|
|
|
|
|
|
|
|
Instead link against the built libraries and directly invoke those.
|
|
intrinsics.
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
|
|
Implemented to_str() for HashMap and HashSet
Added tests.
Minor formatting and stylistic cleanups.
|
|
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.
|
|
All tests pass now.
|
|
|
|
`BigUint::is_even()` didn't return correct value.
|
|
Just cleaning up warnings.
|
|
|
