auto merge of #7523 : huonw/rust/uppercase-statics-lint, r=cmr
Adds a lint for `static some_lowercase_name: uint = 1;`. Warning by default since it causes confusion, e.g. `static a: uint = 1; ... let a = 2;` => `error: only refutable patterns allowed here`.
auto merge of #7474 : Seldaek/rust/clean-iter, r=thestinger
I think it's WIP - but I wanted to ask for feedback (/cc @thestinger)
I had to move the impl of FromIter for vec into extra::iter because I don't think std can depend on extra, but that's a bit messed up. Similarly some FromIter uses are gone now, not sure if this is fixable or if I made a complete mess here..
Niko Matsakis [Thu, 6 Jun 2013 01:04:07 +0000 (21:04 -0400)]
Correct handling of if/match, and make explicit computation of
common supertypes.
This was breaking with the change to regions because of the
(now incorrect) assumpton that our inference code makes,
which is that if a <: b succeeds, there is no need to compute
the LUB/GLB.
Niko Matsakis [Fri, 24 May 2013 01:37:37 +0000 (21:37 -0400)]
Defer reasoning about region relationships until after regionck.
This patch makes error handling for region inference failures more
uniform by not reporting *any* region errors until the reigon inference
step. This requires threading through more information about what
caused a region constraint, so that we can still give informative
error messages.
I have only taken partial advantage of this information: when region
inference fails, we still report the same error we always did, despite
the fact that we now know precisely what caused the various constriants
and what the region variable represents, which we did not know before.
This change is required not only to improve error messages but
because the region hierarchy is not in fact fully known until regionck,
because it is not clear where closure bodies fit in (our current
treatment is unsound). Moreover, the relationships between free variables
cannot be fully determined until type inference is otherwise complete.
auto merge of #7409 : alexcrichton/rust/threadsafe, r=cmr
@catamorphism, this re-enables threadsafe rustpkg tests, @brson this will fail unless the bots have LLVM rebuilt, so this is a good indicator of whether that happened or not.
auto merge of #7492 : yichoi/rust/fix_cleanllvm, r=luqmana
fix clean-llvm in mk/clean.mk for cross-compile
after #7442 landed, below error produced while android cross-compile
```
make[1]: *** No rule to make target `clean-llvmarm-linux-androideabi', needed by `clean-llvm'. Stop.
make[1]: Leaving directory `/home/yichoi/rust_latest/build'
make: *** [rustllvm/llvm-auto-clean-stamp] Error 2
```
bors [Sun, 30 Jun 2013 22:02:05 +0000 (15:02 -0700)]
auto merge of #7495 : thestinger/rust/exchange, r=cmr
With these changes, exchange allocator headers are never initialized, read or written to. Removing the header will now just involve updating the code in trans using an offset to only do it if the type contained is managed.
The only thing blocking removing the initialization of the last field in the header was ~fn since it uses it to store the dynamic size/types due to captures. I temporarily switched it to a `closure_exchange_alloc` lang item (it uses the same `exchange_free`) and #7496 is filed about removing that.
Since the `exchange_free` call is now inlined all over the codebase, I don't think we should have an assert for null. It doesn't currently ever happen, but it would be fine if we started generating code that did do it. The `exchange_free` function also had a comment declaring that it must not fail, but a regular assert would cause a failure. I also removed the atomic counter because valgrind can already find these leaks, and we have valgrind bots now.
Note that exchange free does not currently print an error an out-of-memory when it aborts, because our `io` code may allocate. We could probably get away with a `#[rust_stack]` call to a `stdio` function but it would be better to make a write system call.
bors [Sun, 30 Jun 2013 16:32:01 +0000 (09:32 -0700)]
auto merge of #7465 : alexcrichton/rust/issue-4432, r=cmr
This stems from trying to perform as few allocations as possible throughout the standard libraries.
This specializes the `ToStr` implementation for floats/ints separately because it's known that ints will have a maximum length (whereas floats could be very very large).
I also removed a `FIXME` to remove a malloc from the `to_str()` of floats in `repr.rs` because I think that this should be addressed elsewhere. I think that we may not be able to avoid it easily because floats can have such large representations, but regardless this should be a problem with the implementation of `float_to_str_bytes_common` now and not in the `Repr` module.
Huon Wilson [Sat, 29 Jun 2013 05:05:50 +0000 (15:05 +1000)]
Remove vec::{map, mapi, zip_map} and the methods, except for .map, since this
is very common, and the replacement (.iter().transform().collect()) is very
ugly.
Daniel Micay [Sun, 30 Jun 2013 02:35:04 +0000 (22:35 -0400)]
simplify the exchange allocator
* stop using an atomic counter, this has a significant cost and
valgrind will already catch these leaks
* remove the extra layer of function calls
* remove the assert of non-null in free, freeing null is well defined
but throwing a failure from free will not be
* stop initializing the `prev`/`next` pointers
* abort on out-of-memory, failing won't necessarily work
bors [Sun, 30 Jun 2013 04:13:31 +0000 (21:13 -0700)]
auto merge of #7475 : Seldaek/rust/fixsplit, r=cmr
I almost got locked out of my machine because I misunderstood the purpose of the function and called it with a limit of uint::max_value, which turned this function into an almost endless loop.
bors [Sat, 29 Jun 2013 23:46:32 +0000 (16:46 -0700)]
auto merge of #7452 : dotdash/rust/self_indirection, r=cmr
Currently we pass all "self" arguments by reference, for the pointer
variants this means that we end up with double indirection which causes
a unnecessary performance hit.
The fix itself is pretty straight-forward and just means that "self"
needs to be handled like any other argument, except for by-value "self"
which still needs to be passed by reference. This is because
non-pointer types can't just be stuffed into the environment slot which
is used to pass "self".
What made things tricky is that there was also a bug in the typechecker
where the method map entries are created. For type impls, that stored
the base type instead of the actual self-type in the method map, e.g.
Foo instead of &Foo for &self. That worked with pass-by-reference, but
fails with pass-by-value which needs the real type.
Code that makes use of methods seems to be about 10% faster with this
change. Also, build times are reduced by about 4%.
bors [Sat, 29 Jun 2013 19:02:05 +0000 (12:02 -0700)]
auto merge of #7342 : alexcrichton/rust/assort-cleanup, r=cmr
This removes usage of `&const` throughout the standard libraries/compiler, and it removes some extraneous fields in the AST now that unique boxes always inherit their mutability.
Björn Steinbrink [Thu, 27 Jun 2013 23:40:27 +0000 (01:40 +0200)]
Avoid double indirection for the "self" arg in methods
Currently we pass all "self" arguments by reference, for the pointer
variants this means that we end up with double indirection which causes
a unnecessary performance hit.
The fix itself is pretty straight-forward and just means that "self"
needs to be handled like any other argument, except for by-value "self"
which still needs to be passed by reference. This is because
non-pointer types can't just be stuffed into the environment slot which
is used to pass "self".
What made things tricky is that there was also a bug in the typechecker
where the method map entries are created. For type impls, that stored
the base type instead of the actual self-type in the method map, e.g.
Foo instead of &Foo for &self. That worked with pass-by-reference, but
fails with pass-by-value which needs the real type.
Code that makes use of methods seems to be about 10% faster with this
change. Also, build times are reduced by about 4%.
Björn Steinbrink [Sat, 29 Jun 2013 15:45:59 +0000 (17:45 +0200)]
Fix handling of temp cleanups for the "self" argument
The code that tried to revoke the cleanup for the self argument tried
to use "llself" to do so, but the cleanup might actually be registered
with a different ValueRef due to e.g. casting. Currently, this is
worked around by early revocation of the cleanup for self in
trans_self_arg.
To handle this correctly, we have to put the ValueRef for the cleanup
into the MethodData, so trans_call_inner can use it to revoke the
cleanup when it's actually supposed to.