Bad diagnostic about memberwise init not being public

[AnthonyLatsis]

Description

No response

Reproduction

public struct Number: RawRepresentable {
  public let rawValue: Int
}

398 | public struct Number: RawRepresentable {
    |               `- error: initializer 'init(rawValue:)' must be declared public because it matches a requirement in public protocol 'RawRepresentable' [witness_not_accessible_proto]
399 |   public let rawValue: Int
400 | }

Expected behavior

This diagnostic is not great:

1. What initializer? (The implicit memberwise initializer).
2. How do I or can I at all declare it public? (An implicit memberwise initializer cannot be public).
3. What should I do to make this work? (Declare an explicit initializer + fix-it).

Environment

Swift version 6.2-dev (LLVM 1a588e5b044c46f, Swift 55189ba)

Additional information

No response

[devnumber7]

Hello!, I would like to be assigned on this issue.

[vlkhvnn]

Hello, can I also be assigned on this issue?

[devnumber7]

Hello,
I am a little lost here and I could not find anything in the swift/include/swift/AST/DiagnosticsSema.def

This is my first time poking around the swift source and I wanted to make sure if I am looking at the right places. Not sure if I missed it but in the DiagnosticsSema.def I could not find anything related to "must be declared public because it matches a requirement in public protocol"

[jamieQ]

it can be a little tricky at first to reverse lookup the source from the diagnostic text because many of them are string 'templates' and the nouns & adjectives get substituted in. in this case the relevant diagnostic message is likely this one. you can then use the diagnostic ID (type_witness_not_accessible_proto in this case) to better determine where the relevant callsites for addressing this issue are.

[devnumber7]

So from what I have learned, this issue would require a simple boolean flag to append the diagnostic message. Now from my understanding the rawRepresentable protocol requires that the initializer must be declared public and you cannot have that with the implicit memberwise initialization. So a "fix-it" option would be to just add the code snippet for explicit public initialization. My only question is, which files would I have to change to have the "fix-it" option for the Xcode.

Also, is there any testing guidelines that I need to follow to on my side for the context based implementation of the diagnosis

[AnthonyLatsis]

The first two things I think you should check off the list when dealing with issues that require code changes are:

• To build a compiler.
• To write a test case and reproduce it using that compiler.

Then you know the issue is still relevant and are equipped to start debugging. In this case, you can start off by using the -debug-diagnostic-names flag to show the IDs of emitted diagnostics, and locate both their definition and emission sites in the codebase. For understanding diagnostic templates and how to write and test diagnostics, refer to Diagnostics.md.

[rdingman]

@devnumber7 It looks like its been a couple months, are you still working on this issue? If not, I'd like to take it over.

[devnumber7]

@rdingman yeah I haven't given up on this one. I ran into some compiler issues before so I had redo some stuff again, and I was stuck with C projects. But yeah I plan on submitting this week.

[rdingman]

@devnumber7 Thanks, sounds good. Let me know if you'd like to collaborate.

[devnumber7]

@rdingman Hey! I would like to collaborate with you, if you're still open

[rdingman]

@devnumber7 That works for me. Let me know how to get into contact with you and we can work on it.

[devnumber7]

@rdingman I am available through discord if that's what you use

[SwiftyJoeyy]

Hey @devnumber7 are you still working on this issue? If not, I'd like to take it over.

[devnumber7]

Hey @devnumber7 are you still working on this issue? If not, I'd like to take it over.

I am still working on the issue and very close to getting the fix.

[adozenlines]

@devnumber7 It’s been months, there’s no harm in walking away from the issue and let someone else complete it.

[AnthonyLatsis]

Let’s give @devnumber7 2 weeks to open a PR and rotate the assignee otherwise. A work-in-progress change is fine. The point is to have something material that we can review, help with, and iterate on relatively actively.

[devnumber7]

@AnthonyLatsis Hey! Sorry about the late response. I have been working on it and made progress with diagnostic emission. Currently I was stuck in an issue which said bin/swift-ide-test needs libml2.tbd
Right now, the only thing that's left is the fix-it loc in the test suite. I am trying to find the emission of the fixit using the -emit-fixits- flag in the test file. For that I would need to do a clean build. Again, I apologize for the lack of response.

[AnthonyLatsis]

an issue which said bin/swift-ide-test needs libml2.tbd

You can ignore that.

I am trying to find the emission of the fixit using the -emit-fixits- flag in the test file

If you are already verifying the error in a test file using expected-error and the test passes, add a random fix-it verification like {{1-1=}} to it and rerun the test. The test runner should then tell you what the actual fix-it is. See Diagnostic verifier. You don’t need to rebuild anything in response to modifying a test.

[rdingman]

@AnthonyLatsis I'd like to take over this issue. I've been collaborating with and guiding @devnumber7 through this behind the scenes, but it is taking longer than he expected. For the sake of getting this done, he and I have agreed it would be best if I take over at this point. He should be following up and confirming this in his own comment soon.

I should have a PR to start critiquing sometime this weekend.

[devnumber7]

Yes, I'd like @rdingman to take over.