SourceKit-LSP currently parses the XML comment to generate Markdown again but round-tripping a (probably markdown) doc comment to XML to Markdown is lossy in many cases and unnecessary work. Include the comment as it is spelled in source in the cursor info response so that sourcekit-lsp can display it.
Part of rdar://120685874
When completing in cases like `bar(arg: foo(|, option: 1)`, we don’t know if `option` belongs to the call to `foo` or `bar`. Be defensive and also suggest the signature.
The IDE's use isn't correct under noncopyable generics and only the
constraint solver uses it. It's a misleading method now that nearly
every archetype has Copyable/Escapable requirements.
Unify with `CTP_ReturnStmt`, and have the
SyntacticElementTarget carry the ReturnStmt for
regular type-checking, which we can use to record
implied returns.
Use the generalized implied result logic, and
rename to `isImpliedResult` since that's really
what we're querying here, and it needs to handle
implicit-last-exprs if enabled.
Test shadowed variable of same type
Fully type check caller side macro expansion
Skip macro default arg caller side expr at decl primary
Test macro expand more complex expressions
Set synthesized expression as implicit
Add test case for with argument, not compiling currently
Test with swiftinterface
Always use the string representation of the default argument
Now works across module boundary
Check works for multiple files
Make default argument expression work in single file
Use expected-error
Disallow expression macro as default argument
Using as a sub expression in default argument still allowed as expression macros behave the same as built-in magic literals
Remove this bit from function decls and closures.
Instead, for closures, infer it from the presence
of a single return or single expression AST node
in the body, which ought to be equivalent, and
automatically takes result builders into
consideration. We can also completely drop this
query from AbstractFunctionDecl, replacing it
instead with a bit on ReturnStmt.
This can occur for e.g multi-statement closure
returns (and soon for singe-expression closures
too), so fall back to evaluating the expression
type if it's not fully resolved.
The old TypeAttributes reprsentation wasn't too bad for a small number of
simple attributes. Unfortunately, the number of attributes has grown over
the years by quite a bit, which makes TypeAttributes fairly bulky even at
just a single SourceLoc per attribute. The bigger problem is that we want
to carry more information than that on some of these attributes, which is
all super ad hoc and awkward. And given that we want to do some things
for each attribute we see, like diagnosing unapplied attributes, the linear
data structure does require a fair amount of extra work.
I switched around the checking logic quite a bit in order to try to fit in
with the new representation better. The most significant change here is the
change to how we handle implicit noescape, where now we're passing the
escaping attribute's presence down in the context instead of resetting the
context anytime we see any attributes at all. This should be cleaner overall.
The source range changes around some of the @escaping checking is really a
sort of bugfix --- the existing code was really jumping from the @ sign
all the way past the autoclosure keyword in a way that I'm not sure always
works and is definitely a little unintentional-feeling.
I tried to make the parser logic more consistent around recognizing these
parameter specifiers; it seems better now, at least.
Now that there is an actual declaration for `Copyable` we should be emitting that as a code completion result instead of a keyword, like we currently do.
rdar://109107817
Previously, were were suggesting to add `()` after eg. `x.` if `x` has a function type, resulting in `x.()`, which is incorrect. We need to remove the `.` in the completion suggestion.
rdar://121155241
This removes the distinction between argument completions and postfix expr paren completions, which was meaningless since solver-based completion.
It then determines whether to suggest the entire function call pattern (with all argument labels) or only a single argument based on whether there are any existing arguments in the call.
For this to work properly, we need to improve parser recovery a little bit so that it parsers arguments after the code completion token properly.
This should make call pattern heuristics obsolete.
rdar://84809503
