To return accurate type of the expression.
i.e.
MyType.foo(#^COMPLETE^# // -> (MyType) -> (args...) -> Result
MyType().foo(#^COMPLETE^# // -> (args...) -> Result
There were 2 functions to output argument list. Consolidate them and
consistently use it from every call like production (i.e. function call,
constructor call, enum with associated values, subscript)
Instead of re-typechecking parsed expression, find typechecked
expression that corresponds to the parsed expression from the
typechecked decl context, because the sub expressions of the parsed
expression can be weirdly mutated/replaced by decl context typechecking.
rdar://problem/48141174
"Fixes" <rdar://problem/30680565> -- the "reconstruct_type_from_mangled_name_invalid"
test has been disabled since 2017, and the output has changed a fair bit. But the
FIXMEs have been addressed and it can reconstruct the associated type and
type alias now, and there's no harm in re-enabling it now.
enum MyEnum {
case null
case str(String)
}
When completing elements for enum like this, the former shows `MyEnum`,
but the latter shows `(String) -> MyEnum`. This is inconsistent with
function call pattern which only shows the result type.
rdar://problem/48220244
For `Initializer` decl context, type context analyzer should look into
its parent context because that might constrain initializer's type.
rdar://problem/48208253
This is libIDE side implementation for collecting all type information in a source
file. When several expression share the same source range, we always report the
type of the outermost expression.
rdar://35199889
For context, String, Nil, and Bool already behave this way.
Note: Before it used to construct (call, ... (integer_literal)), and the
call would be made explicit / implicit based on if you did eg: Int(3) or
just 3. This however did not translate to the new world so this PR adds
a IsExplicitConversion bit to NumberLiteralExpr. Some side results of
all this are that some warnings changed a little and some instructions are
emitted in a different order.
`source.request.conformingmethods` is a new SourceKit request which
receives a source position and a list of protocol namses, returns a list
of methods whose return type conforms to the requested protocols.
rdar://problem/44699573
There was only one remaining usage other than in testing tools.
Note that when a declaration mangling was passed in, the old entry
point would (try to) return the type of the declaration.
The new entry point no longer has this behavior. I changed the
bridging-header-first test to run lldb-moduleimport-test with
-decl-from-mangled instead of -type-from-mangled-old to preserve
the behavior of the test.
Also, I removed test/DebugInfo/DumpTypeFromMangledName.swift
completely. This test only covered a handful of cases, and a bunch
of them were declaration manglings rather than type manglings.
The new tests in test/TypeDecoder/ are much more comprehensive.
`@unknown` is so far the only attribute for statement. Handle it
specially in syntax-map.
rdar://problem/47855035 / https://bugs.swift.org/browse/SR-9873
* Handle sequence expression at call argument position
* Set the sequence expression as the parent when walking into its sub
expressions.
* Correctly call walkToExprPost() to the sequence expression.
rdar://problem/47603866 / https://bugs.swift.org/browse/SR-9776
