We were asserting that the attribute range recorded in the AST started at the
same location as the fist unconsumed SyntaxNode in the file. This should be
true in most cases, but isn't for mispelled attributes, corrected in the AST
but not recognised or present in the list of SyntaxNodes. E.g.
@availability(...) comes through as if @available(...) was specified, but
there's no SyntaxNode for it because we don't highlight invalid attributes
(to indicate they're invalid).
Resolves rdar://problem/62201594
Resolves https://bugs.swift.org/browse/SR-12500
Protocol extension only members are not customization point. Code
completion should not suggest them in override/conformance completion.
rdar://problem/53591636
For exmaple:
func foo(_: Int, _: IntOption)
func foo(_: Float, _: FloatOption)
foo(intVal, .<HERE>)
Previously code completion suggests static member from 'IntOption' and
'FloatOption' without any prioritization. Prioritize members from
'IntOption' because the user probably wants to input them.
In such cases, 'CodeCompletionExpr' at the cursor position is
pre-typechecked to 'IntOption'. So mark results with matching type with
'ExprSpecific'.
rdar://problem/62121221
If any arguments were defaulted the tuple/paren was made implicit, even though
the original tuple/paren was present in the source.
This prevented some sourcekit ASTWalkers from considering them, making
refactorings, documentation info, jump-to-definition and other features
unavailable when queried via their argument labels.
Resolves rdar://problem/62118957
Remove duplication in the modeling of TypeExpr. The type of a TypeExpr
node is always a metatype corresponding to the contextual
type of the type it's referencing. For some reason, the instance type
was also stored in this TypeLoc at random points in semantic analysis.
Under the assumption that this instance type is always going to be the
instance type of the contextual type of the expression, introduce
a number of simplifications:
1) Explicit TypeExpr nodes must be created with a TypeRepr node
2) Implicit TypeExpr nodes must be created with a contextual type
3) The typing rules for implicit TypeExpr simply opens this type
We weren't handling this case, so their generated interfaces / doc info
wouldn't include symbols from the cross-import overlays, and we wouldn't
map the underscored cross-import overlay name back to the declaring
framework's name in cusor-info, completion results or when indexing.
Resolves rdar://problem/62138551
Add ModuleImplicitImportsRequest, which computes
the modules that should be implicitly imported by
each file of a given module. Use this request in
import resolution to add all the necessary
implicit imports.
The request computes the implicit imports by
consulting the ImplicitImportInfo, which ModuleDecl
can now be created with. This allows us to remove
uses of `SourceFile::addImports` in favor of
adding modules needed to be implicitly imported to
the ImplicitImportInfo.
E.g. if/guard condition patterns are column-aligned, but hitting enter after
the ',' below wasn't column-aligning the next empty line:
guard let x = Optional(42),
// No indentation added here after enter
Also the isTargetContext() check takes a start and end token location, but
wasn't accounting for the end location pointing a multiline string, so we
weren't walking into such nodes. This meant we didn't realise the target
location was within a multiline string in some cases, and we ended up
interfering with whitespace in its content.
When completing inside tuple expressions, the context tuple type may
have fewer number of elements. In such cases, we cannot provide the
expected type.
rdar://problem/61668779
They were missed before, so < > that should trigger outdenting weren't. E.g.
let x = foo<
Int, String, Int
>()
.count // Indented becase we didn't process the < > brackets previously.
