Refactor dyn-compatibility error and suggestions #133372
Conversation
rustbot
added
S-waiting-on-review
|
HIR ty lowering was modified cc @fmease |
|
|
||
| trait Child: Super {} | ||
|
|
||
| fn take_dyn(_: &dyn Child) {} |
There was a problem hiding this comment.
This duplication and mis-attribution is the original source of the AsyncFn issue. I haven't yet resolved it as part of this PR, but this one started to get quite large again, so I figured I'd save it. I'd be happy to poke around more or try things out if you have ideas!
cramertj
force-pushed
the
rework-dyn-suggestions
branch
from
9dcb36e to
4ad5567
Compare
|
Some changes occurred in src/tools/cargo cc @ehuss |
|
You've touched several git submodules. See https://rustc-dev-guide.rust-lang.org/git.html#i-changed-a-submodule-by-accident |
This comment has been minimized.
This comment has been minimized.
fmease
added
S-waiting-on-author
This comment was marked as resolved.
This comment was marked as resolved.
| @@ -276,7 +271,7 @@ impl<'tcx> dyn HirTyLowerer<'tcx> + '_ { | |||
| self.dcx(), | |||
| i.bottom().1, | |||
| E0038, | |||
| "the {} `{}` cannot be made into an object", | |||
| "the {} `{}` is not dyn-compatible", | |||
There was a problem hiding this comment.
Obviously a nit, but do we want to hyphenate this use or not? @fmease, how does this fit with the system you've been using elsewhere?
We didn't hyphenate over in:
My grammatical intuition is that in most uses it should be unhyphenated, as with "object safety", "trait object", or "forward compatible".
There was a problem hiding this comment.
We discussed in #133267 (comment)
My read of the APA style is that hyphens are required when the adjective comes before the object (e.g. "dyn-compatible trait") but optional when the adjective comes after (e.g. "this trait is dyn compatible" / "this trait is dyn-compatible") except where required for resolving ambiguity.
IMO we can make any choice here. It seems like folks besides myself prefer the un-hyphenated version for "postfix" adjectives. Should we resolve to always use that form?
I'll update this PR.
cramertj
force-pushed
the
rework-dyn-suggestions
branch
from
4ad5567 to
0c4161f
Compare
@fmease Thanks for the link! I should make sure my search-and-replace tooling doesn't recurse into submodules by accident :) |
This comment was marked as resolved.
This comment was marked as resolved.
cramertj
force-pushed
the
rework-dyn-suggestions
branch
from
0c4161f to
02d748e
Compare
This comment was marked as resolved.
This comment was marked as resolved.
cramertj
added
S-waiting-on-review
cramertj
force-pushed
the
rework-dyn-suggestions
branch
from
02d748e to
2f9e7ec
Compare
This comment was marked as resolved.
This comment was marked as resolved.
This CL makes a number of small changes to dyn compatibility errors: - "object safety" has been renamed to "dyn-compatibility" throughout - "Convert to enum" suggestions are no longer generated when there exists a type-generic impl of the trait or an impl for `dyn OtherTrait` - Several error messages are reorganized for user readability Additionally, the dyn compatibility error creation code has been split out into functions. cc rust-lang#132713 cc rust-lang#133267
cramertj
force-pushed
the
rework-dyn-suggestions
branch
from
2f9e7ec to
cf3816f
Compare
This CL makes a number of small changes to dyn compatibility errors:
dyn OtherTraitAdditionally, the dyn compatibility error creation code has been split out into functions.
cc #132713
cc #133267
r? @compiler-errors