When projecting associate types for a trait's default methods, the
trait itself was added to the predicate candidate list twice: one from
parameter environment, the other from trait definition. Then the
duplicates were deemed as code ambiguity and the compiler rejected the
code. Simply checking and dropping the duplicates solves the issue.
Closes#22036
The live code analysis only visited the function's body when visiting a
method, and not the FnDecl and the generics, resulting in code to be
incorrectly marked as unused when it only appeared in the generics, the
arguments, or the return type, whereas the same code in non-method
functions was correctly detected as used. Fixes#20343.
Originally I just added a call to `walk_generics` and `walk_fndecl` alongside `walk_block` but then I noticed the `walk_method_helper` function did pretty much the same thing. The only difference is that it also calls `visit_mac`, but since this is not going to happen at this stage, I think it's ok. However let me know if this was not the right thing to do.
This is a resurrection and heavy revision/expansion of a PR that pcwalton did to resolve#8861.
The most relevant, user-visible semantic change is this: #[unsafe_destructor] is gone. Instead, if a type expression for some value has a destructor, then any lifetimes referenced within that type expression must strictly outlive the scope of the value.
See discussion on https://github.com/rust-lang/rfcs/pull/769
When projecting associate types for a trait's default methods, the
trait itself was added to the predicate candidate list twice: one from
parameter environment, the other from trait definition. Then the
duplicates were deemed as code ambiguity and the compiler rejected the
code. Simply checking and dropping the duplicates solves the issue.
Closes#22036
includes regression tests discovered during bootstrapping and tests of
cyclic structure that currently pass and are expected to continue
passing under the dropck rule.
(Note that all the uses of `unsafe_destructor` are just placating the
simple analysis used for that feature, which will eventually go away
once we have put the dropck through its paces.)
As the function comment already says, the types generated in the
foreign_signture function don't necessarily match the types used for a
corresponding rust function. Therefore we can't just use these types to
guide the translation of the wrapper function that bridges between the
external ABI and the rust ABI. Instead, we can query LLVM about the
types used in the rust function and use those to generate an appropriate
wrapper.
Fixes#21454
As the function comment already says, the types generated in the
foreign_signture function don't necessarily match the types used for a
corresponding rust function. Therefore we can't just use these types to
guide the translation of the wrapper function that bridges between the
external ABI and the rust ABI. Instead, we can query LLVM about the
types used in the rust function and use those to generate an appropriate
wrapper.
Fixes#21454
The live code analysis only visited the function's body when visiting a
method, and not the FnDecl and the generics, resulting in code to be
incorrectly marked as unused when it only appeared in the generics, the
arguments, or the return type, whereas the same code in non-method
functions was correctly detected as used. Fixes#20343.
Given `<expr> as Box<Trait>`, infer that `Box<_>` is expected type for `<expr>`.
This is useful for addressing fallout from newly proposed box protocol; see #22006 for examples of such fallout, much of which will be unnecessary with this fix.
Simplify cache selection by just using the local cache whenever there
are any where-clauses at all. This seems to be the simplest possible
rule and will (hopefully!) put an end to these annoying "cache leak"
bugs. Fixes#22019.
r? @aturon
Fixes#21833.
[breaking-change]
r? @alexcrichton
The tests in #21912 will also need `#[feature(no_std)]`. If you're okay with both PRs, I can merge and test them.
make `for PAT in ITER_EXPR { ... }` a terminating-scope for ITER_EXPR.
In effect, temporary anonymous values created during the evaluation of ITER_EXPR no longer not live for the entirety of the block surrounding the for-loop; instead they only live for the extent of the for-loop itself, and no longer.
----
There is one case I know of that this breaks, demonstrated to me by @nikomatsakis (but it is also a corner-case that is useless in practice). Here is that case:
```
fn main() {
let mut foo: Vec<&i8> = Vec::new();
for i in &[1, 2, 3] { foo.push(i) }
}
```
Note that if you add any code following the for-loop above, or even a semicolon to the end of it, then the code will stop compiling (i.e., it gathers a vector of references but the gathered vector cannot actually be used.)
(The above code, despite being useless, did occur in one run-pass test by accident; that test is updated here to accommodate the new striction.)
----
So, technically this is a:
[breaking-change]
closes#21630
Overloaded indexing (`&[mut] foo[bar]`) only works when `<Self as Index>::Output` is the same as `<Self as IndexMut>::Output` (see issue above). To restrict implementations of `IndexMut` that doesn't work, this PR makes `IndexMut` a supertrait over `Index`, i.e. `trait IndexMut<I>: Index<I>`, just like in the `trait DerefMut: Deref` case.
This breaks all downstream implementations of `IndexMut`, in most cases this simply means removing the `type Output = ..` bit, which is now redundant, from `IndexMut` implementations:
``` diff
impl Index<Foo> for Bar {
type Output = Baz;
..
}
impl IndexMut<Foo> for Bar {
- type Output = Baz;
..
}
```
[breaking-change]
---
r? @nikomatsakis
are any where-clauses at all. This seems to be the simplest possible
rule and will (hopefully!) put an end to these annoying "cache leak"
bugs. Fixes#22019.
Ported regions-mock-tcx to use TypedArena rather than Arena since it holds cyclic structure (which the Arena API updated for the Drop-Check-Rule cannot handle).
Plus, the use of `arena::Arena` here really is not justified; the allocated values are all the same type anyway.
Implement step 1 of rust-lang/rfcs#702
Allows the expression `..` (without either endpoint) in general, can be
used in slicing syntax `&expr[..]` where we previously wrote `&expr[]`.
The old syntax &expr[] is not yet removed or warned for.
In effect, temporary anonymous values created during the evaluation of
ITER_EXPR no longer not live for the entirety of the block surrounding
the for-loop; instead they only live for the extent of the for-loop
itself, and no longer.
----
There is one case I know of that this breaks, demonstrated to me by
niko (but it is also a corner-case that is useless in practice). Here
is that case:
```
fn main() {
let mut foo: Vec<&i8> = Vec::new();
for i in &[1, 2, 3] { foo.push(i) }
}
```
Note that if you add any code following the for-loop above, or even a
semicolon to the end of it, then the code will stop compiling (i.e.,
it gathers a vector of references but the gathered vector cannot
actually be used.)
(The above code, despite being useless, did occur in one run-pass test
by accident; that test is updated here to accommodate the new
striction.)
----
So, technically this is a:
[breaking-change]
Allows the expression `..` (without either endpoint) in general, can be
used in slicing syntax `&expr[..]` where we previously wrote `&expr[]`.
The old syntax &expr[] is not yet removed or warned for.
This *almost* completes the job for #16440. The idea is that even if we do not know whether some closure type `C` implements `Fn` or `FnMut` (etc), we still know its argument and return types. So if we see an obligation `C : Fn(_0)`, we can unify `_0` with those argument types while still considering the obligation ambiguous and unsatisfied. This helps to make a lot of progress with type inference even before closure kind inference is done.
As part of this PR, the explicit `:` syntax is removed from the AST and completely ignored. We still infer the closure kind based on the expected type if that is available. There are several reasons for this. First, deciding the closure kind earlier is always better, as it allows us to make more progress. Second, this retains a (admittedly obscure) way for users to manually specify the closure kind, which is useful for writing tests if nothing else. Finally, there are still some cases where inference can fail, so it may be useful to have this manual override. (The expectation is that we will eventually revisit an explicit syntax for specifying the closure kind, but it will not be `:` and may be some sort of generalization of the `||` syntax to handle other traits as well.)
This commit does not *quite* fix#16640 because a snapshot is still needed to enable the obsolete syntax errors for explicit `&mut:` and friends.
r? @eddyb as he reviewed the prior patch in this direction
Implements [RFC 474](https://github.com/rust-lang/rfcs/pull/474); see
that RFC for details/motivation for this change.
This initial commit does not include additional normalization or
platform-specific path extensions. These will be done in follow up
commits or PRs.
possible. There is some amount of duplication as a result (similar to
select) -- I am not happy about this but not sure how to fix it
without deeper rewrites.
