Skip to content
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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

cramertj
Copy link
Member

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 #132713
cc #133267

r? @compiler-errors

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels Nov 23, 2024
@rustbot
Copy link
Collaborator

rustbot commented Nov 23, 2024

HIR ty lowering was modified

cc @fmease


trait Child: Super {}

fn take_dyn(_: &dyn Child) {}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cc @compiler-errors

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!

@rustbot
Copy link
Collaborator

rustbot commented Nov 23, 2024

Some changes occurred in src/tools/cargo

cc @ehuss

@fmease
Copy link
Member

fmease commented Nov 23, 2024

You've touched several git submodules. See https://rustc-dev-guide.rust-lang.org/git.html#i-changed-a-submodule-by-accident

@rust-log-analyzer

This comment has been minimized.

@fmease fmease added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 25, 2024
@fmease fmease assigned fmease and unassigned compiler-errors Nov 25, 2024
@bors

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",
Copy link
Contributor

@traviscross traviscross Nov 26, 2024

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:

rust-lang/lang-team#286

My grammatical intuition is that in most uses it should be unhyphenated, as with "object safety", "trait object", or "forward compatible".

Copy link
Member Author

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated!

@cramertj
Copy link
Member Author

You've touched several git submodules. See https://rustc-dev-guide.rust-lang.org/git.html#i-changed-a-submodule-by-accident

@fmease Thanks for the link! I should make sure my search-and-replace tooling doesn't recurse into submodules by accident :)

@rust-log-analyzer

This comment was marked as resolved.

@bors

This comment was marked as resolved.

@cramertj cramertj added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 27, 2024
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants