I've moved all intrinsics in a single file (libcore/private/intrinsics.rs) and changed a few files to make use of this file (e.g. vec.rs: move_val_init).
Two intrinsics have been commented out:
visit_tydesc: it uses TyDesc and TyVisitor, this would create a dependency on librustc which seems undesirable.
frame_address: I really had no idea what it should look like without the legacy modes (would it even work? In several places in libcore the (legacy-modes) intrinsics were wrapped
with a normal fn) and what it was supposed to do.
Some documentation is still required, but many names are fairly self-explanatory.
As far as I can tell, the only reason run-pass/type-use-i1-versus-i8
is trying to do a read is because that code was left over from the
original program the issue was found in. When that test is run as
part of check-fast, and apparently only in that case, the test blocks
indefinitely, which is bad.
r? @graydon - This is for greater uniformity (for example, macros that generate
tuples). rustc already supported 1-tuple patterns, but there was no
way to construct a 1-tuple term.
@graydon , as far as your comment on #4898 - it did turn out to be solvable inside the macro (since @luqmana already fixed it using structs instead), but I still think it's a good idea to allow 1-tuples, for uniformity. I don't think anyone is likely to trip over it, and I'm not too worried that it changes the amount of ambiguity.
These commits take the old bitv implementation and modernize it with an explicit self, some minor touchups, and using what I think is some more recent patterns (like `::new` instead of `Type()`).
Additionally, this adds an implementation of `container::Set` on top of a bit vector to have as a set of `uint`s. I initially tried to parameterize the type for the set to be `T: NumCast` but I was hitting build problems in stage0 which I think means that it's not in a snapshot yet, so it's just hardcoded as a set of `uint`s now. In the future perhaps it could be parameterized. I'm not sure if it would really add anything, though, so maybe it's nicer to be hardcoded anyway.
I also added some extra methods to do normal bit vector operations on the set in-place, but these aren't a part of the `Set` trait right now. I haven't benchmarked any of these operations just yet, but I imagine that there's quite a lot of room for optimization here and there.
This is for greater uniformity (for example, macros that generate
tuples). rustc already supported 1-tuple patterns, but there was no
way to construct a 1-tuple term.
As far as I can tell, the only reason run-pass/type-use-i1-versus-i8
is trying to do a read is because that code was left over from the
original program the issue was found in. When that test is run as
part of check-fast, and apparently only in that case, the test blocks
indefinitely, which is bad.
Consts of such enums are aligned correctly, so we could either misalign
them to match the type_of, or fix the type_of. The latter seems like a
better idea.
* use a proper exported data type with private fields
* implement core::container::Container
* use the current constructor convention
* use explicit self
* get rid of DVec and the mutable fields
Closes#2343
Issue #3869
review? @nikomatsakis
Convert all uses of vec::slice to vec::view Issue #3869
Rename const_view to const_slice
Renamed mut_view to mut_slice
Fix windows build error. `buf` is borrowed by the call to
`as_mut_buf()` and so we must invoke `slice()` outside of that
call.
