- When selecting an implicit trait impl for an unboxed closure, plumb
through and use the substitutions from impl selection instead of
using those from the current param environment in trans, which may
be incorrect.
- When generating a function declaration for an unboxed closure, plumb
through the substitutions from the param environment of the closure
as above. Also normalize the type to avoid generating duplicate
declarations due to regions being inconsistently replaced with
ReStatic elsewhere.
- Do not place the closure type in the self param space when
translating the unboxed closure callee, etc. It is not actually
used, and doing so conflicts with the self substitution from
default trait methods.
Closes#18661Closes#18685
Fixes#18567. Struct{x:foo, .. with_expr} did not walk with_expr, which allowed
using moved variables in some cases. The CFG for structs also built up with
with_expr happening before the fields, which is now reversed. (Fields are now
before the with_expr in the CFG)
variables in the intracrate case. This requires a deeper distinction
between inter- and intra-crate so as to keep coherence working.
I suspect the best fix is to generalize the recursion check that
exists today, but this requires a bit more refactoring to achieve.
(In other words, where today it says OK for an exact match, we'd want
to not detect exact matches but rather skolemize each trait-reference
fresh and return AMBIG -- but that requires us to make builtin bounds
work shallowly like everything else and move the cycle detection into
the fulfillment context.)
This branch cleans up overloaded operator resolution so that it is strictly based on the traits in `ops`, rather than going through the normal method lookup mechanism. It also adds full support for autoderef to overloaded index (whereas before autoderef only worked for non-overloaded index) as well as for the slicing operators.
This is a [breaking-change]: in the past, we were accepting combinations of operands that were not intended to be accepted. For example, it was possible to compare a fixed-length array and a slice, or apply the `!` operator to a `&int`. See the first two commits in this pull-request for examples.
One downside of this change is that comparing fixed-length arrays doesn't always work as smoothly as it did before. Before this, comparisons sometimes worked due to various coercions to slices. I've added impls for `Eq`, `Ord`, etc for fixed-lengths arrays up to and including length 32, but if the array is longer than that you'll need to either newtype the array or convert to slices. Note that this plays better with deriving in any case than the previous scheme.
Fixes#4920.
Fixes#16821.
Fixes#15757.
cc @alexcrichton
cc @aturon
Key points are:
1. `a + b` maps directly to `Add<A,B>`, where `A` and `B` are the types of `a` and `b`.
2. Indexing and slicing autoderefs consistently.
This fixes some metadata/AST encoding problems that lead to ICEs. The way this is currently handled will need revisiting if abstract return types are added, as unboxed closure types from extern crates could show up without being inlined into the local crate.
Closes#16790 (I think this was fixed earlier by accident and just needed a test case)
Closes#18378Closes#18543
r? @pcwalton
If a dylib is being produced, the compiler will now first check to see if it can
be created entirely statically before falling back to dynamic dependencies. This
behavior can be overridden with `-C prefer-dynamic`.
Due to the alteration in behavior, this is a breaking change. Any previous users
relying on dylibs implicitly maximizing dynamic dependencies should start
passing `-C prefer-dynamic` to compilations.
Closes#18499
[breaking-change]
This almost completely avoids GEPi's and pointer manipulation,
postponing it until the end with one big write of the whole vector. This
leads to a small speed-up in compilation, and makes it easier for LLVM
to work with the values, e.g. with `--opt-level=0`,
pub fn foo() -> f32x4 {
f32x4(0.,0.,0.,0.)
}
was previously compiled to
define <4 x float> @_ZN3foo20h74913e8b13d89666eaaE() unnamed_addr #0 {
entry-block:
%sret_slot = alloca <4 x float>
%0 = getelementptr inbounds <4 x float>* %sret_slot, i32 0, i32 0
store float 0.000000e+00, float* %0
%1 = getelementptr inbounds <4 x float>* %sret_slot, i32 0, i32 1
store float 0.000000e+00, float* %1
%2 = getelementptr inbounds <4 x float>* %sret_slot, i32 0, i32 2
store float 0.000000e+00, float* %2
%3 = getelementptr inbounds <4 x float>* %sret_slot, i32 0, i32 3
store float 0.000000e+00, float* %3
%4 = load <4 x float>* %sret_slot
ret <4 x float> %4
}
but now becomes
define <4 x float> @_ZN3foo20h74913e8b13d89666eaaE() unnamed_addr #0 {
entry-block:
ret <4 x float> zeroinitializer
}
Removes all target-specific knowledge from rustc. Some targets have changed
during this, but none of these should be very visible outside of
cross-compilation. The changes make our targets more consistent.
iX86-unknown-linux-gnu is now only available as i686-unknown-linux-gnu. We
used to accept any value of X greater than 1. i686 was released in 1995, and
should encompass the bare minimum of what Rust supports on x86 CPUs.
The only two windows targets are now i686-pc-windows-gnu and
x86_64-pc-windows-gnu.
The iOS target has been renamed from arm-apple-ios to arm-apple-darwin.
A complete list of the targets we accept now:
arm-apple-darwin
arm-linux-androideabi
arm-unknown-linux-gnueabi
arm-unknown-linux-gnueabihf
i686-apple-darwin
i686-pc-windows-gnu
i686-unknown-freebsd
i686-unknown-linux-gnu
mips-unknown-linux-gnu
mipsel-unknown-linux-gnu
x86_64-apple-darwin
x86_64-unknown-freebsd
x86_64-unknown-linux-gnu
x86_64-pc-windows-gnu
Closes#16093
[breaking-change]
If a dylib is being produced, the compiler will now first check to see if it can
be created entirely statically before falling back to dynamic dependencies. This
behavior can be overridden with `-C prefer-dynamic`.
Due to the alteration in behavior, this is a breaking change. Any previous users
relying on dylibs implicitly maximizing dynamic dependencies should start
passing `-C prefer-dynamic` to compilations.
Closes#18499
[breaking-change]
If the overloaded method does not have a tuple or unit type as its
first non-self parameter, produce a list of error types with the
correct length to prevent a later index bound panic. This typically
occurs due to propagation of an earlier type error or unconstrained
type variable. Closes#18532
* Moves multi-collection files into their own directory, and splits them into seperate files
* Changes exports so that each collection has its own module
* Adds underscores to public modules and filenames to match standard naming conventions
(that is, treemap::{TreeMap, TreeSet} => tree_map::TreeMap, tree_set::TreeSet)
* Renames PriorityQueue to BinaryHeap
* Renames SmallIntMap to VecMap
* Miscellanious fallout fixes
[breaking-change]
Always translate the ID into the local crate ID space since
presently the only way to encounter an unboxed closure type
from another crate is to inline once of its functions.
This may need to change if abstract return types are added.
Closes#18543
In some obscure circumstances, failure to do this can cause
unsubstituted type parameters to show up where they aren't
expected and cause an ICE.
Closes#18514
As part of the collections reform RFC, this commit removes all collections
traits in favor of inherent methods on collections themselves. All methods
should continue to be available on all collections.
This is a breaking change with all of the collections traits being removed and
no longer being in the prelude. In order to update old code you should move the
trait implementations to inherent implementations directly on the type itself.
Note that some traits had default methods which will also need to be implemented
to maintain backwards compatibility.
[breaking-change]
cc #18424
Teach variance checker about the lifetime bounds that appear in trait object types.
[breaking-change] This patch fixes a hole in the type system which resulted in lifetime parameters that were only used in trait objects not being checked. It's hard to characterize precisely the changes that might be needed to fix target code.
cc #18262 (this fixes the test case by @jakub- but I am not sure if this is the same issue that @alexcrichton was reporting)
r? @pnkfelix
Fixes#18205
- The signature of the `*_equiv` methods of `HashMap` and similar structures have changed, and now require one less level of indirection. Change your code from:
``` rust
hashmap.find_equiv(&"Hello");
hashmap.find_equiv(&&[0u8, 1, 2]);
```
to:
``` rust
hashmap.find_equiv("Hello");
hashmap.find_equiv(&[0u8, 1, 2]);
```
- The generic parameter `T` of the `Hasher::hash<T>` method have become `Sized?`. Downstream code must add `Sized?` to that method in their implementations. For example:
``` rust
impl Hasher<FnvState> for FnvHasher {
fn hash<T: Hash<FnvState>>(&self, t: &T) -> u64 { /* .. */ }
}
```
must be changed to:
``` rust
impl Hasher<FnvState> for FnvHasher {
fn hash<Sized? T: Hash<FnvState>>(&self, t: &T) -> u64 { /* .. */ }
// ^^^^^^
}
```
[breaking-change]
---
After review I'll squash the commits and update the commit message with the above paragraph.
r? @aturon
cc #16918
This fixes ICEs caused by late-bound lifetimes ending up in argument
datum types and being used in cleanup - user Drop impl's would then
fail to monomorphize if the type was used to look up the impl of a
method call - which happens in trans now, I presume for multidispatch.
- The signature of the `*_equiv` methods of `HashMap` and similar structures
have changed, and now require one less level of indirection. Change your code
from:
```
hashmap.find_equiv(&"Hello");
hashmap.find_equiv(&&[0u8, 1, 2]);
```
to:
```
hashmap.find_equiv("Hello");
hashmap.find_equiv(&[0u8, 1, 2]);
```
- The generic parameter `T` of the `Hasher::hash<T>` method have become
`Sized?`. Downstream code must add `Sized?` to that method in their
implementations. For example:
```
impl Hasher<FnvState> for FnvHasher {
fn hash<T: Hash<FnvState>>(&self, t: &T) -> u64 { /* .. */ }
}
```
must be changed to:
```
impl Hasher<FnvState> for FnvHasher {
fn hash<Sized? T: Hash<FnvState>>(&self, t: &T) -> u64 { /* .. */ }
// ^^^^^^
}
```
[breaking-change]
This PR aims to improve the readability of diagnostic messages that involve unresolved type variables. Currently, messages like the following:
```rust
mismatched types: expected `core::result::Result<uint,()>`, found `core::option::Option<<generic #1>>`
<anon>:6 let a: Result<uint, ()> = None;
^~~~
mismatched types: expected `&mut <generic #2>`, found `uint`
<anon>:7 f(42u);
^~~
```
tend to appear unapproachable to new users. [0] While specific type var IDs are valuable in
diagnostics that deal with more than one such variable, in practice many messages
only mention one. In those cases, leaving out the specific number makes the messages
slightly less terrifying.
```rust
mismatched types: expected `core::result::Result<uint, ()>`, found `core::option::Option<_>`
<anon>:6 let a: Result<uint, ()> = None;
^~~~
mismatched types: expected `&mut _`, found `uint`
<anon>:7 f(42u);
^~~
```
As you can see, I also tweaked the aesthetics slightly by changing type variables to use the type hole syntax _. For integer variables, the syntax used is:
```rust
mismatched types: expected `core::result::Result<uint, ()>`, found `core::option::Option<_#1i>`
<anon>:6 let a: Result<uint, ()> = Some(1);
```
and float variables:
```rust
mismatched types: expected `core::result::Result<uint, ()>`, found `core::option::Option<_#1f>`
<anon>:6 let a: Result<uint, ()> = Some(0.5);
```
[0] https://twitter.com/coda/status/517713085465772032
Closes https://github.com/rust-lang/rust/issues/2632.
Closes https://github.com/rust-lang/rust/issues/3404.
Closes https://github.com/rust-lang/rust/issues/18426.
This commit enables implementations of IndexMut for a number of collections,
including Vec, RingBuf, SmallIntMap, TrieMap, TreeMap, and HashMap. At the same
time this deprecates the `get_mut` methods on vectors in favor of using the
indexing notation.
cc #18424
I just found this patch which at some point solved a problem I encountered. Unfortunately I apparently dropped it before I managed to write a test case. I'll try to dig up the code that triggered the issue.
The error messages still aren’t as good as they were before DST, but they better
describe the actual problem, not mentioning `Sized` at all (because that bound
is normally implied, not explicitly stated).
Closes#17567.
Closes#18040.
Closes#18159.
closes#17670
[breaking-change]
Traits must be object-safe if they are to be used in trait objects. This might require splitting a trait into object-safe and non-object-safe parts.
Some standard library traits in std::io have been split - Reader has new traits BytesReader (for the bytes method) and AsRefReader (for by_ref), Writer has new trait AsRefWriter (for by_ref). All these new traits have blanket impls, so any type which implements Reader or Writer (respectively) will have an implmentation of the new traits. To fix your code, you just need to `use` the new trait.
Diagnostics such as the following
```
mismatched types: expected `core::result::Result<uint,()>`, found `core::option::Option<<generic #1>>`
<anon>:6 let a: Result<uint, ()> = None;
^~~~
mismatched types: expected `&mut <generic #2>`, found `uint`
<anon>:7 f(42u);
^~~
```
tend to be fairly unappealing to new users. While specific type var IDs are valuable in
diagnostics that deal with more than one such variable, in practice many messages
only mention one. In those cases, leaving out the specific number makes the messages
slightly less terrifying.
In addition, type variables have been changed to use the type hole syntax `_` in diagnostics.
With a variable ID, they're printed as `_#id` (e.g. `_#1`). In cases where the ID is left out,
it's simply `_`. Integer and float variables have an additional suffix after the number, e.g.
`_#1i` or `_#3f`.
This common representation for delimeters should make pattern matching easier. Having a separate `token::DelimToken` enum also allows us to enforce the invariant that the opening and closing delimiters must be the same in `ast::TtDelimited`, removing the need to ensure matched delimiters when working with token trees.
This includes updating the language items and marking what needs to
change after a snapshot.
If you do not use the standard library, the language items you need to
implement have changed. For example:
```rust
#[lang = "fail_fmt"] fn fail_fmt() -> ! { loop {} }
```
is now
```rust
#[lang = "panic_fmt"] fn panic_fmt() -> ! { loop {} }
```
Related, lesser-implemented language items `fail` and
`fail_bounds_check` have become `panic` and `panic_bounds_check`, as
well. These are implemented by `libcore`, so it is unlikely (though
possible!) that these two renamings will affect you.
[breaking-change]
Fix test suite
https://github.com/rust-lang/rfcs/pull/221
The current terminology of "task failure" often causes problems when
writing or speaking about code. You often want to talk about the
possibility of an operation that returns a Result "failing", but cannot
because of the ambiguity with task failure. Instead, you have to speak
of "the failing case" or "when the operation does not succeed" or other
circumlocutions.
Likewise, we use a "Failure" header in rustdoc to describe when
operations may fail the task, but it would often be helpful to separate
out a section describing the "Err-producing" case.
We have been steadily moving away from task failure and toward Result as
an error-handling mechanism, so we should optimize our terminology
accordingly: Result-producing functions should be easy to describe.
To update your code, rename any call to `fail!` to `panic!` instead.
Assuming you have not created your own macro named `panic!`, this
will work on UNIX based systems:
grep -lZR 'fail!' . | xargs -0 -l sed -i -e 's/fail!/panic!/g'
You can of course also do this by hand.
[breaking-change]
This adds a `Substs` field to `ty_unboxed_closure` and plumbs basic
handling of it throughout the compiler. trans now correctly
monomorphizes captured free variables and llvm function defs. This
fixes uses of unboxed closures which reference a free type or region
parameter from their environment in either their signature or free
variables. Closes#16791
The arenas write the value to memory and then return a non-aliasing
reference to it. The returned reference can be mutable and can be
coerced to an immutable one.
[breaking-change]
Use the `is_shorthand` field introduced by #17813 (ead6c4b) to make the
prettyprinter output the shorthand form. Fixes a few places that set
`is_shorthand: true` when the pattern is not a PatIdent with the same
name as the field.
- Correctly categorize env pointer deref for `FnMut` as declared
rather than inherited. This fixes an assert in borrowck.
Closes#18238
- Categorize env pointer deref as mutable only if the closure is
`FnMut` *and* the original variable is declared mutable. This
disallows capture-by-value `FnMut` closures from mutating captured
variables that aren't declared mutable. This is a difference
from the equivalent desugared code which would permit it, but
it is consistent with the behavior of procs. Closes#18335
- Avoid computing info about the env pointer if there isn't one.
Rather than doing it top-down, with a known expected type, we will now simply establish the appropriate constraints between the pattern and the expression it destructures.
Closes#8783.
Closes#10200.
Adds an `assume` intrinsic that gets translated to llvm.assume. It is
used on a boolean expression and allows the optimizer to assume that
the expression is true.
This implements #18051.
Instead of checking patterns in a top-down fashion with a known
expected type on entry, this changes makes typeck establish
appropriate constraints between a pattern and the expression
it destructures, and lets inference compute the final types
or produce good error messages if it's impossible.
This reverts commit a0ec902e23 "Avoid
unnecessary temporary on assignments".
Leaving out the temporary for the functions return value can lead to a
situation that conflicts with rust's aliasing rules.
Given this:
````rust
fn func(f: &mut Foo) -> Foo { /* ... */ }
fn bar() {
let mut foo = Foo { /* ... */ };
foo = func(&mut foo);
}
````
We effectively get two mutable references to the same variable `foo` at
the same time. One for the parameter `f`, and one for the hidden
out-pointer. So we can't just `trans_into` the destination directly, but
must use `trans` to get a new temporary slot from which the result can
be copied.
of tracking individual candidates per impl, we just track one
candidate for the extension trait itself, and let the trait resolution
handle walking the individual impls and so forth. Also change the
interface to report back a richer notion of error.
This is a large spring-cleaning commit now that the 0.12.0 release has passed removing an amount of deprecated functionality. This removes a number of deprecated crates (all still available as cargo packages in the rust-lang organization) as well as a slew of deprecated functions. All `#[crate_id]` support has also been removed.
I tried to avoid anything that was recently deprecated, but I may have missed something! The major pain points of this commit is the fact that rustc/syntax have `#[allow(deprecated)]`, but I've removed that annotation so moving forward they should be cleaned up as we go.
Spring cleaning is here! In the Fall! This commit removes quite a large amount
of deprecated functionality from the standard libraries. I tried to ensure that
only old deprecated functionality was removed.
This is removing lots and lots of deprecated features, so this is a breaking
change. Please consult the deprecation messages of the deleted code to see how
to migrate code forward if it still needs migration.
[breaking-change]
When translating the unboxing shim, account for the fact that the shim translation has already performed the necessary unboxing of input types and values when forwarding to the shimmed function. This prevents ICEing or generating incorrect code.
Closes#16739
Check object lifetime bounds in coercions, not just trait bounds. Fixes#18055.
r? @pcwalton
This is a [breaking change]. Change code like this:
fn foo(v: &[u8]) -> Box<Clone+'static> { ... }
to make the lifetimes agree:
// either...
fn foo(v: &'static[u8]) -> Box<Clone+'static> { box v }
// or ...
fn foo<'a>(v: &'a [u8]) -> Box<Clone+'a> { box v }
The representability-checking routine ```is_type_representable``` failed to detect structural recursion in some cases, leading to stack overflow later on.
The first problem was in the loop in the ```find_nonrepresentable``` function. We were improperly terminating the iteration if we saw a ```ContainsRecursive``` condition. We should have kept going in case a later member of the struct (or enum, etc) being examined was ```SelfRecursive```. The example from #17431 triggered this issue:
```rust
use std::sync::Mutex;
struct Foo { foo: Mutex<Option<Foo>> }
impl Foo { fn bar(self) {} }
fn main() {}
```
I'm not 100% sure, but I think the ```ty_enum``` case of ```fn type_structurally_recursive``` had a similar problem, since it could ```break``` on ```ContainsRecursive``` before looking at all variants. I've replaced this with a ```flat_map``` call.
The second problem was that we were failing to identify code like ```struct Foo { foo: Option<Option<Foo>> }``` as SelfRecursive, even though we correctly identified ```struct Foo { foo: Option<Foo> }```. This was caused by using DefId's for the ```ContainsRecursive``` check, which meant the nested ```Option```s were identified as illegally recursive (because ```ContainsRecursive``` is not an error, we would then keep compiling and eventually hit a stack overflow).
In order to make sure that we can recurse through the different ```Option``` invocations, I've changed the type of ```seen``` from ```Vec<DefId>``` to ```Vec<t>``` and added a separate ```same_type``` function to check whether two types are the same when generics are taken into account. Now we only return ```ContainsRecursive``` when this stricter check is satisfied. (There's probably a better way to do this, and I'm not sure my code is entirely correct--but my knowledge of rustc internals is pretty limited, so any help here would be appreciated!)
Note that the ```SelfRecursive``` check is still comparing ```DefId```s--this is necessary to prevent code like this from being allowed:
```rust
struct Foo { x: Bar<Foo> }
struct Bar<T> { x: Bar<Foo> }
```
All four of the new ```issue-17431``` tests cause infinite recursion on master, and errors with this pull request. I wrote the extra ```issue-3008-4.rs``` test to make sure I wasn't introducing a regression.
Fixes#17431.
This adds ‘help’ diagnostic messages to rustc. This is used for anything that provides help to the user, particularly the `--explain` messages that were previously integrated into the relevant error message.
They look like this:
```
match.rs:10:13: 10:14 error: unreachable pattern [E0001]
match.rs:10 1 => {},
^
match.rs:3:1: 3:38 note: in expansion of foo!
match.rs:7:5: 20:2 note: expansion site
match.rs:10:13: 10:14 help: pass `--explain E0001` to see a detailed explanation
```
(`help` is coloured cyan.) Adding these errors on a separate line stops the lines from being too long, as discussed in #16619.
When translating the unboxing shim, account for the fact that the shim
translation has already performed the necessary unboxing of input
types and values when forwarding to the shimmed function. This
prevents ICEing or generating incorrect code.
Closes#16739
When an overloaded call expression has parameters but the function
object takes none, construct an array of formal argument types with
the arity of the call expression so that we don't fail by indexing out
of bounds later.
Closes#16939
- Unify the representations of `cat_upvar` and `cat_copied_upvar`
- In `link_reborrowed_region`, account for the ability of upvars to
change their mutability due to later processing. A map of recursive
region links we may want to establish in the future is maintained,
with the links being established when the kind of the borrow is
adjusted.
- When categorizing upvars, add an explicit deref that represents the
closure environment pointer for closures that do not take the
environment by value. The region for the implicit pointer is an
anonymous free region type introduced for this purpose. This
creates the necessary constraint to prevent unsound reborrows from
the environment.
- Add a note to categorizations to make it easier to tell when extra
dereferences have been inserted by an upvar without having to
perform deep pattern matching.
- Adjust borrowck to deal with the changes. Where `cat_upvar` and
`cat_copied_upvar` were previously treated differently, they are
now both treated roughly like local variables within the closure
body, as the explicit derefs now ensure proper behavior. However,
error diagnostics had to be changed to explicitly look through the
extra dereferences to avoid producing confusing messages about
references not present in the source code.
Closes issue #17403. Remaining work:
- The error diagnostics that result from failed region inference are
pretty inscrutible and should be improved.
Code like the following is now rejected:
let mut x = 0u;
let f = || &mut x;
let y = f();
let z = f(); // multiple mutable references to the same location
This also breaks code that uses a similar construction even if it does
not go on to violate aliasability semantics. Such code will need to
be reworked in some way, such as by using a capture-by-value closure
type.
[breaking-change]
Adds an `assume` intrinsic that gets translated to llvm.assume. It is
used on a boolean expression and allows the optimizer to assume that
the expression is true.
This implements #18051.
librustc: Improve method autoderef/deref/index behavior more, and enable IndexMut on mutable vectors.
This fixes a bug whereby the mutability fixups for method behavior were
not kicking in after autoderef failed to happen at any level. It also
adds support for `Index` to the fixer-upper.
Closes#12825.
r? @pnkfelix
LLVM generates wrong code (which may be an instance of compile-time UB) when
faced with types that take lots of memory - bigger than the address space.
Make using such types a trans error. While trans errors are bad, overbig
types are expected to be very rare.
Use the integer sizes LLVM uses, rather than having random projections
laying around. Sizes are u64, Alignments are u32, C_*int is target-dependent
but 64-bit is fine (the int -> C_int conversion is non-precision-losing,
but it can be preceded by `as int` conversions which are, so it is
somewhat ugly. However, being able to suffix a `u` to properly infer
integer types is nice).
RFC 344 proposes a set of naming conventions for lints. This commit
renames existing lints to follow the conventions.
Use the following sed script to bring your code up to date:
```
s/unnecessary_typecast/unused_typecasts/g
s/unsigned_negate/unsigned_negation/g
s/type_limits/unused_comparisons/g
s/type_overflow/overflowing_literals/g
s/ctypes/improper_ctypes/g
s/owned_heap_memory/box_pointers/g
s/unused_attribute/unused_attributes/g
s/path_statement/path_statements/g
s/unused_must_use/unused_must_use/g
s/unused_result/unused_results/g
s/non_uppercase_statics/non_upper_case_globals/g
s/unnecessary_parens/unused_parens/g
s/unnecessary_import_braces/unused_import_braces/g
s/unused_unsafe/unused_unsafe/g
s/unsafe_block/unsafe_blocks/g
s/unused_mut/unused_mut/g
s/unnecessary_allocation/unused_allocation/g
s/missing_doc/missing_docs/g
s/unused_imports/unused_imports/g
s/unused_extern_crate/unused_extern_crates/g
s/unnecessary_qualification/unused_qualifications/g
s/unrecognized_lint/unknown_lints/g
s/unused_variable/unused_variables/g
s/dead_assignment/unused_assignments/g
s/unknown_crate_type/unknown_crate_types/g
s/variant_size_difference/variant_size_differences/g
s/transmute_fat_ptr/fat_ptr_transmutes/g
```
Closes#16545Closes#17932
Due to deprecation, this is a:
[breaking-change]
`IndexMut` on mutable vectors.
This fixes a bug whereby the mutability fixups for method behavior were
not kicking in after autoderef failed to happen at any level. It also
adds support for `Index` to the fixer-upper.
Closes#12825.
Function arguments are (hopefully!) the last places where allocas don't
get proper markers for the end of their lifetimes. This means that this
code using 64 bytes of stack for the function arguments:
````rust
std::io::println("1");
std::io::println("2");
std::io::println("3");
std::io::println("4");
````
But with the proper lifetime markers, the slots can be reused, and
the arguments only need 16 bytes of stack.
Doing so would incur deeply nested expansion of the tree with no useful
side effects. This is problematic for "wide" data types such as structs
with dozens of fields but where only a few are actually being matched or bound.
Most notably, matching a fixed slice would use a number of stack frames that
grows with the number of elements in the slice.
Fixes#17877.
Implement multidispatch and conditional dispatch. Because we do not attempt to preserve crate concatenation, this is a backwards compatible change. This is not yet fully integrated into method dispatch, so "UFCS"-style wrappers must be used to take advantage of the new features (see the run-pass tests).
cc #17307 (multidispatch)
cc #5527 (trait reform -- conditional dispatch)
Because we no longer preserve crate concatenability, this deviates slightly from what was specified in the RFC. The motivation for this change is described in [this blog post](http://smallcultfollowing.com/babysteps/blog/2014/09/30/multi-and-conditional-dispatch-in-traits/). I will post an amendment to the RFC in due course but do not anticipate great controversy on this point -- particularly as the RFCs more important features (e.g., conditional dispatch) just don't work without the change.
This change is an implementation of [RFC 69][rfc] which adds a third kind of
global to the language, `const`. This global is most similar to what the old
`static` was, and if you're unsure about what to use then you should use a
`const`.
The semantics of these three kinds of globals are:
* A `const` does not represent a memory location, but only a value. Constants
are translated as rvalues, which means that their values are directly inlined
at usage location (similar to a #define in C/C++). Constant values are, well,
constant, and can not be modified. Any "modification" is actually a
modification to a local value on the stack rather than the actual constant
itself.
Almost all values are allowed inside constants, whether they have interior
mutability or not. There are a few minor restrictions listed in the RFC, but
they should in general not come up too often.
* A `static` now always represents a memory location (unconditionally). Any
references to the same `static` are actually a reference to the same memory
location. Only values whose types ascribe to `Sync` are allowed in a `static`.
This restriction is in place because many threads may access a `static`
concurrently. Lifting this restriction (and allowing unsafe access) is a
future extension not implemented at this time.
* A `static mut` continues to always represent a memory location. All references
to a `static mut` continue to be `unsafe`.
This is a large breaking change, and many programs will need to be updated
accordingly. A summary of the breaking changes is:
* Statics may no longer be used in patterns. Statics now always represent a
memory location, which can sometimes be modified. To fix code, repurpose the
matched-on-`static` to a `const`.
static FOO: uint = 4;
match n {
FOO => { /* ... */ }
_ => { /* ... */ }
}
change this code to:
const FOO: uint = 4;
match n {
FOO => { /* ... */ }
_ => { /* ... */ }
}
* Statics may no longer refer to other statics by value. Due to statics being
able to change at runtime, allowing them to reference one another could
possibly lead to confusing semantics. If you are in this situation, use a
constant initializer instead. Note, however, that statics may reference other
statics by address, however.
* Statics may no longer be used in constant expressions, such as array lengths.
This is due to the same restrictions as listed above. Use a `const` instead.
[breaking-change]
Closes#17718
[rfc]: https://github.com/rust-lang/rfcs/pull/246
parameter list.
This breaks code like:
fn f(a: int, a: int) { ... }
fn g<T,T>(a: T) { ... }
Change this code to not use the same name for a parameter. For example:
fn f(a: int, b: int) { ... }
fn g<T,U>(a: T) { ... }
Code like this is *not* affected, since `_` is not an identifier:
fn f(_: int, _: int) { ... } // OK
Closes#17568.
r? @alexcrichton
[breaking-change]
This change is an implementation of [RFC 69][rfc] which adds a third kind of
global to the language, `const`. This global is most similar to what the old
`static` was, and if you're unsure about what to use then you should use a
`const`.
The semantics of these three kinds of globals are:
* A `const` does not represent a memory location, but only a value. Constants
are translated as rvalues, which means that their values are directly inlined
at usage location (similar to a #define in C/C++). Constant values are, well,
constant, and can not be modified. Any "modification" is actually a
modification to a local value on the stack rather than the actual constant
itself.
Almost all values are allowed inside constants, whether they have interior
mutability or not. There are a few minor restrictions listed in the RFC, but
they should in general not come up too often.
* A `static` now always represents a memory location (unconditionally). Any
references to the same `static` are actually a reference to the same memory
location. Only values whose types ascribe to `Sync` are allowed in a `static`.
This restriction is in place because many threads may access a `static`
concurrently. Lifting this restriction (and allowing unsafe access) is a
future extension not implemented at this time.
* A `static mut` continues to always represent a memory location. All references
to a `static mut` continue to be `unsafe`.
This is a large breaking change, and many programs will need to be updated
accordingly. A summary of the breaking changes is:
* Statics may no longer be used in patterns. Statics now always represent a
memory location, which can sometimes be modified. To fix code, repurpose the
matched-on-`static` to a `const`.
static FOO: uint = 4;
match n {
FOO => { /* ... */ }
_ => { /* ... */ }
}
change this code to:
const FOO: uint = 4;
match n {
FOO => { /* ... */ }
_ => { /* ... */ }
}
* Statics may no longer refer to other statics by value. Due to statics being
able to change at runtime, allowing them to reference one another could
possibly lead to confusing semantics. If you are in this situation, use a
constant initializer instead. Note, however, that statics may reference other
statics by address, however.
* Statics may no longer be used in constant expressions, such as array lengths.
This is due to the same restrictions as listed above. Use a `const` instead.
[breaking-change]
[rfc]: https://github.com/rust-lang/rfcs/pull/246
While booleans are represented as i1 in SSA values, LLVM expects them
to be stored/loaded as i8 values. Using i1 as we do now works, but
kills some optimizations, so we should switch to i8, just like we do
everywhere else.
Fixes#16959.
While booleans are represented as i1 in SSA values, LLVM expects them
to be stored/loaded as i8 values. Using i1 as we do now works, but
kills some optimizations, so we should switch to i8, just like we do
everywhere else.
Fixes#16959.
This fixes a soundness problem where `Fn` unboxed closures can mutate free variables in the environment.
The following presently builds:
```rust
#![feature(unboxed_closures, overloaded_calls)]
fn main() {
let mut x = 0u;
let _f = |&:| x = 42;
}
```
However, this is equivalent to writing the following, which borrowck rightly rejects:
```rust
struct F<'a> {
x: &'a mut uint
}
impl<'a> Fn<(),()> for F<'a> {
#[rust_call_abi_hack]
fn call(&self, _: ()) {
*self.x = 42; // error: cannot assign to data in a `&` reference
}
}
fn main() {
let mut x = 0u;
let _f = F { x: &mut x };
}
```
This problem is unique to unboxed closures; boxed closures cannot be invoked through an immutable reference and are not subject to it.
This change marks upvars of `Fn` unboxed closures as freely aliasable in mem_categorization, which causes borrowck to reject attempts to mutate or mutably borrow them.
@zwarich pointed out that even with this change, there are remaining soundness issues related to regionck (issue #17403). This region issue affects boxed closures as well.
Closes issue #17780
parameter list.
This breaks code like:
fn f(a: int, a: int) { ... }
fn g<T,T>(a: T) { ... }
Change this code to not use the same name for a parameter. For example:
fn f(a: int, b: int) { ... }
fn g<T,U>(a: T) { ... }
Code like this is *not* affected, since `_` is not an identifier:
fn f(_: int, _: int) { ... } // OK
Closes#17568.
[breaking-change]
Apart from making the build system determine the LLDB version, this PR also fixes an issue with enums in LLDB pretty printers. In order for GDB's pretty printers to know for sure if a field of some value is an enum discriminant, I had rustc mark discriminant fields with the `artificial` DWARF tag. This worked out nicely for GDB but it turns out that one can't access artificial fields from LLDB. So I changed the debuginfo representation so that enum discriminants are marked by the special field name `RUST$ENUM$DISR` instead, which works in both cases.
The PR does not activate the LLDB test suite yet.
LLDB doesn't allow for reading 'artifical' fields (fields that are generated by the compiler). So do not mark, slice fields, enum discriminants, and GcBox value fields as artificial.
This causes borrowck to correctly reject mutation or mutable borrows
of upvars in `Fn` unboxed closures since the closure environment is
aliasable.
This also tracks the responsible closure in the aliasability
information returned and uses it to give a helpful diagnostic.
Closes issue #17780
