In addition to capturing more detailed preprocessor info, the
DetailedPreprocessorRecord option sets the clang module format to 'raw'
rather than the default 'object'. Sourcekitd doesn't link the code
generation libs, which it looks like the default 'object' format requires,
so it sets this option to true. The subinvocation generated when loading a
module from a .swiftinterface file still used the default prior to this
change though, so it would end up crashing sourcekitd.
This change sets the DetailedProccessorRecord option if the DetailedRecord
option is set on the preprocessor options of parent context's clang module
loader. This fixes interface generation crashing for modules that only have
a .swiftinterface file.
rdar://problem/43906499
We were checking the parent invocation's DiagnosticEnginer rather than the
subinstance's to determine if there were any errors building the module, which
meant we would fail to load the module if there were errors prior to the import
statement in the importing file.
This also meant code completion would fail to load the module, because it always
emits a bogus error in order to mark the AST as erroneous so that different
parts of the compiler (e.g. the verifier) have less strict assumptions.
rdar://problem/43906499
`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
We were checking the parent invocation's DiagnosticEnginer rather than the
subinstance's to determine if there were any errors building the module, which
meant we would fail to load the module if there were errors prior to the import
statement in the importing file.
This also meant code completion would fail to load the module, because it always
emits a bogus error in order to mark the AST as erroneous so that different
parts of the compiler (e.g. the verifier) have less strict assumptions.
rdar://problem/43906499
SourceKit document structure request used to crash if if there's inititalizer
with single named parameter with `@IBAction` attribute.
This used to happen because
ConstructorDecl::isObjCZeroParameterWithLongSelector() requires
interface type of the parameter but the constructor doesn't have it at
this stage.
This change fixes that by not vending ObjC name for
constructor or destructors.
rdar://problem/47426948
The type checker calls these types Builtin.FPIEEE<size>; the demangler
should too.
This is just cosmetic at the moment, but it was causing problems when
I added support for builtin types to the TypeDecoder.
This is a new SourceKit request which receives a position in the source
file, returns possible expected types and their members which can be
referenced by "implicit member expression" syntax.
Semantically, these are not superclass/refined-protocol members.
If I have a generic parameter <T : P & Q>, then when looking at
a value of type T, members of P and Q are at the same "level" as
if I had a value of type (P & Q).
When printing its annotated decl, we would would assume the param's default
value is present if the default value kind was "Normal". The type checker
explicitly sets the default value to nullptr if it doesn't type check though, so
we were crashing for that case. Added the check.
Resolves rdar://problem/46694149
* Add swift_evolve feature and disable several tests
This change adds a swift_evolve feature to our lit configuration and uses it to mark several tests as unsupported by swift_evolve.
One of these—test/api-digester/stability-stdlib-abi.swift—is actually pretty bad; we would really like to have it. But the digester has known issues exposed by swift-evolve.
* Remove order dependency in another test
* Tweaks from Jordan’s review
* Distinguish between tests which are intentionally unsupported and temporarily disabled.
* Add an explanation for one unsupproted test.
* Code nitpick.
The standard library has two versions of the `abs(_:)` function:
```
func abs<T : SignedNumeric>(_ x: T) -> T where T.Magnitude == T
func abs<T : SignedNumeric & Comparable>(_ x: T) -> T
```
The first is more specialized than the second because `T.Magnitude` is
known to conform to `Comparable`. Indeed, it’s a more specialized
implementation that returns `magnitude`.
However, this overload behaves oddly: in the expression `abs(-8)`, the type
checker will pick the first overload because it is more specialized. That’s
a general guiding principle for overloading: pick the most specialized
overload that works.
However, to select that overload, it needs to pick a type for the literal
“8” for which that overload works, and it chooses `Double`. The “obvious”
answer, `Int`, doesn’t work because `Int.Magnitude == UInt`.
There is a conflict between the two rules, here: we prefer more-specialized
overloads (but we’ll fall back to less-specialized if those don’t work) and we prefer to use `Int` for integer literals (but we’ll fall back to `Double` if it doesn’t work). We have a few options from a type-checker
perspective:
1. Consider the more-specialized-function rule to be more important
2. Consider the integer-literals-prefer-`Int` rule to be more important
3. Call the result ambiguous and make the user annotate it
The type checker currently does #1, although at some point in the past it
did #2. Moving forward, #1 is a better choice because it prunes the number
of overloads that need to be considered: if the more-specialized overload
succeeds its type-check, the others need not be considered. It’s also
easier to reason about than the literal-scoring approach, because there can
be a direct definition for “more specialized than” that can be reasoned
about.
I think we should dodge the issue by removing the more-specialized version
of `abs(_:)`. Its use of `magnitude` seems unlikely to provide a
significant performance benefit, and the presence of overloading either
forces us to consider both overloads always (which is bad for type checker
performance) or accept the regression that `abs(-8)` is `Double`. Better
to eliminate the overloading and, if needed in the future, find a better
way to introduce the more-specialized implementation without it being a
separate signature.
Fixes rdar://problem/42345366.
We already disabled one of these because it failed (extremely) rarely in
CI, but the assumption was that there was a bug. In reality, the
behaviour was correct, so remove the unreliable checks for good and
document why in the test.
rdar://36408114
Module references get indexed as a 'module' symbol; they get USRs similar to how clang would assign a USR for a module reference.
JIRA: https://bugs.swift.org/browse/SR-8677
