r? @nikomatsakis The way we deal with unreachable expressions in trans is pretty ad hoc,
but this at least doesn't make it worse, and eliminates the LLVM
assertion failure reported in #5741.
The way we deal with unreachable expressions in trans is pretty ad hoc,
but this at least doesn't make it worse, and eliminates the LLVM
assertion failure reported in #5741.
This adds a lint mode for detecting unnecessary allocations on the heap. This isn't super fancy, currently it only has two rules
1. For a function's arguments, if you allocate a `[~|@]str` literal, when the type of the argument is a `&str`, emit a warning.
2. For the same case, emit warnings for boxed vectors when slices are required.
After adding the lint, I rampaged through the libraries and removed all the unnecessary allocations I could find.
I don't have a strong opinion on the function vs. method, but there's no point in having both. I'd like to make a `repeat` adaptor like Python/Haskell for turning a value into an infinite stream of the value, so this has to at least be renamed.
Replace all instances of #[auto_*code] with the appropriate #[deriving] attribute
and remove the majority of the actual auto_* code, leaving stubs to refer the user to
the new syntax.
Also, moves the useful contents of auto_encode.rs to more appropriate spots: tests and comments to deriving/encodable.rs, and the ExtCtxtMethods trait to build.rs (unused so far, but the method syntax might be nicer than using the mk_* fns in many instances).
Replace all instances of #[auto_*code] with the appropriate #[deriving] attribute
and remove the majority of the actual code, leaving stubs to refer the user to
the new syntax.
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!
