Changes the ad-hoc closure adjustment into using adjustment info instead
of being separately driven from types, and likewise for autoderef.
Also takes care of autoref (the cases we should be seeing in consts,
at least, since we can't be doing method calls which would need the
ref-to-vec mode), which didn't quite work right previously.
However, "dereference" of a newtype isn't handled yet....
Also converts const cast-from-enum, because it used the same routine to
get the discriminant as what's renovated to construct the enums.
Also fixes ICE on struct-like variants as consts, and provides a slightly
less bad ICE for functional-update-like struct expressions in consts.
Note that in the ByValue case (which can't happen? yet?) we're still
effectively bitcasting, I think. So this change adds a way to assert
that that's safe.
Note also, for future reference, that LLVM's instcombine pass will turn
a bitcast into a GEP(0, 0, ...) if possible.
This change remains separate from the addition of adt.rs, even though
it's necessary for compatibility with pre-trans::adt representation,
to serve as an example of a change to the representation logic.
Later changes on this branch adapt the rest of rustc::middle::trans
to use this module instead of scattered hard-coded knowledge of
representations; a few of them also have improvements or cleanup for
adt.rs (and many added comments) that weren't drastic enough to justify
changing history to move them into this commit.
Work towards #4846.
- Institute new region defaults where all omitted regions get a fresh lifetime.
- Require explicit region names except in functions.
- Fix a bug in region parameterization inference. I've been putting this off because it will not be important when we remove RP inference in favor of explicit declarations, but then it was blocking this patch.
r? @pcwalton
Before:
````
test.rs:3:21: 3:30 error: expected constant integer for repeat count but found variable
test.rs:3 let a = ~[0, ..n]; //~ ERROR expected constant integer for repeat count but found variable
^~~~~~~~~
````
After:
````
test.rs:3:27: 3:28 error: expected constant integer for repeat count but found variable
test.rs:3 let a = ~[0, ..n]; //~ ERROR expected constant integer for repeat count but found variable
^
````
Before:
````
test.rs:3:21: 3:30 error: expected constant integer for repeat count but found variable
test.rs:3 let a = ~[0, ..n]; //~ ERROR expected constant integer for repeat count but found variable
^~~~~~~~~
````
After:
````
test.rs:3:27: 3:28 error: expected constant integer for repeat count but found variable
test.rs:3 let a = ~[0, ..n]; //~ ERROR expected constant integer for repeat count but found variable
^
````
The basic idea is that we add a new kind of adjustment, AutoAddEnv, that pads
an extern fn into a closure by adding the extra NULL word. Then there are a few
misc changes in trans to get the LLVM types to match up.
Fixes#4808.
This removes all but 6 uses of `drop {}` from the entire codebase. Removing any of the remaining uses causes various non-trivial bugs; I'll start reporting them once this gets merged.
Major changes are:
- replace ~[ty_param] with Generics structure, which includes
both OptVec<TyParam> and OptVec<Lifetime>;
- the use of syntax::opt_vec to avoid allocation for empty lists;
cc #4846
r? @graydon
Major changes are:
- replace ~[ty_param] with Generics structure, which includes
both OptVec<TyParam> and OptVec<Lifetime>;
- the use of syntax::opt_vec to avoid allocation for empty lists;
cc #4846
r?
#3406
Pretty straightforward. I'm using opaque pointers instead trying to get trans and core to agree on the types of the main function and crate map. One oddity is that this required changing the order of the `-lrustrt` argument to the linker in order to resolve `upcall_new_stack`. Linkers are mysterious.
r?
After this patch, macros declared in a module, function, or block can only be used inside of that module, function or block, with the exception of modules declared with the #[macro_escape] attribute; these modules allow macros to escape, and can be used as a limited macro export mechanism.
This pull request also includes miscellaneous comments, lots of new test cases, a few renamings, and a few as-yet-unused data definitions for hygiene.
Address #2281
```
-> % cat foo.rs
fn foo() -> int {
let bar = 10;
bad
}
```
```
-> % rustc foo.rs
foo.rs:4:4: 4:7 error: unresolved name: `bad`. Did you mean: `bar`?
foo.rs:4 bad
^~~
error: aborting due to previous error
```
Note on `struct_elt`: the comment is wrong, it actually dereferences the nth element of LLVM struct type if it is a pointer. That's why `T_ptr` is removed in `callee.rs`.
It appears that using deriving_eq/auto_encode on ASTs bumps up against the "gee this looks like infinite unfolding" limit of 10 in monomorphization. Increasing it to 30 seems to solve this problem for me....
Also, commenting and a few renames.
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...
