bors [Thu, 20 Jun 2013 18:35:34 +0000 (11:35 -0700)]
auto merge of #7128 : yichoi/rust/fix_sometc, r=brson
- Fix stat struct for Android (found by SEGV at run-pass/stat.rs)
- Adjust some test cases to rpass for Android
- Modify some script to rpass for Android
Brian Anderson [Wed, 19 Jun 2013 02:52:05 +0000 (19:52 -0700)]
std: Work around some failing 'run' tests when valgrinding. #7224
Under valgrind on 64->32 cross compiles the dynamic linker is emitting
some error messages on stderr, which interferes with the tests that
are checking stderr.
bors [Mon, 17 Jun 2013 22:54:56 +0000 (15:54 -0700)]
auto merge of #7197 : rkbodenner/rust/doc-for-lib-move, r=brson
Was updating some code of mine to use the new `std`/`extra` library names, and noticed a place where docs for `std::libc` hadn't been updated. Then I updated some top-level docs for the new libraries' names, too.
bors [Mon, 17 Jun 2013 21:58:01 +0000 (14:58 -0700)]
auto merge of #7131 : Blei/rust/windows-dynamic-lib, r=graydon
The code compiles and runs under windows now, but I couldn't look up any
symbol from the current executable (dlopen(NULL)), and calling looked
up external function handles doesn't seem to work correctly under windows.
bors [Mon, 17 Jun 2013 21:01:35 +0000 (14:01 -0700)]
auto merge of #7134 : vadimcn/rust/DIBuilder, r=jdm
This commit fixes rustc's debug info generation and turns debug-info tests back on.
The old generator used to write out LLVM metadata directly, however it seems that debug metadata format is not stable and keeps changing from release to release. So I wrapped LLVM's official debug info API - the DIBuilder class, and now rustc will use that.
One bit of old functionality that still doesn't work, is debug info for function arguments. Someone more familiar with the compiler guts will need to look into that.
Also, unfortunately, debug info is still won't work on Windows,- due to a LLVM bug (http://llvm.org/bugs/show_bug.cgi?id=16249).
bors [Mon, 17 Jun 2013 17:40:21 +0000 (10:40 -0700)]
auto merge of #7202 : pcwalton/rust/resolve-speed, r=pcwalton
I'm pretty sure this got adequately reviewed by a combination of @nikomatsakis and @graydon so I'm rubber stamping it because I really want this in (it makes it much less likely for me to swap, allowing me to get more work done).
bors [Mon, 17 Jun 2013 14:43:06 +0000 (07:43 -0700)]
auto merge of #7174 : SiegeLord/rust/remove_trim, r=brson
This change prevents the indentation in code blocks inside the /// doc comments
from being eaten. The indentation that is the same across the consecutive doc
comments is removed by the uindent_pass in librustdoc.
The bug can be seen, e.g., here: http://static.rust-lang.org/doc/std/iterator.html#example-12
I also altered how the block comments are treated, for consistency. There isn't much testing done on the documentation output (I added a few tests of my own for the modified function), so I don't know if anything relied on the previous behavior. I checked a number of documentation files and observed either no change in output or changes that consistent of the above bug being fixed.
bors [Mon, 17 Jun 2013 03:16:01 +0000 (20:16 -0700)]
auto merge of #7184 : smvv/rust/doc_css, r=brson
After reading issue #7077, all header elements had a border. In my opinion those borders are a bit too much distraction. I tried a different approach with increasing the padding and font size, and omitting the borders.
Note: the highlighted code blocks are not caused by this commit.
I left the border of the code block / function signature as is. The reason behind that is that code blocks are really block elements, while headers are not. What do you guys think?
bors [Sun, 16 Jun 2013 18:48:57 +0000 (11:48 -0700)]
auto merge of #7186 : dotdash/rust/landing_pads, r=pcwalton
Currently, cleanup blocks are only reused when there are nested scopes, the
child scope's cleanup block will terminate with a jump to the parent
scope's cleanup block. But within a single scope, adding or revoking
any cleanup will force a fresh cleanup block. This means quadratic
growth with the number of allocations in a scope, because each
allocation needs a landing pad.
Instead of forcing a fresh cleanup block, we can keep a list chained
cleanup blocks that form a prefix of the currently required cleanups.
That way, the next cleanup block only has to handle newly added
cleanups. And by keeping the whole list instead of just the latest
block, we can also handle revocations more efficiently, by only
dropping those blocks that are no longer required, instead of all of
them.
Reduces the size of librustc by about 5% and the time required to build
it by about 10%.
SiegeLord [Fri, 14 Jun 2013 22:37:29 +0000 (18:37 -0400)]
Do not strip leading whitespace when parsing doc comments.
This change prevents the indentation in code blocks inside the /// doc comments
from being eaten. The indentation that is the same across the consecutive doc
comments is removed by the uindent_pass in librustdoc.
bors [Sun, 16 Jun 2013 16:54:59 +0000 (09:54 -0700)]
auto merge of #7167 : nikomatsakis/rust/ref-bindings-explicit-copy-in-generics, r=brson
Two changes:
1. Make type parameters move by default, even if they have a Copy bound. After all, they could be bound to `~T` or `~[]`. Also, this is a necessary step towards removing `copy` keyword and replacing with clone.
2. Make it illegal to move from `*T`. This is dangerous in a "moves-by-default" scenario, because it's very easy to move when working with a `*T` pointer. Also, it requires zeroing memory, which we hope to do away with someday.
Niko Matsakis [Sun, 16 Jun 2013 00:17:59 +0000 (20:17 -0400)]
Make it illegal to move from *T. This interacts poorly with moves-based-on-type,
since it creates moves that were not apparent. It also turns out to be not
widely used.
Björn Steinbrink [Sun, 16 Jun 2013 12:51:50 +0000 (14:51 +0200)]
Avoid quadratic growth of cleanup blocks
Currently, cleanup blocks are only reused when there are nested scopes, the
child scope's cleanup block will terminate with a jump to the parent
scope's cleanup block. But within a single scope, adding or revoking
any cleanup will force a fresh cleanup block. This means quadratic
growth with the number of allocations in a scope, because each
allocation needs a landing pad.
Instead of forcing a fresh cleanup block, we can keep a list chained
cleanup blocks that form a prefix of the currently required cleanups.
That way, the next cleanup block only has to handle newly added
cleanups. And by keeping the whole list instead of just the latest
block, we can also handle revocations more efficiently, by only
dropping those blocks that are no longer required, instead of all of
them.
Reduces the size of librustc by about 5% and the time required to build
it by about 10%.
bors [Sun, 16 Jun 2013 08:52:09 +0000 (01:52 -0700)]
auto merge of #7142 : alexcrichton/rust/deriving-zero, r=pcwalton
This allows mass-initialization of large structs without having to specify all the fields.
I'm a bit hesitant, but I wanted to get this out there. I don't really like using the `Zero` trait, because it doesn't really make sense for a type like `HashMap` to use `Zero` as the 'blank allocation' trait. In theory there'd be a new trait, but then that's adding cruft to the language which may not necessarily need to be there.
I do think that this can be useful, but I only implemented `Zero` on the basic types where I thought it made sense, so it may not be all that usable yet. (opinions?)
bors [Sun, 16 Jun 2013 07:04:13 +0000 (00:04 -0700)]
auto merge of #7123 : huonw/rust/more-str, r=thestinger
Moves all the remaining functions that could reasonably be methods to be methods, except for some FFI ones (which I believe @erickt is working on, possibly) and `each_split_within`, since I'm not really sure the details of it (I believe @kimundi wrote the current implementation, so maybe he could convert it to an external iterator method on `StrSlice`, e.g. `word_wrap_iter(&self) -> WordWrapIterator<'self>`, where `WordWrapIterator` impls `Iterator<&'self str>`. It probably won't be too hard, since it's already a state machine.)
This also cleans up the comparison impls for the string types, except I'm not sure how the lang items `eq_str` and `eq_str_uniq` need to be handled, so they (`eq_slice` and `eq`) remain stand-alone functions.
bors [Sun, 16 Jun 2013 03:40:14 +0000 (20:40 -0700)]
auto merge of #7114 : pnkfelix/rust/issue3961-fix-whitespace-detection, r=brson
r? (yes, the review request is back, now that I got it building against incom... I mean master!)
(Attempting to port from orphaned pull-request #6764 )
Fix for #3961. Also includes a test case to illustrate the issues. (All of the entries that say "should align" should align with each other, and the four lines near the end that say "compare _" for _ in {A,B,C,D} should line up with each other.)
Before applying this change set:
-- the "(should align)"'s are all over the place, and the form/line feeding spaces are not cut out as one might or might not expect.
-- compare B and D do not match A and C.
(To be honest, its hard to really say what the right behavior is here, and people who are expecting a particular behavior out of a pretty printer in these cases may well get burned.)
Huon Wilson [Fri, 14 Jun 2013 03:37:47 +0000 (13:37 +1000)]
std: continue improving the comparison trait impls for str.
This moves them all into the traits submodule, and delegates Ord
to the TotalOrd instance. It also deletes the stand-alone lt, gt,
ge and le functions.
projects / rust.git / log