swiftlang/swift

[SR-15051] Swift should suggest updating existing @available attribute when you use an insufficiently available declaration

Open

#57,378 opened on Aug 10, 2021

View on GitHub
 (4 comments) (0 reactions) (0 assignees)Swift (10,719 forks)batch import
availabilitycompilerdiagnostics qualityfix-itsgood first issueimprovementtype checker

Repository metrics

Stars
 (69,989 stars)
PR merge metrics
 (Avg merge 8d 17h) (510 merged PRs in 30d)

Description

Previous ID SR-15051
Radar rdar://problem/81802673
Original Reporter @beccadax
Type Improvement
Votes 0
Component/s Compiler
Labels Improvement, DiagnosticsQoI, StarterBug
Assignee mininny (JIRA)
Priority Medium

md5: 9db411fbe711e822a955f04325204e6d

Issue Description:

Currently, fixAvailabilityForDecl() in TypeCheckAvailability.cpp exits early if there is already an @available attribute on the declaration, with a comment noting work that should be done in the future:

/// Emit a diagnostic note and Fix-It to add an @available attribute
/// on the given declaration for the given version range.
static void fixAvailabilityForDecl(SourceRange ReferenceRange, const Decl *D,
                                   const VersionRange &RequiredRange,
                                   ASTContext &Context) {
  // ...irrelevant code omitted...

  if (getActiveAvailableAttribute(D, Context)) {
    // For QoI, in future should emit a fixit to update the existing attribute.
    return;
  }

Indeed, we should make this change. For instance, if you give the compiler this code:

@available(macOS 42, *) func foo() {}

@available(macOS 12, *) func bar() {
    foo()
}

Swift should emit a note with a fix-it replacing "macOS 12" with "macOS 42".

Your implementation, should you choose to commit it, should test not only this easy case with one simple @available attribute, but also cases with multiple OSes and long-form @available attributes. You will certainly need to update some existing tests; those might adequately cover this, but I'm not sure.

Contributor guide