This patch series is doing a couple things with the ultimate goal of removing `#[allow(vecs_implicitly_copyable)]`, although I'm not quite there yet. The main change is passing around `@~str`s in most places, and using `ref`s in others. As far as I could tell, there are no performance changes with these patches, and all the tests pass on my mac.
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.
`simplify_type` was bogus, as there was no way for it to handle enums
properly. It was also slow, because it created many Rust types at runtime. In
general creating Rust types during trans is a source of slowness, and I'd like
to avoid doing it as much as possible. (It is probably not possible to
eliminate it entirely, due to `subst`, but we should get rid of as much of it
as we can.) So this patch replaces `simplify_type` with `sizing_type_of`,
which creates a size-equivalent LLVM type directly without going through a
Rust type first.
Because this is causing an ICE in Servo, I'm rubber stamping it.
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.
r?
Apply deriving_eq to the data structures in ast.rs, and get rid of the custom definitions of eq that were everywhere. resulting ast.rs is about 400 lines shorter.
Also: add a few test cases and a bunch of comments.
Also: change ast_ty_to_ty_cache to use node ids rather than ast::ty's. I believe this was a suggestion related to my changes, and it appears to pass all tests.
Also: tiny doc fix, remove references to crate keywords.
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.
If an enum is isomorphic to unit, there's no need to use any bits to
represent it. The only obvious reason this wasn't the case was because
the enum could be C-like and have a user-specified discriminant -- but
that value is constant, so it doesn't need to be stored.
This change means that all newtype-like enums have the same size (and
layout) as their underlying type, which might be a useful property to
have, at least in terms of making programs' low-level behavior less
surprising.
...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.
The number of operands of the LLVM node initializing the array
underlying a const vector isn't always the array length -- if the
array is of a sufficiently primitive type and all the elements' values
are known (or something like that), LLVM uses a specialized Constant
subclass that stores the data packed, and thus has no operands. Oops.
But, because llsize_of now gives us a ConstantInt, we can just fix
mozilla/rust#3169 and this all goes away.
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 unsigned integers to uint-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 uint-template to_str and from_str overflow tests.
- 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.
lent. We can be more liberal with respect to the scope of the loan
if we do not own the data being lent, which used to be impossible
but can now occur with `&mut`.
r=pcwalton
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
Print out a clearer error message when a `for` gets
used with the wrong type of iterator. Also fix spans on `for` loop
bodies, and suppress some more derived errors.
r=brson
Closes#3651
ABIInfo provides a method to translate the type of foreign function.
The foreign trans uses the method to get ABI-specific type and
uses the result to generate LLVM instructions for wrapper and shim functions.
This eliminates an ICE in trans where the scope for a particular
borrow was a statement ID, but the code in trans that does cleanups
wasn't finding the block with that scope. As per #3860
preserve looks at a node ID to see if it's for a statement -- if it
is, it uses the enclosing scope instead when updating the map that
trans looks at later.
I added a comment noting that this is not the best fix (since it may
cause boxes to be frozen for longer than necessary) and referring
to #3511.
r=nmatsakis
def-id we have, so that the inliner can distinguish between external and
internal def-ids. Also add some comments explaining the distinction!
Fixes#4516.
r=graydon
Loosening the connection between the LLVM type and the Rust type
is necessary to use non-nullary enum constructors as const initializers,
because the const needs to be initialized with data of the actual type of
the variant in question, which is (generally) not the same as the u8
array in the `type_of` type.
Thus, referring to a const now requires casting the LLVM global to the
expected pointer type instead of using it as-is.
