It's unhelpful since raw pointers to trait objects are also FFI-unsafe and casting to a thin raw pointer loses the vtable. There are working solutions that _involve_ raw pointers but they're too complex to explain in one line and have serious trade offs.
The suggestion is unconditional, so following it could lead to further errors. This is already the case for the repr(C) suggestion, which makes this acceptable, though not *good*. Checking up-front whether the suggestion can help would be great but applies more broadly (and would require some refactoring to avoid duplicating the checks).
- Always name the non-FFI-safe
- Explain *why* the type is not FFI-safe
- Stop vaguely gesturing at structs/enums/unions if the non-FFI-safe types occured in a field.
The last part is arguably a regression, but it's minor now that the non-FFI-safe type is actually named. Removing it avoids some code duplication.
Continue parsing function after finding `...` arg
When encountering a variadic argument in a function definition that
doesn't accept it, if immediately after there's a closing paren,
continue parsing as normal. Otherwise keep current behavior of emitting
error and stopping.
Fix#31481.
When encountering a variadic argument in a function definition that
doesn't accept it, if immediately after there's a closing paren,
continue parsing as normal. Otherwise keep current behavior of emitting
error and stopping.
rustc_mir: insert a dummy access to places being matched on, when building MIR.
Fixes#47412 by adding a `_dummy = Discriminant(place)` before each `match place {...}`.
r? @nikomatsakis
Fix ICE for mismatched args on target without span
Commit 7ed00caacc improved our error reporting by including the target function in our error messages when there is an argument count mismatch. A simple example from the UI tests is:
```
error[E0593]: function is expected to take a single 2-tuple as argument, but it takes 0 arguments
--> $DIR/closure-arg-count.rs:32:53
|
32 | let _it = vec![1, 2, 3].into_iter().enumerate().map(foo);
| ^^^ expected function that takes a single 2-tuple as argument
...
44 | fn foo() {}
| -------- takes 0 arguments
```
However, this assumed the target span was always available. This does not hold true if the target function is in `std` or another crate. A simple example from #48046 is assigning `str::split` to a function type with a different number of arguments.
Fix by omitting all of the labels and suggestions related to the target span when it's not found.
Fixes#48046
r? @estebank
Warn about more ignored bounds in type aliases
It seems that all bounds in type aliases are entirely ignored, not just type bounds. This extends the warning appropriately.
I assume this should be made a hard error with the next epoch? I can't see any reason to accept these programs. (And suddenly enforcing these type bounds would be a breaking change.)
Add filtering options to `rustc_on_unimplemented`
- Add filtering options to `rustc_on_unimplemented` for local traits, filtering on `Self` and type arguments.
- Add a way to provide custom notes.
- Tweak binops text.
- Add filter to detect wether `Self` is local or belongs to another crate.
- Add filter to `Iterator` diagnostic for `&str`.
Partly addresses #44755 with a different syntax, as a first approach. Fixes#46216, fixes#37522, CC #34297, #46806.
[NLL] Improve DefiningTy::Const
Fixes#47590 by fixing the way DefiningTy represents constants. Previously, constants were represented using just the type of the variable. However, this will fail to capture early-bound regions as NLL inference vars, resulting in an ICE when we try to compute region VIDs a little bit later in the universal
region resolution process. (ref #47590)
Commit 7ed00caacc improved our error reporting by including the target
function in our error messages when there is an argument count mismatch.
A simple example from the UI tests is:
```
error[E0593]: function is expected to take a single 2-tuple as argument, but it takes 0 arguments
--> $DIR/closure-arg-count.rs:32:53
|
32 | let _it = vec![1, 2, 3].into_iter().enumerate().map(foo);
| ^^^ expected function that takes a single 2-tuple as argument
...
44 | fn foo() {}
| -------- takes 0 arguments
```
However, this assumed the target span was always available. This does
not hold true if the target function is in `std` or another crate. A
simple example from #48046 is assigning `str::split` to a function type
with a different number of arguments.
Fix by removing all of the labels and suggestions related to the target
span when it's not found.
Fixes#48046
Fixes#47590 by fixing the way DefiningTy represents constants. Previously,
constants were represented using just the type of the variable. However, this
will fail to capture early-bound regions as NLL inference vars, resulting in an
ICE when we try to compute region VIDs a little bit later in the universal
region resolution process.
MIR-borrowck: augmented assignment causes duplicate errors
Fixes#45697. This PR resolves the error duplication. I attempted to replace the existing sets since there were quite a few but only managed to replace two of them.
r? @nikomatsakis
Previously, when the type of a method receiver could not be determined,
the error message would, potentially confusingly, highlight the span of
the entire method call.
Resolves#36598, resolves#42234.
Stabilize feature(match_beginning_vert)
With this feature stabilized, match expressions can optionally have a `|` at the beginning of each arm.
Reference PR: rust-lang-nursery/reference#231
Closes#44101
