This removes the stacking of type parameters that occurs when invoking
trait methods, and fixes all places in the standard library that were
relying on it. It is somewhat awkward in places; I think we'll probably
want something like the `Foo::<for T>::new()` syntax.
Fixes for #8625 to prevent assigning to `&mut` in borrowed or aliasable locations. The old code was insufficient in that it failed to catch bizarre cases like `& &mut &mut`.
r? @pnkfelix
This is a pull request for #2275
I've created a small python script to generate test files for a list of keywords (as break do else enum extern false fn for if impl let loop match mod mut priv pub ref return self static struct super true trait type unsafe use while), but I'm not really sure where to put it. I've added the created files as well.
I did not use
fn main() {
let $KW = "foo"; //~ error
println($KW); //~ error
}
as template, because for return, self, ref, loop, mut and break this does not raise an error in the ```println``` line, only in the ```let``` line.
For #7083.
The metadata issue with the old version is now fixed. Ready for review.
This is also not the full solution to #7083, because this is not supported yet:
```
trait Foo : Send { }
impl <T: Send> Foo for T { }
fn foo<T: Foo>(val: T, chan: std::comm::Chan<T>) {
chan.send(val);
}
```
cc @nikomatsakis
When using a `do` block to call an internal iterator, if you forgot to
return a value from the body, it would tell you
error: Do-block body must return bool, but returns () here. Perhaps
you meant to write a `for`-loop?
This advice no longer applies as `for` loops are now for external
iterators. Delete this message outright and let it use the default error
message
error: mismatched types: expected `bool` but found `()`
r? @thestinger
When parsing a trait function, the function must end with either `;` or
`{` (signifying a default implementation). The error message incorrectly
stated that it must be `;` or `}`.
Fixes#6610.
When using a `do` block to call an internal iterator, if you forgot to
return a value from the body, it would tell you
error: Do-block body must return bool, but returns () here. Perhaps
you meant to write a `for`-loop?
This advice no longer applies as `for` loops are now for external
iterators. Delete this message outright and let it use the default error
message
error: mismatched types: expected `bool` but found `()`
This allows the internal implementation details of the TLS keys to be
changed without requiring the update of all the users. (Or, applying
changes that *have* to be applied for the keys to work correctly, e.g.
forcing LLVM to not merge these constants.)
This allows the internal implementation details of the TLS keys to be
changed without requiring the update of all the users. (Or, applying
changes that have to be applied for the keys to work correctly, e.g.
forcing LLVM to not merge these constants.)
When parsing a trait function, the function must end with either `;` or
`{` (signifying a default implementation). The error message incorrectly
stated that it must be `;` or `}`.
Fixes#6610.
Fix#3192. r? anyone
There are 4 different new tests, to check some different scenarios for
what the parse context is at the time of recovery, becasue our
compile-fail infrastructure does not appear to handle verifying
error-recovery situations.
Differentiate between unit-like struct definition item and unit-like
struct construction in the error message.
----
More generally, outlines a more generic strategy for parse error
recovery: By committing to an expression/statement at set points in
the parser, we can then do some look-ahead to catch common mistakes
and skip over them.
One detail about this strategy is that you want to avoid emitting the
"helpful" message unless the input is reasonably close to the case of
interest. (E.g. do not warn about a potential unit struct for an
input of the form `let hmm = do foo { } { };`)
To accomplish this, I added (partial) last_token tracking; used for
`commit_stmt` support.
The check_for_erroneous_unit_struct_expecting fn returns bool to
signal whether it "made progress"; currently unused; this is meant for
use to compose several such recovery checks together in a loop.
