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.
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.
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.
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.
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.
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.
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.
Spotted by Jack.
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!
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.
Closes#8704
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>`.
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.
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.
If merged, this closes#9300.
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.
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.
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.
Spotted by Jack.
I'm not entirely sure why this is happening, but the server task is never seeing
the second send of the client task, and this test will very reliably fail to
complete on windows.
