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

Improve DiagnosticEngine's handling of ValueDecl arguments #67075

Merged
merged 14 commits into from
Jul 21, 2023

Conversation

beccadax
Copy link
Contributor

@beccadax beccadax commented Jul 1, 2023

This PR improves the DiagnosticEngine's handling of Decl * diagnostic arguments:

  • Any Decl, not just ValueDecl, can now be used. This is mainly meant for decls like OperatorDecl which have a name but aren’t ValueDecls, but it works for all Decls.
  • If the decl is an accessor, the diagnostic engine will automatically describe it using a phrase like getter for 'someProperty’; if it’s an extension, the diagnostic engine will describe it using a phrase like extension of ’SomeType’.
  • If the %kind modifier is used, the diagnostic engine will prefix the name with the decl's descriptive kind; this lets you eliminate pairs of arguments.
  • If the %base modifier is used, only the base name will be printed.
  • If the %kindbase modifier is used, the effects of the previous two modifiers are combined.
  • If the %kindonly modifier is used, only the kind will be inserted. This is useful when the kind and name aren’t paired together in the usual way.

I believe these changes will simplify a lot of diagnostic code that currently special-cases accessors, passes DescriptiveDeclKind/ValueDecl argument pairs that need to be kept matched up, and looks up declaration names by hand. Adopting Decl more broadly may also open up opportunities for future improvements to diagnostics, like turning decl names into links in clients that would support it.

I've tried to keep this PR close to NFC, but I've kept a few obvious wins where this change handled accessors better or made kinds more specific.

I’ve also removed some diagnostics that are unused and replaced some warn_ variants of diagnostics with more modern features like limitBehavior or warnUntilSwiftVersion.

docs/Diagnostics.md Outdated Show resolved Hide resolved
@beccadax
Copy link
Contributor Author

@swift-ci please test

@beccadax beccadax requested a review from DougGregor July 14, 2023 22:47
Copy link
Member

@kavon kavon left a comment

Choose a reason for hiding this comment

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

this is a really nice improvement. will definitely let us clean-up a lot diagnostic-emitting code.

beccadax added 8 commits July 19, 2023 13:06
Implements several enhancements to DiagnosticEngine’s handling of Decl arguments:

• All Decl classes, not just ValueDecls, are now valid to use as arguments.
• There is built-in logic to handle accessors by printing a phrase like `getter for 'foo'`, so this no longer has to be special-cased for each diagnostic.
• `%kind` can be used to insert the descriptive kind before a name; `%kindonly` inserts only the descriptive kind. This can eliminate kind/name argument pairs.
• `%base` can insert only the base name, leaving out any argument labels; `%kindbase` combines `%kind` and `%base`.

This PR is marked NFC because there are no intentional uses of these changes yet.
These particular changes slightly alter some diagnostics.
Causes minor changes in diagnostic text.
It was used in one place to handle accessors, which happily is no longer necessary.
Causes slight changes to notes on certain `init`s.
beccadax added 5 commits July 19, 2023 13:08
…warn

This changes the wording of some diagnostics in Swift 4.2 and Swift 4 modes.
…and also adopt new DiagnosticEngine features.
Allows the removal of a helper function.
Slightly alters wording of a diagnostic.
@beccadax beccadax force-pushed the kinder-diagnostics branch from 4178c61 to 4981654 Compare July 19, 2023 21:54
@beccadax
Copy link
Contributor Author

@swift-ci smoke test and merge

@beccadax beccadax force-pushed the kinder-diagnostics branch from 4981654 to fe67534 Compare July 20, 2023 22:35
@beccadax
Copy link
Contributor Author

@swift-ci smoke test and merge

Copy link
Contributor

@tshortli tshortli left a comment

Choose a reason for hiding this comment

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

This is a massive improvement! I've experienced the difficulty in handling accessors in diagnostics before and I'm really glad you addressed it holistically.

@@ -7,8 +7,8 @@ public protocol PublicProtoWithReqs {
}

@usableFromInline struct UFIAdopter<T> : PublicProtoWithReqs {}
// expected-warning@-1 {{type alias 'Assoc' should be declared '@usableFromInline' because it matches a requirement in protocol 'PublicProtoWithReqs'}} {{none}}
// expected-warning@-2 {{instance method 'foo()' should be declared '@usableFromInline' because it matches a requirement in protocol 'PublicProtoWithReqs'}} {{none}}
// expected-warning@-1 {{type alias 'Assoc' must be declared '@usableFromInline' because it matches a requirement in protocol 'PublicProtoWithReqs'; this is an error in Swift 5}} {{none}}
Copy link
Contributor

Choose a reason for hiding this comment

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

Looks probably intentional and fine to me but I do want to flag this just in case - are the wording changes here a drive by improvement coming from making other changes in the area?

Copy link
Contributor Author

@beccadax beccadax Jul 21, 2023

Choose a reason for hiding this comment

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

Yes. When I was updating this diagnostic, I noticed that it had a separate warn_ variant because it predated the introduction of warnUntilSwiftVersion(), so I merged them together to simplify things overall.

@swift-ci swift-ci merged commit 7741409 into swiftlang:main Jul 21, 2023
@bnbarham
Copy link
Contributor

Just used this, awesome improvement @beccadax 😍!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants