[CursorInfo] Always add module name to response #39851
Conversation
|
@swift-ci please test |
|
Build failed |
|
Build failed |
|
What's the problem being solved here? Non-Apple folk can't read rdars. The current design point of omitting the module name for declarations from the module being queried (the |
We'd like the API to be consistent to simplify clients and we believe it's worth the change in behaviour here. Is there a particular client that you know this will break? |
bnbarham
force-pushed
the
always-add-module-name
branch
from
a006806
to
fcd5a9e
Compare
|
@swift-ci please test |
To simplify clients, have the cursorinfo result be consistent whether requesting a symbol within the current module or not, ie. do not skip adding the module name. Resolves rdar://77003299
bnbarham
force-pushed
the
always-add-module-name
branch
from
fcd5a9e
to
8128450
Compare
|
@swift-ci please test |
|
Well I'll fix up the clients I look after - just wanted to make sure you were aware that this is a breaking change. |
I'm interested into what sort of breakage emitting the module name causes - is there any more details you can give there? Specifically, I'd like to make sure there's an alternative if we do go ahead with the change. |
|
In jazzy, one example is figuring out whether a decl that is missing doc comments is from the user's module or not (ie. related to an extension of a type from somewhere else). The code that does this today does not know [has not needed to know] the name of the user's module -- so I imagine the change is 'just' plumbing this through, as I expect will be the same anywhere else. |
|
Yeah, plumbing it through seems reasonable for clients that need to differentiate on current vs other modules. Thanks for the details! |
To simplify clients, have the cursorinfo result be consistent whether
requesting a symbol within the current module or not, ie. do not skip
adding the module name.
Resolves rdar://77003299