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.
This is a natural extension of #4887, and handles the following three cases:
~~~~
a line with only /s
////////////////////////////////////////////
a line with only /s followed by whitespace
////////////////////////////////////////////
a block comment with only *s between two /s
/********************************/
~~~~
This patch finishes removing inner vector mutability from the vast majority of the compiler. Exceptions:
* core::dvec: ideally this entire type will be able to be replaced by `~[]`, but Niko asked me to hold off on removing Dvecs until he makes some fixes to borrowed pointers.
* liveness: liveness.rs is an impenetrable neutron star of deprecated semantics.
* compile-fail: I'm not sure if a lot of these tests are testing inner mutability or mutability in general. I figure that RIMOVing this folder should wait until this syntax is removed from the parser.
I also took this chance to remove many of the inner-mutability-related functions from core::vec, or as many uses of those functions as possible where still necessary. consume_mut and append_mut have been axed. cast_to_mut and cast_from_mut are still needed in a few places.
...ear
values to be copied. Rewrite kind computation so that instead of directly
computing the kind it computes what kinds of values are present in the type,
and then derive kinds based on that. I find this easier to think about.
Fixes#4821.
r? @catamorphism
values to be copied. Rewrite kind computation so that instead of directly
computing the kind it computes what kinds of values are present in the type,
and then derive kinds based on that. I find this easier to think about.
Fixes#4821.
This adds a `BaseIter` impl to `PriorityQueue`, `TreeMap`, `LinearMap` and `SmallIntMap`, and introduces a `ReverseIter` trait + implementations for `TreeMap`, `TreeSet` and `SmallIntMap`.
This is wasted space if the const is just an enum, but optimizing that
case without breaking everything else is an issue that can be addressed
separately.
The first commit message has most of the comments, but this pull request basically fixes a lot of issues surrounding the `unused_imports` warning/deny attribute.
Before this patch there were these problems:
1. Unused imports from `prelude.rs` were warned about with dummy spans, leading to a large number of confusing warnings.
2. Unused imports from `intrinsic.rs` were warned about with the file `<intrinsic>` which couldn't be forced to go away
3. Methods used from imported traites (like `io::WriterUtil`) resulted in an unused warning of the import even though it was used.
4. If one `use` statement imported N modules, M of which weren't used, M warning statements were issued.
5. If a glob import statement was used, each public export of the target module which wasn't used had a warning issued.
This patch deals with all these cases by doing:
1. Ignore unused imports from `prelude.rs` (indicated by a dummy span of 0)
2. Ignore unused imports from `intrinsic.rs` (test on the imported module name, is there a better way?)
3. Track when imported modules are used as candidates for methods, and just assume they're used. This may not end up being the actual case, but in theory not warning about an unused thing is worse than warning about a used thing.
4. Only issue one warning statement
5. Only issue one warning statement.
This is the first time I've edited the compiler itself, and I tried to keep up with the style around, but I may have missed something here or there...
1. Don't warn about anything not used in the prelude which is autmoatically
injected, accomplished with a test that the span is equal to a dummy span.
2. Don't warn about unused imports from the injected intrinsic module,
accomplished by testing against the name of the imported module
3. If anything is used from a glob import, don't warn about the glob import.
4. If an import imports more than one thing, and none of them are used, only
issue a warning once
Also updated the unused-imports-warn test to have stricter requirements on
error messages.
- Moved ToStr implementation of integers to int-template.rs.
- Marked the `str()` function as deprecated.
- Forwarded all conversion functions to `core::num::to_str_common()`
and `core::num::from_str_common()`.
- Fixed most places in the codebase where `to_str()` is being used.
- Added int-template to_str and from_str overflow tests.
LinearMap is quite a bit faster, and is fully owned/sendable without
requiring copies. The older std::map also doesn't use explicit self and
relies on mutable fields.
Changes:
- Refactor move mode computation
- Removes move mode arguments, unary move, capture clauses
(though they still parse for backwards compatibility)
- Simplify how moves are handled in trans
- Fix a number of illegal copies that cropped up
- Workaround for bug involving def-ids in params
(see details below)
Future work (I'll open bugs for these...):
- Improve error messages for moves that are due
to bindings
- Add support for moving owned content like a.b.c
to borrow check, test in trans (but I think it'll
"just work")
- Proper fix for def-ids in params
Def ids in params:
Move captures into a map instead of recomputing.
This is a workaround for a larger bug having to do with the def-ids associated
with ty_params, which are not always properly preserved when inlining. I am
not sure of my preferred fix for the larger bug yet. This current fix removes
the only code in trans that I know of which relies on ty_param def-ids, but
feels fragile.
Add a new method_super origin for supertrait methods. Also make
coherence create a table that maps pairs of trait IDs and self types
to impl IDs, so that it's possible to check a supertrait method
knowing only its index in its trait's methods (without knowing all
supertraits for a given trait).
r=nmatsakis and graydon -- with hope, we'll revamp all of this code as
per #4678, but for now this fixes the bug.
Closes#3979
"Dual impls" are impls that are both type implementations and trait
implementations. They can lead to ambiguity and so this patch removes them
from the language.
This also enforces coherence rules. Without this patch, records can implement
traits not defined in the current crate. This patch fixes this, and updates
all of rustc to adhere to the new enforcement. Most of this patch is fixing
rustc to obey the coherence rules, which involves converting a bunch of records
to structs.
needed.
Regarding soundness: there was a subtle bug in how it was done before; see the
compile-fail test for an example.
Regarding reborrowing: reborrowing allows mut and const
slices/borrowed-pointers to be used with pure fns that expect immutable data.
r=brson
