-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor dyn-compatibility error and suggestions #133372
base: master
Are you sure you want to change the base?
Conversation
HIR ty lowering was modified cc @fmease |
|
||
trait Child: Super {} | ||
|
||
fn take_dyn(_: &dyn Child) {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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!
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated!
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.
0c4161f
to
02d748e
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
02d748e
to
2f9e7ec
Compare
This CL makes a number of small changes to dyn compatibility errors:
dyn OtherTrait
Additionally, the dyn compatibility error creation code has been split out into functions.
cc #132713
cc #133267
r? @compiler-errors