Fix the static_functions_not_mutating error messsage

[felixinkinto]

Fix #77835

[xedin]

Thank you for the contribution! I left a comment inline about the text and as a separate note: please modify existing tests (because the text is now different) or make sure that we have tests for both nonmutating and mutating attributes that exercise the new diagnostics before we can run CI and land this.

[xedin]

Instead of clamping mutating and nonmutating together it would be better to print one or the other depending on what the attribute was, a boolean flag could be used to distinguish between the two (i.e. no_overloads_match_exactly_in_call does a similar thing reference vs. call).

Instead of "operate" we can use "cannot access" and the "because" part can be turned into a note.

[felixinkinto]

@xedin
Thanks for the advice!
I fixed based on your suggestion.

[xedin]

I left one more small note inline. We also have a few tests that use the diagnostic and they'd need to be adjusted before we can land this:

test/Sema/immutability.swift:134
test/decl/subscript/static.swift:23
test/decl/subscript/static.swift:24
test/decl/overload.swift:413

[AnthonyLatsis]

@felixinkinto Next time, please ask us to assign you to an issue before you start working on one. A good first issue is a queue, not a race. We want to avoid instances of multiple people independently working on them.

[felixinkinto]

@xedin sorry for the delay for long. I addressed the feedback. May I ask some questions to do behaviour checks?

1. Does the order matter? I realized note usually follows the error in other areas.

➜  test xcrun -sdk macosx build/Ninja-RelWithDebInfoAssert/swift-macosx-arm64/bin/swiftc test.swift
test.swift:4:3: error: 'nonmutating' modifier cannot be used on static functions
2 |
3 | struct S {
4 |   nonmutating static func foo() {}
  |   |                       `- note: static members cannot access instance properties or self
  |   `- error: 'nonmutating' modifier cannot be used on static functions
5 |
6 |

2. After testing the locally built compiler in Xcode according to this manual, it seems that the existing swiftc is overriding the errors in the IDE.
   this build log shows my local compiler.

this is still the default swiftc

[felixinkinto]

@felixinkinto Next time, please ask us to assign you to an issue before you start working on one. A good first issue is a queue, not a race. We want to avoid instances of multiple people independently working on them.

@AnthonyLatsis
sorry I’ll make sure to ask for an assignment before starting work on an issue next time.

[felixinkinto]

@swift-ci please test Windows platform

[AnthonyLatsis]

If you incorporate the declaration like so, the message will be also be tailored for an accessor:

Suggested change

	"%0 modifier cannot be used on static functions",
	(SelfAccessKind))
	"%0 modifier cannot be used on %kindonly1",
	(SelfAccessKind, const FuncDecl *))

We loose the plural, but I think that’s fine because the object remains indefinite.

[AnthonyLatsis]

I’m not a fan of this interpretation because it’s misleading. We have this very problem with another diagnostic: #62909. You can access both self or instance members inside a static method depending on what you mean by it.

Maybe we could borrow a more clear phrasing from the book. For example:

static members are defined on the type itself rather than on instances of the type
static members belong to the type itself rather than to instances of the type
static members are members of the type itself rather than instances of the type

[AnthonyLatsis]

Does the order matter? I realized note usually follows the error in other areas.

Emission order does matter. Notes are always attached to a primary diagnostic such as an error or warning. The grouped diagnostic formatter probably chose to display the error below the note there because it wants a clear path from each message to its location.