auto merge of #7958 : kemurphy/rust/link-section, r=alexcrichton
This allows for control over the section placement of static, static
mut, and fn items. One caveat is that if a static and a static mut are
placed in the same section, the static is declared first, and the static
mut is assigned to, the generated program crashes. For example:
auto merge of #7885 : graydon/rust/workcache-fixes-1, r=pcwalton
This just redoes various parts of workcache to support context-cloning (eventually quite crudely, via ARCs), the absence of which was blocking rustpkg from being able to use it. Better versions of this are possible (notably removing the ARCs on everything except the database) but it ought to work well enough for now.
scope_info => ScopeInfo
```
I also tried to convert instances of `@mut` to `&mut` or `&` but a lot of them are blocked by issue #6268, so I left it for some time later.
auto merge of #7944 : blake2-ppc/rust/dlist-move-nodes, r=bblum
Factor out internal methods to pop/push list nodes so that .merge() and .rotate_to_front(), .rotate_to_back() (new methods) can be implemented without allocating nodes.
With that, some cleanup changes to DList use of Option, and adding a missing Encodable implementation.
Kevin Murphy [Tue, 23 Jul 2013 02:34:04 +0000 (22:34 -0400)]
Add link_section attribute for static and fn items
This allows for control over the section placement of static, static
mut, and fn items. One caveat is that if a static and a static mut are
placed in the same section, the static is declared first, and the static
mut is assigned to, the generated program crashes. For example:
auto merge of #7703 : sfackler/rust/bitv, r=alexcrichton
Switched Bitv and BitvSet to external iterators. They still use some internal iterators internally (ha).
Derived clone for all Bitv types.
Removed indirection in BitvVariant. It previously held a unique pointer to the appropriate Bitv struct, even though those structs are the size of a pointer themselves. BitvVariant is the same size (16 bytes) as it was previously.
auto merge of #7883 : brson/rust/rm-std-net, r=graydon
This removes all the code from libextra that depends on libuv. After that it removes three runtime features that existed to support the global uv loop: weak tasks, runtime-global variables, and at_exit handlers.
The networking code doesn't have many users besides servo, so shouldn't have much fallout. The timer code though is useful and will probably break out-of-tree code until the new scheduler lands, but I expect that to be soon.
It also incidentally moves `os::change_dir_locked` to `std::unstable`. This is a function used by test cases to avoid cwd races and in my opinion shouldn't be public (#7870).
auto merge of #7941 : dotdash/rust/codegen, r=huonw
These changes remove unnecessary basic blocks and the associated branches from
the LLVM IR that we emit. Together, they reduce the time for unoptimized builds
in stage2 by about 10% on my box.
Björn Steinbrink [Sun, 21 Jul 2013 14:19:34 +0000 (16:19 +0200)]
Avoid blocks for static allocas and loading the closure environment
These blocks were required because previously we could only insert
instructions at the end of blocks, but we wanted to have all allocas in
one place, so they can be collapse. But now we have "direct" access the
the LLVM IR builder and can position it freely. This allows us to use
the same trick that clang uses, which means that we insert a dummy
"marker" instruction to identify the spot at which we want to insert
allocas. We can then later position the IR builder at that spot and
insert the alloca instruction, without any dedicated block.
The block for loading the closure environment can now also go away,
because the function context now provides the toplevel block, and the
translation of the loading happens first, so that's good enough.
Makes the LLVM IR a bit more readable, saving a bunch of branches in the
unoptimized code, which benefits unoptimized builds.
Björn Steinbrink [Sun, 21 Jul 2013 13:33:40 +0000 (15:33 +0200)]
Provide lower level access to the LLVM IR builder
Currently, the helper functions in the "build" module can only append
at the end of a block. For certain things we'll want to be able to
insert code at arbitrary locations inside a block though. Although can
we do that by directly calling the LLVM functions, that is rather ugly
and means that somethings need to be implemented twice. Once in terms
of the helper functions and once in terms of low level LLVM functions.
Instead of doing that, we should provide a Builder type that provides
low level access to the builder, and which can be used by both, the
helper functions in the "build" module, as well larger units of
abstractions that combine several LLVM instructions.
Björn Steinbrink [Wed, 17 Jul 2013 19:59:58 +0000 (21:59 +0200)]
Avoid creating llenv blocks when there's nothing to load
Currently, all closures have an llenv block to load values from the
captured environment, but for closure that don't actually capture
anything, that block is useless and can be skipped.
auto merge of #7902 : huonw/rust/attr++, r=cmr,pcwalton
This does a number of things, but especially dramatically reduce the
number of allocations performed for operations involving attributes/
meta items:
- Converts ast::meta_item & ast::attribute and other associated enums
to CamelCase.
- Converts several standalone functions in syntax::attr into methods,
defined on two traits AttrMetaMethods & AttributeMethods. The former
is common to both MetaItem and Attribute since the latter is a thin
wrapper around the former.
- Deletes functions that are unnecessary due to iterators.
- Converts other standalone functions to use iterators and the generic
AttrMetaMethods rather than allocating a lot of new vectors (e.g. the
old code would have to allocate a new vector to use functions that
operated on &[meta_item] on &[attribute].)
- Moves the core algorithm of the #[cfg] matching to syntax::attr,
similar to find_inline_attr and find_linkage_metas.
This doesn't have much of an effect on the speed of #[cfg] stripping,
despite hugely reducing the number of allocations performed; presumably
most of the time is spent in the ast folder rather than doing attribute
checks.
Also fixes the Eq instance of MetaItem_ to correctly ignore spans, so
that `rustc --cfg 'foo(bar)'` now works.
auto merge of #7882 : blake2-ppc/rust/iterator-clone, r=thestinger
Implement method .cycle() that repeats an iterator endlessly
Implement Clone for simple iterators (without closures), including VecIterator.
> The theory is simple, the immutable iterators simply hold state
> variables (indicies or pointers) into frozen containers. We can freely
> clone these iterators, just like we can clone borrowed pointers.
std: Implement Clone for VecIterator and iterators using it
The theory is simple, the immutable iterators simply hold state
variables (indicies or pointers) into frozen containers. We can freely
clone these iterators, just like we can clone borrowed pointers.
VecIterator needs a manual impl to handle the lifetime struct member.
auto merge of #7710 : michaelwoerister/rust/WP4, r=jdm
This pull request includes various improvements:
+ Composite types (structs, tuples, boxes, etc) are now handled more cleanly by debuginfo generation. Most notably, field offsets are now extracted directly from LLVM types, as opposed to trying to reconstruct them. This leads to more stable handling of edge cases (e.g. packed structs or structs implementing drop).
+ `debuginfo.rs` in general has seen a major cleanup. This includes better formatting, more readable variable and function names, removal of dead code, and better factoring of functionality.
+ Handling of `VariantInfo` in `ty.rs` has been improved. That is, the `type VariantInfo = @VariantInfo_` typedef has been replaced with explicit uses of @VariantInfo, and the duplicated logic for creating VariantInfo instances in `ty::enum_variants()` and `typeck::check::mod::check_enum_variants()` has been unified into a single constructor function. Both function now look nicer too :)
+ Debug info generation for enum types is now mostly supported. This includes:
+ Good support for C-style enums. Both DWARF and `gdb` know how to handle them.
+ Proper description of tuple- and struct-style enum variants as unions of structs.
+ Proper handling of univariant enums without discriminator field.
+ Unfortunately `gdb` always prints all possible interpretations of a union, so debug output of enums is verbose and unintuitive. Neither `LLVM` nor `gdb` support DWARF's `DW_TAG_variant` which allows to properly describe tagged unions. Adding support for this to `LLVM` seems doable. `gdb` however is another story. In the future we might be able to use `gdb`'s Python scripting support to alleviate this problem. In agreement with @jdm this is not a high priority for now.
+ The debuginfo test suite has been extended with 14 test files including tests for packed structs (with Drop), boxed structs, boxed vecs, vec slices, c-style enums (standalone and embedded), empty enums, tuple- and struct-style enums, and various pointer types to the above.
~~What is not yet included is DI support for some enum edge-cases represented as described in `trans::adt::NullablePointer`.~~