bors [Mon, 19 Aug 2013 11:32:04 +0000 (04:32 -0700)]
auto merge of #8535 : nikomatsakis/rust/issue-3678-wrappers-be-gone-2, r=graydon
Long-standing branch to remove foreign function wrappers altogether. Calls to C functions are done "in place" with no stack manipulation; the scheme relies entirely on the correct use of `#[fixed_stack_segment]` to guarantee adequate stack space. A linter is added to detect when `#[fixed_stack_segment]` annotations are missing. An `externfn!` macro is added to make it easier to declare foreign fns and wrappers in one go: this macro may need some refinement, though, for example it might be good to be able to declare a group of foreign fns. I leave that for future work (hopefully somebody else's work :) ).
bors [Mon, 19 Aug 2013 08:42:05 +0000 (01:42 -0700)]
auto merge of #8564 : alexcrichton/rust/ifmt+++, r=graydon
See discussion in #8489, but this selects option 3 by adding a `Default` trait to be implemented by various basic types.
Once this makes it into a snapshot I think it's about time to start overhauling all current use-cases of `fmt!` to move towards `ifmt!`. The goal is to replace `%X` with `{}` in 90% of situations, and this commit should enable that.
bors [Mon, 19 Aug 2013 02:32:36 +0000 (19:32 -0700)]
auto merge of #8565 : bblum/rust/select-bugfix, r=brson
@brson grilled me about how this bugfix worked the first time around, and it occurred to me that it didn't in the case where the task is unwinding. Now it will.
bors [Sun, 18 Aug 2013 14:21:58 +0000 (07:21 -0700)]
auto merge of #8555 : chris-morgan/rust/time-clone, r=huonw
I need `Clone` for `Tm` for my latest work on [rust-http](https://github.com/chris-morgan/rust-http) (static typing for headers, and headers like `Date` are a time), so here it is.
@huonw recommended deriving DeepClone while I was at it.
I also had to implement `DeepClone` for `~str` to get a derived implementation of `DeepClone` for `Tm`; I did `@str` while I was at it, for consistency.
bors [Sun, 18 Aug 2013 09:51:59 +0000 (02:51 -0700)]
auto merge of #8550 : kballard/rust/token-start-err-msg, r=catamorphism
The span was fixed at some point to point to the correct character, but
the error message is still bad. Update it to emit the actual character
in question (potentially escaped).
bors [Sun, 18 Aug 2013 05:52:00 +0000 (22:52 -0700)]
auto merge of #8547 : kballard/rust/trait-parse-err-msg, r=alexcrichton
When parsing a trait function, the function must end with either `;` or
`{` (signifying a default implementation). The error message incorrectly
stated that it must be `;` or `}`.
bors [Sat, 17 Aug 2013 22:22:04 +0000 (15:22 -0700)]
auto merge of #8554 : michaelwoerister/rust/generics, r=brson
This pull request includes support for generic functions and self arguments in methods, and combinations thereof. This also encompasses any kind of trait methods, regular and static, with and without default implementation. The implementation is backed up by a felt ton of test cases `:)`
This is a very important step towards being able to compile larger programs with debug info, since practically any generic function caused an ICE before.
One point worth discussing is that activating debug info now automatically (and silently) sets the `no_monomorphic_collapse` flag. Otherwise debug info would show wrong type names in all but one instance of the monomorphized function.
Another thing to note is that the handling of generic types does not strictly follow the DWARF specification. That is, variables with type `T` (where `T=int`) are described as having type `int` and not as having type `T`. In other words, we are losing information whether a variable has been declared with a type parameter as its type. In practice this should not make much of difference though since the concrete type is mostly what one is interested in. I'll post an issue later so this won't be forgotten.
Also included are a number of bug fixes:
* Closes #1758
* Closes #8513
* Closes #8443
* Fixes handling of field names in tuple structs
* Fixes and re-enables test case for option-like enums that relied on undefined behavior before
* Closes #1339 (should have been closed a while ago)
bors [Sat, 17 Aug 2013 14:42:01 +0000 (07:42 -0700)]
auto merge of #8272 : DaGenix/rust/digest-md5-impl-not-unrolled, r=cmr
An MD5 implementation was originally included in #8097, but, since there are a couple different implementations of that digest algorithm (@alco mentioned his implementation on the mailing list just before I opened that PR), it was suggested that I remove it from that PR and open up a new PR to discuss the different implementations and the best way forward. If anyone wants to discuss a different implementation, feel free to present it here and discuss and compare it to this one. I'll just discuss my implementation and I'll leave it to others to present details of theirs.
This implementation relies on the FixedBuffer struct from cryptoutil.rs for managing the input buffer, just like the Sha1 and Sha2 digest implementations do. I tried manually unrolling the loops in the compression function, but I got slightly worse performance when I did that.
Outside of the #[test]s, I also tested the implementation by generating 1,000 inputs of up to 10MB in size and checking the MD5 digest calculated by this code against the MD5 digest calculated by Java's implementation.
On my computer, I'm getting the following performance:
bors [Sat, 17 Aug 2013 12:12:03 +0000 (05:12 -0700)]
auto merge of #8053 : gavinb/rust/uuid_std, r=alexcrichton
Addresses part of #7104
This module adds the ability to generate UUIDs (on all Rust-supported platforms).
I reviewed the existing UUID support in libraries for a range of languages; Go, D, C#, Java and Boost++. The features were all very similar, and this patch essentially covers the union. The implmentation is quite straightforward, and uses the underlying rng support which is assumed to be sufficiently strong for this purpose.
This patch is not complete, however I have put this up for review to gather feedback before finalising. It has tests for most features and documentation for most functions.
Outstanding issues:
* Only generates V4 (Random) UUIDs. Do we want to support the SHA-1 hash based flavour as well?
* Is it worth having the field-based struct public as well as the byte array?
* Formatting the string with '-' between groups not done yet.
* Parsing full string not done as there appears to be no regexp support yet. I can write a simple manual parser for now?
* D has a generator as well. This would be easy to add. However, given the simple interface for creating a new one, and the presence of the macro, is this useful?
* Is it worth having a separate UUID trait and specific implementation? Or should it just have a struct+impl with the same name? Currently it feels weird to have the trait (which can't be named UUID so as to conflict) a separate thing.
* Should the macro be visible at the top level scope?
As this is a first attempt, some code may not be idiomatic. Please comment below...
bors [Sat, 17 Aug 2013 07:22:05 +0000 (00:22 -0700)]
auto merge of #8531 : brson/rust/test-waitpid-workaround, r=graydon
...er
I believe the calls to waitpid are interacting badly with the message passing that goes
on between schedulers and causing us to have very little parallelism in
the test suite. I don't fully understand the sequence of events that causes
the problem here but clearly blocking on waitpid is something that a
well-behaved task should not be doing.
Unfortunately this adds quite a bit of overhead to each test: one thread, two
tasks, three stacks, so there's a tradeoff. The time to execute run-pass on
my 4-core machine goes from ~750s to ~300s.
This should have a pretty good impact on cycle times.
Palmer Cox [Mon, 12 Aug 2013 03:14:27 +0000 (23:14 -0400)]
Crypto: update checked addition functions to use CheckedAdd intrinsic.
The shift_add_check_overflow and shift_add_check_overflow_tuple functions are
re-written to be more efficient and to make use of the CheckedAdd instrinsic
instead of manually checking for integer overflow.
* The invokation leading_zeros() is removed and replaced with simple integer
comparison. The leading_zeros() method results in a ctpop LLVM instruction
and it may not be efficient on all architectures; integer comparisons,
however, are efficient on just about any architecture.
* The methods lose the ability for the caller to specify a particular shift
value - that functionality wasn't being used and removing it allows for the
code to be simplified.
* Finally, the methods are renamed to add_bytes_to_bits and
add_bytes_to_bits_tuple to reflect their very specific purposes.
bors [Fri, 16 Aug 2013 15:05:10 +0000 (08:05 -0700)]
auto merge of #8534 : huonw/rust/tls-key-macro, r=alexcrichton
This allows the internal implementation details of the TLS keys to be
changed without requiring the update of all the users. (Or, applying
changes that *have* to be applied for the keys to work correctly, e.g.
forcing LLVM to not merge these constants.)
Add UUID support to libextra
- generate random UUIDs
- convert to and from strings and bytes
- parse common string formats
- implements Zero, Clone, FromStr, ToStr, Eq, TotalEq and Rand
- unit tests and documentation
- parsing error codes and strings
- incorporate feedback from PR review
Huon Wilson [Thu, 15 Aug 2013 13:16:59 +0000 (23:16 +1000)]
syntax: add a local_data_key macro that creates a key for access to the TLS.
This allows the internal implementation details of the TLS keys to be
changed without requiring the update of all the users. (Or, applying
changes that have to be applied for the keys to work correctly, e.g.
forcing LLVM to not merge these constants.)
Kevin Ballard [Fri, 16 Aug 2013 04:16:40 +0000 (21:16 -0700)]
Better error message for unknown start of token
The span was fixed at some point to point to the correct character, but
the error message is still bad. Update it to emit the actual character
in question (potentially escaped).
Kevin Ballard [Fri, 16 Aug 2013 00:58:56 +0000 (17:58 -0700)]
Fix error message when trait method ends with wrong token
When parsing a trait function, the function must end with either `;` or
`{` (signifying a default implementation). The error message incorrectly
stated that it must be `;` or `}`.
bors [Thu, 15 Aug 2013 13:56:06 +0000 (06:56 -0700)]
auto merge of #8491 : robertknight/rust/7722-reservoir_sampling, r=graydon
Fixes #7722
I had a couple of queries:
- Should this return an array or an iterator?
- Should this be a method on iterators or on the rng? I implemented it in RngUtils as it seemed to belong with shuffle().
bors [Thu, 15 Aug 2013 11:56:06 +0000 (04:56 -0700)]
auto merge of #8527 : pnkfelix/rust/fsk-visitor-vpar-defaults-step1, r=nikomatsakis
Rewriting visit.rs to operate on a borrowed `&mut V` where `<V:Visitor>`
r? @nikomatsakis
r? @pcwalton
This is the first in a planned series of incremental pull requests. (There will probably be five pull requests including this one, though they can be combined or split as necessary.)
Part of #7081. (But definitely does *not* complete it, not on its own, and not even after all five parts land; there are still a few loose ends to tie up or trim afterwards.)
The bulk of this change for this particular PR is pnkfelix@3d83010, which has the changes necessary to visit.rs to support everything else that comes later. The other commits are illustrating the standard mechanical transformation that I am applying.
One important point for nearly *all* of these pull requests: I was deliberately *not* trying to be intelligent in the transformation.
* My goal was to minimize code churn, and make the transformation as mechanical as possible.
* For example, I kept the separation between the Visitor struct (corresponding to the earlier vtable of functions that were potentially closed over local state) and the explicitly passed (and clones) visitor Env. I am certain that this is almost always unnecessary, and a later task will be to go through an meld the Env's into the Visitors as appropriate. (My original goal had been to make such melding part of this task; that's why I turned them into a (Env, vtable) tuple way back when. But I digress.)
* Also, my main goal here was to get rid of the record of `@fn`'s as described by the oldvisit.rs API. (This series gets rid of all but one such case; I'm still investigating that.) There is *still* plenty of `@`-boxing left to be removed, I'm sure, and even still some `@fn`'s too; removing all of those is not the goal here; its just to get rid of the encoded protocol of `@fn`'s in the (old)visit API.
To see where things will be going in the future (i.e., to get a sneak-preview of future pull-requests in the series), see:
* https://github.com/pnkfelix/rust/commits/fsk-visitor-vpar-defaults-step1 (that's this one)
* https://github.com/pnkfelix/rust/commits/fsk-visitor-vpar-defaults-step2
* https://github.com/pnkfelix/rust/commits/fsk-visitor-vpar-defaults-step3
* https://github.com/pnkfelix/rust/commits/fsk-visitor-vpar-defaults-step4
* https://github.com/pnkfelix/rust/commits/fsk-visitor-vpar-defaults-step5
* Note that between step 4 and step 5 there is just a single commit, but its a doozy because its the only case where my mechanical transformation did not apply, and thus more serious rewriting was necessary. See commit pnkfelix@da902b2ff3b1e0bee9fc63cf00c449cceea8abf7
bors [Thu, 15 Aug 2013 09:56:08 +0000 (02:56 -0700)]
auto merge of #8490 : huonw/rust/fromiterator-extendable, r=catamorphism
If they are on the trait then it is extremely annoying to use them as
generic parameters to a function, e.g. with the iterator param on the trait
itself, if one was to pass an Extendable<int> to a function that filled it
either from a Range or a Map<VecIterator>, one needs to write something
like:
since using a generic, i.e. `foo<E: Extendable<int, I>, I: Iterator<int>>`
means that `foo` takes 2 type parameters, and the caller has to specify them
(which doesn't work anyway, as they'll mismatch with the iterators used in
`foo` itself).
This patch changes it to:
fn foo<E: Extendable<int>>(e: &mut E, ...) { ... }
projects / rust.git / log