Allows an enum with a discriminant to use any of the primitive integer types to store it. By default the smallest usable type is chosen, but this can be overridden with an attribute: `#[repr(int)]` etc., or `#[repr(C)]` to match the target's C ABI for the equivalent C enum.
Also adds a lint pass for using non-FFI safe enums in extern declarations, checks that specified discriminants can be stored in the specified type if any, and fixes assorted code that was assuming int.
This is one of the final steps needed to complete #9128. It still needs a little bit of polish before closing that issue, but it's in a pretty much "done" state now.
The idea here is that the entire event loop implementation using libuv is now housed in `librustuv` as a completely separate library. This library is then injected (via `extern mod rustv`) into executable builds (similarly to how libstd is injected, tunable via `#[no_uv]`) to bring in the "rust blessed event loop implementation."
Codegen-wise, there is a new `event_loop_factory` language item which is tagged on a function with 0 arguments returning `~EventLoop`. This function's symbol is then inserted into the crate map for an executable crate, and if there is no definition of the `event_loop_factory` language item then the value is null.
What this means is that embedding rust as a library in another language just got a little harder. Libraries don't have crate maps, which means that there's no way to find the event loop implementation to spin up the runtime. That being said, it's always possible to build the runtime manually. This request also makes more runtime components public which should probably be public anyway. This new public-ness should allow custom scheduler setups everywhere regardless of whether you follow the `rt::start `path.
The previous implementation, when combined with small discriminants and
immediate types, caused problems for types like `Either<u8, i16>` which
are now small enough to be immediate and can have fields intersecting
the highest-alignment variant's alignment padding (which LLVM doesn't
preserve). So let's not do that.
Not only can discriminants be smaller than int now, but they can be
larger than int on 32-bit targets. This has obvious implications for the
reflection interface. Without this change, things fail with LLVM
assertions when we try to "extend" i64 to i32.
Note that raising an error during trans doesn't stop the compile or cause
rustc to exit with a failure status, currently, so this is of more than
cosmetic importance.
Allows an enum with a discriminant to use any of the primitive integer
types to store it. By default the smallest usable type is chosen, but
this can be overridden with an attribute: `#[repr(int)]` etc., or
`#[repr(C)]` to match the target's C ABI for the equivalent C enum.
This commit breaks a few things, due to transmutes that now no longer
match in size, or u8 enums being passed to C that expects int, or
reflection; later commits on this branch fix them.
There are a few reasons that this is a desirable move to take:
1. Proof of concept that a third party event loop is possible
2. Clear separation of responsibility between rt::io and the uv-backend
3. Enforce in the future that the event loop is "pluggable" and replacable
Here's a quick summary of the points of this pull request which make this
possible:
* Two new lang items were introduced: event_loop, and event_loop_factory.
The idea of a "factory" is to define a function which can be called with no
arguments and will return the new event loop as a trait object. This factory
is emitted to the crate map when building an executable. The factory doesn't
have to exist, and when it doesn't then an empty slot is in the crate map and
a basic event loop with no I/O support is provided to the runtime.
* When building an executable, then the rustuv crate will be linked by default
(providing a default implementation of the event loop) via a similar method to
injecting a dependency on libstd. This is currently the only location where
the rustuv crate is ever linked.
* There is a new #[no_uv] attribute (implied by #[no_std]) which denies
implicitly linking to rustuv by default
Closes#5019
This is, I think, the minimal change required. I would have included a test but as far as I can tell there is currently no way to precisely test that the span for an error underlines the correct word. I did verify it manually.
LLVM is unable to determine this for most cases.
http://llvm-reviews.chandlerc.com/D2034 needs to land upstream before
this is going to have an effect. It's harmless to start generating the
expect hint now.
These methods are all excellent candidates for default methods, so there's no need to require extra imports of various traits. Additionally, this was able to remove all the weird underscores after the method names. Yay!
LLVM is unable to determine this for most cases.
http://llvm-reviews.chandlerc.com/D2034 needs to land upstream before
this is going to have an effect. It's harmless to start generating the
expect hint now.
OS X 10.9's linker has a bug that results in it failing to preserve
DWARF unwind information when passed the -no_compact_unwind flag.
This flag is passed on OS X because the unwind information for
__morestack cannot be represented by the compact unwind format.
We can work around this problem by using a more targeted approach
to disabling compact unwind information. The OS X linker looks for
a particular pattern in the DWARF unwind information and will not
attempt to convert the unwind information to the compact format.
The pattern in question is the return address register being saved
twice to the same location.
Fixes#6849.
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
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
OS X 10.9's linker has a bug that results in it failing to preserve
DWARF unwind information when passed the -no_compact_unwind flag.
This flag is passed on OS X because the unwind information for
__morestack cannot be represented by the compact unwind format.
We can work around this problem by using a more targeted approach
to disabling compact unwind information. The OS X linker looks for
a particular pattern in the DWARF unwind information and will not
attempt to convert the unwind information to the compact format.
The pattern in question is the return address register being saved
twice to the same location.
Fixes#6849.
