Cases like `Either<@int,()>` have a null case with at most one value but
a nonzero number of fields; if we misreport this, then bad things can
happen inside of, for example, pattern matching.
Closes#6117.
The test is reduced from a doc test, but making it separate ensures that
(1) unrelated changes to the docs won't leave this case uncovered, and
(2) the nature of any future failures will be more obvious to whoever
sees the tree on fire as a result.
Cases like `Either<@int,()>` have a null case with at most one value but
a nonzero number of fields; if we misreport this, then bad things can
happen inside of, for example, pattern matching.
Closes#6117.
First, it refers to a feature (trait bounds on type parameters) that's
apparently no longer in the language. Second, if I understand the issue
correctly, it should never have been a "run-pass" test because it was
supposed to fail.
One of the tests seems to have no current equivalent that's similar. Please let me know if that's incorrect, and I'll try fixing it instead of deleting it. I suppose a struct could be used instead of `any` and `match type`, but it seems like the original intent of the test was to exercise `match type`
As part of the numeric trait reform (see issue #4819), I have added the following traits to `core::num` and implemented them for Rust's primitive numeric types:
~~~rust
pub trait Bitwise: Not<Self>
+ BitAnd<Self,Self>
+ BitOr<Self,Self>
+ BitXor<Self,Self>
+ Shl<Self,Self>
+ Shr<Self,Self> {}
pub trait BitCount {
fn population_count(&self) -> Self;
fn leading_zeros(&self) -> Self;
fn trailing_zeros(&self) -> Self;
}
pub trait Bounded {
fn min_value() -> Self;
fn max_value() -> Self;
}
pub trait Primitive: Num
+ NumCast
+ Bounded
+ Neg<Self>
+ Add<Self,Self>
+ Sub<Self,Self>
+ Mul<Self,Self>
+ Quot<Self,Self>
+ Rem<Self,Self> {
fn bits() -> uint;
fn bytes() -> uint;
}
pub trait Int: Integer
+ Primitive
+ Bitwise
+ BitCount {}
pub trait Float: Real
+ Signed
+ Primitive {
fn NaN() -> Self;
fn infinity() -> Self;
fn neg_infinity() -> Self;
fn neg_zero() -> Self;
fn is_NaN(&self) -> bool;
fn is_infinite(&self) -> bool;
fn is_finite(&self) -> bool;
fn mantissa_digits() -> uint;
fn digits() -> uint;
fn epsilon() -> Self;
fn min_exp() -> int;
fn max_exp() -> int;
fn min_10_exp() -> int;
fn max_10_exp() -> int;
fn mul_add(&self, a: Self, b: Self) -> Self;
fn next_after(&self, other: Self) -> Self;
}
~~~
Note: I'm not sure my implementation for `BitCount::trailing_zeros` and `BitCount::leading_zeros` is correct for uints. I also need some assistance creating appropriate unit tests for them.
More work needs to be done in implementing specialized primitive floating-point and integer methods, but I'm beginning to reach the limits of my knowledge. Please leave your suggestions/critiques/ideas on #4819 if you have them – I'd very much appreciate hearing them.
I have also added an `Orderable` trait:
~~~rust
pub trait Orderable: Ord {
fn min(&self, other: &Self) -> Self;
fn max(&self, other: &Self) -> Self;
fn clamp(&self, mn: &Self, mx: &Self) -> Self;
}
~~~
This is a temporary trait until we have default methods. We don't want to encumber all implementors of Ord by requiring them to implement these functions, but at the same time we want to be able to take advantage of the speed of the specific numeric functions (like the `fmin` and `fmax` intrinsics).
From a cursory `git grep` this removes the last part of `core` that requires on `@` (other than `io` and the task local data section).
It renames `RandRes` to ~~StdRng~~ `IsaacRng` and `XorShiftState` to `XorShiftRng` as well as moving their constructors to static methods. To go with this, it adds `rng()` which is designed to be used when the programmer just wants a random number generator, without caring about which exact algorithm is being used.
It also removes all the `gen_int`, `gen_uint`, `gen_char` (etc) methods on `RngUtil` (by moving the defintions to the actual `Rand` instances). The replacement is using `RngUtil::gen`, either type-inferred or with an annotation (`rng.gen::<uint>()`).
I tried to have the `Rng` and `RngUtil` traits exported by `core::prelude` (since `core::rand` (except for `random()`) is useless without them), but this caused [an explosion of (seemingly unrelated) `error: unresolved import`'s](https://gist.github.com/5451839).
r? @nikomatsakis
This doesn't completely fix the x86 ABI for structs, but it does fix some cases. On linux, structs appear to be returned correctly now. On windows, structs are only returned by pointer when they are greater than 8 bytes. That scenario works now.
In the case where the struct is less than 8 bytes our generated code looks peculiar. When returning a pair of u16, C packs both variables into %eax to return them. Our generated code though expects to find one of the pair in %ax and the other in %dx. Similar for u8. I haven't looked into it yet.
There appears to also be struct passing problems on linux, where my `extern-pass-TwoU8s` and `extern-pass-TwoU16s` tests are failing.
This Adds a bunch of tests for passing and returning structs
of various sizes to C. It fixes the struct return rules on unix,
and on windows for structs of size > 8 bytes. Struct passing
on unix for structs under a certain size appears to still be broken.
This takes care of one of the last remnants of assumptions about enum layout. A type visitor is now passed a function to read a value's discriminant, then accesses fields by being passed a byte offset for each one. The latter may not be fully general, despite the constraints imposed on representations by borrowed pointers, but works for any representations currently planned and is relatively simple.
Closes#5652.
Update an old test to pass. I'm not 100% sure what the intent of the test was, but it's hard to see how I could have corrupted the intent of the test from the tiny changes I made.
This restores the trait that was lost in 216e85fadf. It will eventually be broken up into a more fine-grained trait hierarchy in the future once a design can be agreed upon.
This refactors much of the ast generation required for `deriving` instances into a common interface, so that new instances only need to specify what they do with the actual data, rather than worry about naming function arguments and extracting fields from structs and enum. (This all happens in `generic.rs`. I've tried to make sure it was well commented and explained, since it's a little abstract at points, but I'm sure it's still a little confusing.)
It makes instances like the comparison traits and `Clone` short and easy to write.
Caveats:
- Not surprisingly, this slows the expansion pass (in some cases, dramatically, specifically deriving Ord or TotalOrd on enums with many variants). However, this shouldn't be too concerning, since in a more realistic case (compiling `core.rc`) the time increased by 0.01s, which isn't worth mentioning. And, it possibly slows type checking very slightly (about 2% worst case), but I'm having trouble measuring it (and I don't understand why this would happen). I think this could be resolved by using traits and encoding it all in the type system so that monomorphisation handles everything, but that would probably be a little tricky to arrange nicely, reduce flexibility and make compiling rustc take longer. (Maybe some judicious use of `#[inline(always)]` would help too; I'll have a bit of a play with it.)
- The abstraction is not currently powerful enough for:
- `IterBytes`: doesn't support arguments of type other than `&Self`.
- `Encodable`/`Decodable` (#5090): doesn't support traits with parameters.
- `Rand` & `FromStr`; doesn't support static functions and arguments of type other than `&Self`.
- `ToStr`: I don't think it supports returning `~str` yet, but I haven't actually tried.
(The last 3 are traits that might be nice to have: the derived `ToStr`/`FromStr` could just read/write the same format as `fmt!("%?", x)`, like `Show` and `Read` in Haskell.)
I have ideas to resolve all of these, but I feel like it would essentially be a simpler version of the `mt` & `ty_` parts of `ast.rs`, and I'm not sure if the simplification is worth having 2 copies of similar code.
Also, makes Ord, TotalOrd and TotalEq derivable (closes#4269, #5588 and #5589), although a snapshot is required before they can be used in the rust repo.
If there is anything that is unclear (or incorrect) either here or in the code, I'd like to get it pointed out now, so I can explain/fix it while I'm still intimately familiar with the code.
This implements #5158. Currently it takes the command line args and the crate map. Since it doesn't take a `main` function pointer, you can't actually start the runtime easily, but that seems to be a shim to allow the current `rust_start` function to call into main.
However, you can do an end-run round the io library and do this:
```rust
use core::libc::{write, c_int, c_void, size_t, STDOUT_FILENO};
#[start]
fn my_start(_argc:int, _argv: **u8, _crate_map: *u8) -> int {
do str::as_buf("Hello World!\n") |s,len| {
unsafe {
write(STDOUT_FILENO, s as *c_void, len as size_t);
}
}
return 0;
}
```
Which is the most basic "Hello World" you can do in rust without starting up the runtime (though that has quite a lot to do with the fact that `core::io` uses `@` everywhere...)
Allow a deriving instance using the generic code to short-circuit for
any non-matching enum variants (grouping them all into a _ match),
reducing the number of arms required. Use this to speed up the Eq &
TotalEq implementations.
Good morning,
This first patch series adds support for `#[deriving(Decodable, Encodable)]`, but does not yet remove `#[auto_encode]` and `#[auto_decode]`. I need a snapshot to remove the old code. Along the way it also extends support for tuple structs and struct enum variants.
Also, it includes a minor fix to the pretty printer. We decided a while ago to use 4 spaces to indent a match arm instead of 2. This updates the pretty printer to reflect that.
There's no unifying theme here; I'm just trying to clear a bunch of small commits: removing dead code, adding comments, renaming to an upper-case type, fixing one test case.
Revert map.each to something which takes two parameters rather than a tuple. The current setup iterates over `BaseIter<(&'self K, &'self V)>` where 'self is a lifetime declared *in the `each()` method*. You can't place such a type in the impl declaration. The compiler currently allows it, but this will not be legal under #5656 and I'm pretty sure it's not sound now. It's too bad that maps can't implement `BaseIter` (at least not over a tuple as they do here) but I think it has to be this way for the time being.
r? @thestinger
rather than a tuple. The current setup iterates over
`BaseIter<(&'self K, &'self V)>` where 'self is a lifetime declared
*in the each method*. You can't place such a type in
the impl declaration. The compiler currently allows it,
but this will not be legal under #5656 and I'm pretty sure
it's not sound now.
Cleanup substitutions and treatment of generics around traits in a number of ways
- In a TraitRef, use the self type consistently to refer to the Self type:
- trait ref in `impl Trait<A,B,C> for S` has a self type of `S`.
- trait ref in `A:Trait` has the self type `A`
- trait ref associated with a trait decl has self type `Self`
- trait ref associated with a supertype has self type `Self`
- trait ref in an object type `@Trait` has no self type
- Rewrite `each_bound_traits_and_supertraits` to perform
substitutions as it goes, and thus yield a series of trait refs
that are always in the same 'namespace' as the type parameter
bound given as input. Before, we left this to the caller, but
this doesn't work because the caller lacks adequare information
to perform the type substitutions correctly.
- For provided methods, substitute the generics involved in the provided
method correctly.
- Introduce TypeParameterDef, which tracks the bounds declared on a type
parameter and brings them together with the def_id and (in the future)
other information (maybe even the parameter's name!).
- Introduce Subst trait, which helps to cleanup a lot of the
repetitive code involved with doing type substitution.
- Introduce Repr trait, which makes debug printouts far more convenient.
Fixes#4183. Needed for #5656.
r? @catamorphism
- In a TraitRef, use the self type consistently to refer to the Self type:
- trait ref in `impl Trait<A,B,C> for S` has a self type of `S`.
- trait ref in `A:Trait` has the self type `A`
- trait ref associated with a trait decl has self type `Self`
- trait ref associated with a supertype has self type `Self`
- trait ref in an object type `@Trait` has no self type
- Rewrite `each_bound_traits_and_supertraits` to perform
substitutions as it goes, and thus yield a series of trait refs
that are always in the same 'namespace' as the type parameter
bound given as input. Before, we left this to the caller, but
this doesn't work because the caller lacks adequare information
to perform the type substitutions correctly.
- For provided methods, substitute the generics involved in the provided
method correctly.
- Introduce TypeParameterDef, which tracks the bounds declared on a type
parameter and brings them together with the def_id and (in the future)
other information (maybe even the parameter's name!).
- Introduce Subst trait, which helps to cleanup a lot of the
repetitive code involved with doing type substitution.
- Introduce Repr trait, which makes debug printouts far more convenient.
Fixes#4183. Needed for #5656.
Performing a deep copy isn't ever desired for a persistent data
structure, and it requires a more complex implementation to do
correctly. A deep copy needs to check for cycles to avoid an infinite
loop.
bare function store (which is not in fact a kind of value) but rather
ty::TraitRef. Removes many uses of fail!() and other telltale signs of
type-semantic mismatch.
cc #4183 (not a fix, but related)
@nikomatsakis and I were talking about how the serializers were a bit too complicated. None of the users of With the `emit_option` and `read_option` functions, the serializers are now moving more high level. This patch series continues that trend. I've removed support for emitting specific string and vec types, and added support for emitting mapping types.
I believe this patch incorporates all expected syntax changes from extern
function reform (#3678). You can now write things like:
extern "<abi>" fn foo(s: S) -> T { ... }
extern "<abi>" mod { ... }
extern "<abi>" fn(S) -> T
The ABI for foreign functions is taken from this syntax (rather than from an
annotation). We support the full ABI specification I described on the mailing
list. The correct ABI is chosen based on the target architecture.
Calls by pointer to C functions are not yet supported, and the Rust type of
crust fns is still *u8.
Hey folks,
This patch series does some work on the json decoder, specifically with auto decoding of enums. Previously, we would take this code:
```
enum A {
B,
C(~str, uint)
}
```
and would encode a value of this enum to either `["B", []]` or `["C", ["D", 123]]`. I've changed this to `"B"` or `["C", "D", 123]`. This matches the style of the O'Caml json library [json-wheel](http://mjambon.com/json-wheel.html). I've added tests to make sure all this work.
In order to make this change, I added passing a `&[&str]` vec to `Decode::emit_enum_variant` so the json decoder can convert the name of a variant into it's position. I also changed the impl of `Encodable` for `Option<T>` to have the right upper casing.
I also did some work on the parser, which allows for `fn foo<T: ::cmp::Eq>() { ... }` statements (#5572), fixed the pretty printer properly expanding `debug!("...")` expressions, and removed `ast::expr_vstore_fixed`, which doesn't appear to be used anymore.
the types. Initially I thought it would be necessary to thread this data
through not only the AST but the types themselves, but then I remembered that
the pretty printer only cares about the AST. Regardless, I have elected to
leave the changes to the types intact since they will eventually be needed. I
left a few FIXMEs where it didn't seem worth finishing up since the code wasn't
crucial yet.
- Most functions that used to return `~[~str]` for a list of substrings got turned into iterators over `&str` slices
- Some cleanup of apis, docs and code layout
and from typeck, which is verboten. We are supposed to write inference results
into the FnCtxt and then these get copied over in writeback. Add assertions
that no inference by-products are added to this table.
Fixes#3888Fixes#4036Fixes#4492
This currently requires workarounds for the borrow checker not being flow-sensitive for `LinearMap` and `TrieMap`, but it can already be expressed for `TreeMap` and `SmallIntMap` without that.
Adds an assert_eq! macro that asserts that its two arguments are equal. Error messages can therefore be somewhat more informative than a simple assert, because the error message includes "expected" and "given" values.
the assert_eq! macro compares its arguments and fails if they're not
equal. It's more informative than fail_unless!, because it explicitly
writes the given and expected arguments on failure.
For bootstrapping purposes, this commit does not remove all uses of
the keyword "pure" -- doing so would cause the compiler to no longer
bootstrap due to some syntax extensions ("deriving" in particular).
Instead, it makes the compiler ignore "pure". Post-snapshot, we can
remove "pure" from the language.
There are quite a few (~100) borrow check errors that were essentially
all the result of mutable fields or partial borrows of `@mut`. Per
discussions with Niko I think we want to allow partial borrows of
`@mut` but detect obvious footguns. We should also improve the error
message when `@mut` is erroneously reborrowed.
adjusting a few foreign functions that were declared with by-ref
mode. This also allows us to remove by-val mode in the near future.
With copy mode, though, we have to be careful because Rust will implicitly pass
somethings by pointer but this may not be the C ABI rules. For example, rust
will pass a struct Foo as a Foo*. So I added some code into the adapters to
fix this (though the C ABI rules may put the pointer back, oh well).
This patch also includes a lint mode for the use of by-ref mode
in foreign functions as the semantics of this have changed.
r? @graydon
This removes `log` from the language. Because we can't quite implement it as a syntax extension (probably need globals at the least) it simply renames the keyword to `__log` and hides it behind macros.
After this the only way to log is with `debug!`, `info!`, etc. I figure that if there is demand for `log!` we can add it back later.
I am not sure that we ever agreed on this course of action, though I *think* there is consensus that `log` shouldn't be a statement.
This is the first in a series of patches I'm working on to clean up the code related to `deriving`. This patch allows
```
#[deriving_eq]
#[deriving_iter_bytes]
#[deriving_clone]
struct Foo { bar: uint }
```
to be replaced with:
```
#[deriving(Eq, IterBytes, Clone)]
struct Foo { bar: uint }
```
It leaves the old attributes alone for the time being.
Eventually I'd like to incorporate the new closest-match-suggestion infrastructure for mistyped trait names, and also pass the sub-attributes to the deriving code, so that the following will be possible:
```
#[deriving(TotalOrd(qux, bar))]
struct Foo { bar: uint, baz: char, qux: int }
```
This says to derive an `impl` in which the objects' `qux` fields are compared first, followed by `bar`, while `baz` is ignored in the comparison. If no fields are specified explicitly, all fields will be compared in the order they're defined in the `struct`. This might also be useful for `Eq`. Coming soon.
