bors [Thu, 31 Oct 2013 17:31:56 +0000 (10:31 -0700)]
auto merge of #10167 : briantdawn/rust/master, r=cmr
To keep consistency with the word "borrowing" I suppose an alternate way to write this could be "Having an object borrow an immutable pointer freezes it and prevents mutation".
bors [Thu, 31 Oct 2013 01:31:26 +0000 (18:31 -0700)]
auto merge of #10120 : Kimundi/rust/remove_sys, r=alexcrichton
- `begin_unwind` and `fail!` is now generic over any `T: Any + Send`.
- Every value you fail with gets boxed as an `~Any`.
- Because of implementation issues, `&'static str` and `~str` are still
handled specially behind the scenes.
- Changed the big macro source string in libsyntax to a raw string
literal, and enabled doc comments there.
Marvin Löbel [Sun, 27 Oct 2013 19:12:40 +0000 (20:12 +0100)]
Prepared `std::sys` for removal, and made `begin_unwind` simpler
- `begin_unwind` is now generic over any `T: Any + Send`.
- Every value you fail with gets boxed as an `~Any`.
- Because of implementation details, `&'static str` and `~str` are still
handled specially behind the scenes.
- Changed the big macro source string in libsyntax to a raw string
literal, and enabled doc comments there.
bors [Wed, 30 Oct 2013 07:31:23 +0000 (00:31 -0700)]
auto merge of #9613 : jld/rust/enum-discrim-size.r0, r=alexcrichton
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.
Patrick Walton [Mon, 28 Oct 2013 22:22:49 +0000 (15:22 -0700)]
librustc: Implement the `proc` type as sugar for `~once fn` and `proc`
notation for closures, and disable the feature gate for `once fn` if
used with the `~` sigil.
bors [Tue, 29 Oct 2013 16:36:47 +0000 (09:36 -0700)]
auto merge of #10058 : alexcrichton/rust/uv-crate, r=brson
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.
Jed Davis [Tue, 29 Oct 2013 16:07:30 +0000 (09:07 -0700)]
Prevent unoptimized rustpkg tests from running out of stack.
The actual fix would be to make rustpkg use `rustc::monitor` so it picks
up anything special that rustc needs, but for now let's keep the tests
from breaking.
Jed Davis [Sat, 26 Oct 2013 19:12:53 +0000 (12:12 -0700)]
Fix type_of for enums to not lose data in some cases when immediate.
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.
Jed Davis [Sun, 20 Oct 2013 18:13:41 +0000 (11:13 -0700)]
Work around const_eval issues by changing signed integer `min_value`s.
Otherwise, run-pass/deriving-primitive.rs breaks on 32-bit platforms,
because `int::min_value` is `0xffffffff7fffffff` when evaluated for the
discriminant declaration.
Jed Davis [Sun, 29 Sep 2013 09:20:11 +0000 (02:20 -0700)]
Adjust reflection for the possibility of discriminants larger than int.
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.
Jed Davis [Sat, 31 Aug 2013 21:41:35 +0000 (14:41 -0700)]
Unbreak the debuginfo tests.
The variant used in debug-info/method-on-enum.rs had its layout changed
by the smaller discriminant, so that the `u32` no longer overlaps both
of the `u16`s, and thus the debugger is printing partially uninitialized
data when it prints the wrong variant.
Thus, the test runner is modified to accept wildcards (using a string
that should be unlikely to occur literally), to allow for this.
Jed Davis [Fri, 30 Aug 2013 06:45:06 +0000 (23:45 -0700)]
Check repr attribute consistency at check time, not translation.
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.
Jed Davis [Mon, 1 Jul 2013 05:42:30 +0000 (22:42 -0700)]
Initial implementation of enum discrimnant sizing.
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.
Alex Crichton [Tue, 22 Oct 2013 22:13:18 +0000 (15:13 -0700)]
Move rust's uv implementation to its own crate
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
bors [Tue, 29 Oct 2013 14:41:48 +0000 (07:41 -0700)]
auto merge of #10142 : pythonesque/rust/issue-8263, r=catamorphism
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.
bors [Tue, 29 Oct 2013 03:51:30 +0000 (20:51 -0700)]
auto merge of #10117 : huonw/rust/dead-visits, r=sanxiyn
Used nowhere, and these are likely incorrect anyway: self needs to be
dereferenced once more otherwise the method calls will be reusing the
current impl... bam! Infinite recursion.
bors [Mon, 28 Oct 2013 23:07:14 +0000 (16:07 -0700)]
auto merge of #10113 : thestinger/rust/expect, r=cmr
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.
bors [Mon, 28 Oct 2013 20:51:39 +0000 (13:51 -0700)]
auto merge of #10110 : catamorphism/rust/rustpkg-dependency-build-dir, r=metajack
r? @metajack When invoked with the --rust-path-hack flag, rustpkg was correctly building
the package into the default workspace (and not into the build/ subdirectory of the
parent directory of the source directory), but not correctly putting the output
for any dependencies into the default workspace as well.
Alex Crichton [Tue, 22 Oct 2013 22:09:23 +0000 (15:09 -0700)]
Make some more rt components public
Primarily this makes the Scheduler and all of its related interfaces public. The
reason for doing this is that currently any extern event loops had no access to
the scheduler at all. This allows third-party event loops to manipulate the
scheduler, along with allowing the uv event loop to live inside of its own
crate.
bors [Mon, 28 Oct 2013 17:56:34 +0000 (10:56 -0700)]
auto merge of #10079 : alexcrichton/rust/no-reader-util, r=brson
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!
bors [Mon, 28 Oct 2013 13:41:40 +0000 (06:41 -0700)]
auto merge of #10094 : alexcrichton/rust/issue-8704, r=pcwalton
This drops more of the old C++ runtime to rather be written in rust. A few
features were lost along the way, but hopefully not too many. The main loss is
that there are no longer backtraces associated with allocations (rust doesn't
have a way of acquiring those just yet). Other than that though, I believe that
the rest of the debugging utilities made their way over into rust.
bors [Mon, 28 Oct 2013 08:26:16 +0000 (01:26 -0700)]
auto merge of #9967 : Kimundi/rust/fail_cause_two, r=huonw
# Summary
This PR allows the cause of a failure to be received in a task's future result and as the `Err` case of `task::try`, and also implements dynamic typing in form of an `Any` trait.
# Task failure
- `fail!` and related macros now accept 5 kinds of types: `~str`, `&'static str`, `std::send_str::SendStr`, `~std::any::Any` and `~T` where `T: Any + Send + 'static`
- `std::task::TaskResult` got transformed into an internal enum `std::rt::task::UnwindResult`, and it's `Failure` variant now contains a value of enum type `UnwindReason`:
- `UnwindReasonStr(SendStr)` maps to failing with a value of type `~str`, `&'static str` or `SendStr`.
- `UnwindReasonAny(~Any)` maps to failing with an `~Any` or `~T` with `T: Send + 'static`.
- `UnwindReasonLinked` maps to failing because the task got killed by linked failure.
- Instead, `std::task::TaskResult` is now a typedef for `Result<(), ~Any>`, and both `TaskBuilder`'s `future_result()` and `task::try` now work with a value of this type.
- `future_result()` no longer returns a `Port<TaskResult>`, instead it returns a wrapper `TaskResultPort` that implements `GenericPort` and `Peekable`, and which lazily allocates a `~` box and casts to `~Any` in case of failure with a `SendStr` or linked failure (for the latter case a unit struct `LinkedFailure` got added.)
- Because `fail!` collapses both `~str` and `&'static str` into a `SendStr`, checking if a task error value is a string will just require a `.is::<SendStr>()` check, with `~str` and `&'static str` only being possible in case of an explicit `fail!(~~"...")` or `fail!(~ (&"...") as ~Any)`:
# Any
- In order to allow failing with arbitrary data, the `Any` trait got implemented.
- It is being used in form of a trait object, usually `~Any` or `&Any`.
- `&Any`, `~Any` and `&mut Any` have a few extension methods implemented on them:
- `is<T>(self) -> bool` returns true if the `Any` object contains type `T`
- `as_ref<T>(self) -> Option<&T>` returns a reference to the contained type, if it is `T`
- `as_mut<T>(self) -> Option<&mut T>` returns a mutable reference to the contained type, if it is `T`
- `move<T>(self) -> Option<~T>` allows to get the `~T` out of an `~Any` again.
- `Any` currently uses type descriptors as a type id for comparisons, which is
- not reliable, as it is not guaranteed that every type has only one type descriptor.
- But safe, as no two types share the same type descriptor.
- The implementation also a few `transmute`s, mostly to cast a `*Void` of the wrapped type into it's actual type `&T`, `&mut T` or `~T`.
# Other changes
- `std::unstable::UnsafeArc::try_unwrap` no longer uses `Either`, bringing us one step closer to removing that type.
- A few of the touched modules got their import lines sorted.
- A few stylistic cleanups here and there.
Marvin Löbel [Fri, 11 Oct 2013 21:20:34 +0000 (23:20 +0200)]
Allow fail messages to be caught, and introduce the Any trait
Some code cleanup, sorting of import blocks
Removed std::unstable::UnsafeArc's use of Either
Added run-fail tests for the new FailWithCause impls
Changed future_result and try to return Result<(), ~Any>.
- Internally, there is an enum of possible fail messages passend around.
- In case of linked failure or a string message, the ~Any gets
lazyly allocated in future_results recv method.
- For that, future result now returns a wrapper around a Port.
- Moved and renamed task::TaskResult into rt::task::UnwindResult
and made it an internal enum.
- Introduced a replacement typedef `type TaskResult = Result<(), ~Any>`.
bors [Mon, 28 Oct 2013 05:41:18 +0000 (22:41 -0700)]
auto merge of #10050 : gifnksm/rust/ratio-methods, r=pcwalton
After merging 0ada7c7, user code have not been able to access to `Ratio`'s numerator and denominator fields.
In some algorithms, it is needed to get an rational number's numerator or denominator, but keeping these fields private is necessary for guaranteeing that `Ratio` numbers are irreducible.
So, I added the getter methods `numer()` and `denom()`.
As a bonus, this commit adds utility methods relating to the ratio-integer conversion.
bors [Mon, 28 Oct 2013 04:36:31 +0000 (21:36 -0700)]
auto merge of #9744 : DaGenix/rust/remove-crypto, r=alexcrichton
Remove the Sha1, Sha2, MD5, and MD4 algorithms. SipHash is also cryptographically secure hash function and IsaacRng is a cryptographically secure RNG - I left those alone but removed comments that implied they were suitable for cryptographic use. I thought that MD4 was used for something by the compiler, but everything still seems to work with it removed, so, I guess not.
One thing that I'm not sure about - workcache.rs and workcache_support.rs (in librustpkg) both depend on Sha1. Without Sha1, the only hash function left is SipHash, so I switched that code over to use SipHash. The output size of SipHash is only 64-bits, however - much less than 160 for Sha1. I'm not sure this is a problem. Without other cryptographic hashes in the tree, I'm not sure what else to do. I considered moved Sha1 into librustpkg, but I don't know if that makes sense.
bors [Mon, 28 Oct 2013 01:41:25 +0000 (18:41 -0700)]
auto merge of #10098 : alexcrichton/rust/attempts, r=alexcrichton
It was pretty much a miracle that these tests were ever passing. They would
never have passed in the single threaded case because only one sigint in the
tests is ever generated, but when run in parallel two sigints will be generated.
projects / rust.git / log