Adds an `uninit` intrinsic.
It's just an empty function, so llvm optimizes it down to nothing.
I changed all of the `init` intrinsic usages to `uninit` where it seemed appropriate to.
its own type. Use a bitset to represent built-in bounds. There
are several places in the language where only builtin bounds (aka kinds)
will be accepted, e.g. on closures, destructor type parameters perhaps,
and on trait types.
&str can be turned into @~str on demand, using to_owned(), so for
strings, we can create a specialized interner that accepts &str for
intern() and find() but stores and returns @~str.
Hi there,
Really enjoying Rust. Noticed a few typos so I searched around for a few more--here's some fixes.
Ran `make check` and got `summary of 24 test runs: 4868 passed; 0 failed; 330 ignored`.
Thanks!
Sean
At the moment this only includes type checking and there is no code generation support yet. I wanted to get the design reviewed first.
From discussion with @graydon at #5841, re-implemented as `#[simd]` attribute on structs.
Progressing towards #3499.
r? @ILyoan
This pulls all the logic for discovering the crate entry point into a new pass (out of resolve and typeck), then changes it so that main is only looked for at the crate level (`#[main]` can still be used anywhere).
I don't understand the special android logic here and worry that I may have broken it.
This "finishes" the generic deriving code (which I started in #5640), in the sense it supports everything that I can think of being useful. (Including lifetimes and type parameters on methods and traits, arguments and return values of (almost) any type, static methods.)
It closes#6149, but met with #6257, so the following doesn't work:
```rust
#[deriving(TotalEq)]
struct Foo<'self>(&'self int);
```
(It only fails for `TotalOrd`, `TotalEq` and `Clone`, since they are the only ones that call a method directly on sub-elements of the type, which means that the auto-deref interferes with the pointer.)
It also makes `Rand` (chooses a random variant, fills the fields with random values, including recursively for recursive types) and `ToStr` (`x.to_str()` is the same as `fmt!("%?", x)`) derivable, as well as converting IterBytes to the generic code (which made the code 2.5x shorter, more robust and added support for tuple structs).
({En,De}codable are trickier, so I'll convert them over later.)
Also fixed the docstring on `TC_ONCE_CLOSURE` (was accidentally the same as `TC_MUTABLE`) and shifted the `TC_EMPTY_ENUM` bit left by one since whatever previously used that bit has been removed.
Closes#5392 and #5393
I implemented the pop/swap methods for TrieMap/TreeMap/SmallIntMap, and I also updated all of them such that pop isn't just a remove/insert, but rather it's all done in one operation.
One thing I did notice is that with default methods it'd be really nice to define `insert` and `remove` in terms of `pop` and `swap` (or vice versa, just to have them available).
I just had `git apply` fix most of them and then did a quick skim over the diff to fix a few cases where it did the wrong thing (mostly replacing tabs with 4 spaces, when someone's editor had them at 8 spaces).
After much discussion on IRC and #4819, we have decided to revert to the old naming of the `/` operator. This does not change its behavior. In making this change, we also have had to rename some of the methods in the `Integer` trait. Here is a list of the methods that have changed:
- `Quot::quot` -> `Div::div`
- `Rem::rem` - stays the same
- `Integer::quot_rem` -> `Integer::div_rem`
- `Integer::div` -> `Integer::div_floor`
- `Integer::modulo` -> `Integer::mod_floor`
- `Integer::div_mod` -> `Integer::div_mod_floor`
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.
