Daniel Micay [Fri, 18 Oct 2013 05:14:47 +0000 (01:14 -0400)]
add feature gate for managed boxes
I'll flip this on after doing a snapshot. This syntax may or may not
stay around, and managed boxes are currently not very useful. They have
the same overall performance characteristics as `std::rc::Rc`, but are
significantly slower, allocate larger boxes and hold onto the memory
beyond when it is needed due to lacking move semantics.
There are currently two useful aspects of the type:
* the dereference sugar, which we should implement for `Rc`
* the annihilator freeing cycles at the end of the task
bors [Tue, 22 Oct 2013 04:41:25 +0000 (21:41 -0700)]
auto merge of #9992 : astrieanna/rust/rm_rusti, r=alexcrichton
It seems like rusti has been removed, except for one reference in one Makefile. This reference breaks building rust on my computer because the "all-target" rule has rusti as a target.
~~~~
make: *** No rule to make target `x86_64-unknown-linux-gnu/stage2/bin/rusti', needed by `all-target-x86_64-unknown-linux-gnu-host-x86_64-unknown-linux-gnu'. Stop.
~~~~
bors [Tue, 22 Oct 2013 02:26:19 +0000 (19:26 -0700)]
auto merge of #9982 : danluu/rust/local_delc_xfail, r=brson
This patch is trivial, but it comes with a question. Does Mozilla need to own the copyright on code submitted to Rust?
The reason I ask is that, since the last time I submitted anything to a Mozilla project, I started working at Google, and they (by default) own the copyright on code that I write (even in my spare time). There's a process to assign copyright to another entity, and it should be a formality for something like this, but I'd still have to go through it if that's a requirement for Rust.
Anyway, I'm submitting this incredibly trivial thing because, if I have to go through that process for the first time, I'd like it to be for something that's trivial, so I can see how much of a hassle it is (if any) without having invested much time up front.
I didn't see anything about copyright in the Mozilla contributor's agreement, but I could have easily missed something somewhere else.
bors [Mon, 21 Oct 2013 21:21:54 +0000 (14:21 -0700)]
auto merge of #9936 : madjar/rust/master, r=alexcrichton
This should close #9468.
I removed the test stating that nested comments should not be implemented.
I had a little chicken-and-egg problem because a comment of the std contains "/*", and adding support for nested comment creates a backward incompatibility in that case, so I had to use a dirty hack to get stage1 and stage2 to compile. This part should be revert when this commit lands in a snapshot.
This is my first non-typo contribution, so I'm open to any comment.
Alex Crichton [Mon, 21 Oct 2013 18:33:04 +0000 (11:33 -0700)]
rustdoc: Render default methods for impls as well
This does not work for cross-crate implementations of traits. Cross-crate
implementations are a separate issue that should be addressed separately.
Basically when an implementation of an external trait is detected, the trait
would have to be loaded at that time (or possibly sooner...). Rustdoc currently
doesn't have the proper infrastructure for adding this.
bors [Mon, 21 Oct 2013 12:21:27 +0000 (05:21 -0700)]
auto merge of #9991 : LeoTestard/rust/asm-feature-gate, r=huonw
Fixes #9882
Note that the actual checking code is inside a if false in order to compile libstd properly.
libstd uses asm! in rt. If we put ```#[feature(asm)]``` in libstd, it fails to build at stage0 beacause the
asm feature is not known yet by the snapshot compiler.
We must wait that this PR arrives into the snapshot in order to actually activate the checking code.
bors [Sat, 19 Oct 2013 16:46:18 +0000 (09:46 -0700)]
auto merge of #9834 : alexcrichton/rust/morestack, r=brson
This commit re-introduces the functionality of __morestack in a way that it was
not originally anticipated. Rust does not currently have segmented stacks,
rather just large stack segments. We do not detect when these stack segments are
overrun currently, but this commit leverages __morestack in order to check this.
This commit purges a lot of the old __morestack and stack limit C++
functionality, migrating the necessary chunks to rust. The stack limit is now
entirely maintained in rust, and the "main logic bits" of __morestack are now
also implemented in rust as well.
I put my best effort into validating that this currently builds and runs successfully on osx and linux 32/64 bit, but I was unable to get this working on windows. We never did have unwinding through __morestack frames, and although I tried poking at it for a bit, I was unable to understand why we don't get unwinding right now.
A focus of this commit is to implement as much of the logic in rust as possible. This involved some liberal usage of `no_split_stack` in various locations, along with some use of the `asm!` macro (scary). I modified a bit of C++ to stop calling `record_sp_limit` because this is no longer defined in C++, rather in rust.
Another consequence of this commit is that `thread_local_storage::{get, set}` must both be flagged with `#[rust_stack]`. I've briefly looked at the implementations on osx/linux/windows to ensure that they're pretty small stacks, and I'm pretty sure that they're definitely less than 20K stacks, so we probably don't have a lot to worry about.
Other things worthy of note:
* The default stack size is now 4MB instead of 2MB. This is so that when we request 2MB to call a C function you don't immediately overflow because you have consumed any stack at all.
* `asm!` is actually pretty cool, maybe we could actually define context switching with it?
* I wanted to add links to the internet about all this jazz of storing information in TLS, but I was only able to find a link for the windows implementation. Otherwise my suggestion is just "disassemble on that arch and see what happens"
* I put my best effort forward on arm/mips to tweak __morestack correctly, we have no ability to test this so an extra set of eyes would be useful on these spots.
* This is all really tricky stuff, so I tried to put as many comments as I thought were necessary, but if anything is still unclear (or I completely forgot to take something into account), I'm willing to write more!
Alex Crichton [Thu, 17 Oct 2013 08:40:33 +0000 (01:40 -0700)]
Use __morestack to detect stack overflow
This commit resumes management of the stack boundaries and limits when switching
between tasks. This additionally leverages the __morestack function to run code
on "stack overflow". The current behavior is to abort the process, but this is
probably not the best behavior in the long term (for deails, see the comment I
wrote up in the stack exhaustion routine).
bors [Sat, 19 Oct 2013 10:56:19 +0000 (03:56 -0700)]
auto merge of #9941 : alexcrichton/rust/rustdoc, r=huonw
Beforehand the id of a method was the id of the 'self' argument, but this is not
the id which privacy was using (the id of the ast::method) struct, so by moving
the ids over to the privacy-target ones the methods are now stripped correctly.
bors [Sat, 19 Oct 2013 02:36:22 +0000 (19:36 -0700)]
auto merge of #9437 : catamorphism/rust/rustpkg-dates, r=alexcrichton
r? @alexcrichton On most platforms, the time granularity is 1 sec or more, so comparing
dates in tests that check whether rebuilding did or didn't happen leads
to spurious failures. Instead, test the same thing by making an output
file read-only and trapping attempts to write to it.
Tim Chevalier [Thu, 26 Sep 2013 19:15:54 +0000 (12:15 -0700)]
rustpkg: Make rustpkg tests stop comparing dates
Instead of scrutinizing modification times in rustpkg tests,
change output files to be read-only and detect attempts to write
to them (hack suggested by Jack). This avoids time granularity problems.
As part of this change, I discovered that some dependencies weren't
getting written correctly (involving built executables and library
files), so this patch fixes that too.
This partly addresses #9441, but one test (test_rebuild_when_needed)
is still ignored on Linux.
Alex Crichton [Sat, 19 Oct 2013 01:16:38 +0000 (18:16 -0700)]
rustdoc: Strip methods correctly based on privacy
Beforehand the id of a method was the id of the 'self' argument, but this is not
the id which privacy was using (the id of the ast::method) struct, so by moving
the ids over to the privacy-target ones the methods are now stripped correctly.
bors [Sat, 19 Oct 2013 00:11:25 +0000 (17:11 -0700)]
auto merge of #9856 : alexcrichton/rust/privacy-errors, r=huonw
This stops labeling everything as "is private" when in fact the destination may
be public. Instead, the clause "is inaccessible" is used and the private part of
the flag is called out with a "is private" message.
bors [Fri, 18 Oct 2013 22:26:24 +0000 (15:26 -0700)]
auto merge of #9933 : alexcrichton/rust/no-jemalloc, r=brson
As discovered in #9925, it turns out that we weren't using jemalloc on most
platforms. Additionally, on some platforms we were using it incorrectly and
mismatching the libc version of malloc with the jemalloc version of malloc.
Additionally, it's not clear that using jemalloc is indeed a large performance
win in particular situtations. This could be due to building jemalloc
incorrectly, or possibly due to using jemalloc incorrectly, but it is unclear at
this time.
Until jemalloc can be confirmed to integrate correctly on all platforms and has
verifiable large performance wins on platforms as well, it shouldn't be part of
the default build process. It should still be available for use via the
LD_PRELOAD trick on various architectures, but using it as the default allocator
for everything would require guaranteeing that it works in all situtations,
which it currently doesn't.
Alex Crichton [Fri, 18 Oct 2013 17:33:40 +0000 (10:33 -0700)]
Remove jemalloc from the runtime
As discovered in #9925, it turns out that we weren't using jemalloc on most
platforms. Additionally, on some platforms we were using it incorrectly and
mismatching the libc version of malloc with the jemalloc version of malloc.
Additionally, it's not clear that using jemalloc is indeed a large performance
win in particular situtations. This could be due to building jemalloc
incorrectly, or possibly due to using jemalloc incorrectly, but it is unclear at
this time.
Until jemalloc can be confirmed to integrate correctly on all platforms and has
verifiable large performance wins on platforms as well, it shouldn't be part of
the default build process. It should still be available for use via the
LD_PRELOAD trick on various architectures, but using it as the default allocator
for everything would require guaranteeing that it works in all situtations,
which it currently doesn't.
bors [Fri, 18 Oct 2013 16:41:33 +0000 (09:41 -0700)]
auto merge of #9851 : alexcrichton/rust/include_bin, r=huonw
Previously an ExprLit was created *per byte* causing a huge increase in memory
bloat. This adds a new `lit_binary` to contain a literal of binary data, which
is currently only used by the include_bin! syntax extension. This massively
speeds up compilation times of the shootout-k-nucleotide-pipes test
before:
time: 469s
memory: 6GB
assertion failure in LLVM (section too large)
Alex Crichton [Mon, 14 Oct 2013 15:24:17 +0000 (08:24 -0700)]
Optimize include_bin! for large inputs
Previously an ExprLit was created *per byte* causing a huge increase in memory
bloat. This adds a new `lit_binary` to contain a literal of binary data, which
is currently only used by the include_bin! syntax extension. This massively
speeds up compilation times of the shootout-k-nucleotide-pipes test
before:
time: 469s
memory: 6GB
assertion failure in LLVM (section too large)
bors [Fri, 18 Oct 2013 07:26:19 +0000 (00:26 -0700)]
auto merge of #9924 : metajack/rust/fix-starts-with-ends-with, r=huonw
d4a32386f3b6 broke these since slice_to() and slice_from() must get character
boundaries, and arbitrary needle lengths don't necessarily map to character
boundaries of the haystack.
This also adds new tests that would have caught this bug.
bors [Fri, 18 Oct 2013 06:16:22 +0000 (23:16 -0700)]
auto merge of #9850 : eddyb/rust/inline-asm-constraints, r=luqmana
I've implemented analysis support for the [GCC '=' write-only inline asm constraint modifier](http://gcc.gnu.org/onlinedocs/gcc/Modifiers.html). I had more changes, for '+' (read+write) as well, but it turns out LLVM doesn't support '+' at all.
I've removed the need for wrapping each output in ExprAddrOf, as that would require unwrapping almost everywhere and it was harder to reason about in borrowck than ExprAssign's LHS.
With this change, rustc will treat (in respect to validity of accessing a local) code like this:
```rust
let x: int;
unsafe {
asm!("mov $1, $0" : "=r"(x) : "r"(5u));
}
```
as if it were this:
```rust
let x : int;
x = 5;
```
Previously, the local was required to be both mutable and initialized, and the write effect wasn't recorded.
Jack Moffitt [Fri, 18 Oct 2013 05:32:46 +0000 (23:32 -0600)]
Fix starts_with() and ends_with().
d4a32386f3b6 broke these since slice_to() and slice_from() must get character
boundaries, and arbitrary needle lengths don't necessarily map to character
boundaries of the haystack.
This also adds new tests that would have caught this bug.
bors [Fri, 18 Oct 2013 03:56:18 +0000 (20:56 -0700)]
auto merge of #9921 : sp3d/rust/master, r=alexcrichton
Refactors parsing of numerical literals to make it more readable.
Removes 'float'/the 'f' literal suffix and invalid character literals ''' and '\'.
Also makes attribute highlighting more robust and allows urls in attributes to be recognized.
sp3d [Fri, 18 Oct 2013 03:35:26 +0000 (03:35 +0000)]
track language changes, improve attr handling in GtkSourceView language-spec
Refactors parsing of numerical literals to make it more readable.
Removes 'float'/the 'f' literal suffix and invalid character literals ''' and '\'.
Also makes attribute highlighting more robust and allows urls in attributes to be recognized.
bors [Fri, 18 Oct 2013 01:01:22 +0000 (18:01 -0700)]
auto merge of #9916 : alexcrichton/rust/issue-9861, r=brson
This was just incorrectly handled before, the path component shouldn't be looked
at at all (we used absolute paths everywhere instead of relative to the current
module location).
Alex Crichton [Fri, 18 Oct 2013 00:15:42 +0000 (17:15 -0700)]
rustdoc: Don't treat "super" specially for urls
This was just incorrectly handled before, the path component shouldn't be looked
at at all (we used absolute paths everywhere instead of relative to the current
module location).
bors [Thu, 17 Oct 2013 20:56:23 +0000 (13:56 -0700)]
auto merge of #9902 : thestinger/rust/immediate, r=nikomatsakis
The code generation previously assumed a reference could not alter the
value in a way the destructor would notice. This is an incorrect
assumption for `&mut`, and is also incorrect for an `&` pointer to a
non-`Freeze` type.
Daniel Micay [Thu, 17 Oct 2013 07:43:22 +0000 (03:43 -0400)]
partially fix immediate rvalues
The code generation previously assumed a reference could not alter the
value in a way the destructor would notice. This is an incorrect
assumption for `&mut`, and is also incorrect for an `&` pointer to a
non-`Freeze` type.
projects / rust.git / log