_math would be able to build against either the Swift or the clang
module for _Builtin_float; however the build will fail if the Swift
module is present but does not contain the architectures we need, with errors
like
```
<unknown>:0: error: could not find module
'_Builtin_float' for target 'armv7-unknown-linux-android'; found:
aarch64-unknown-linux-android, x86_64-unknown-linux-android, at:
/home/build-user/build/swift-project/Ninja-Release/swift-linux-x86_64/lib/swift/android/_Builtin_float.swiftmodule/armv7-unknown-linux-android
```
In other words, in this situation we are not falling back to the clang
module.
Addresses rdar://165768601
(cherry picked from commit 817a890a67)
If we didn't find an extension result, try again disregarding
invertible requirements since `demangleGenericSignature` won't
include them. This is just meant to be a quick low risk fix that we
can cherry-pick, the proper fix here is to delete all this logic and
just return the nominal along with the ABI module name to filter
lookup results.
rdar://165639044
If we try to import this in ObjC interop mode:
```objc
typedef CF_OPTIONS(uint32_t, MyFlags) {
...
} CF_SWIFT_NAME(MyCtx.Flags);
struct MyStruct {
MyFlags flags;
...
} CF_SWIFT_NAME(MyCtx);
```
ClangImporter tries to import `MyCtx/MyStruct` before it imports
`MyFlags` (via `importDeclContextOf()`), which in turn tries to import
`MyFlags` again due to the `flags` field. The existing cycle-breaking
mechanism prevents us from looping infinitely, but leads us to import
two copies of the Swift `EnumDecl`, which can cause errors later during
CodeGen.
~~This patch adds an assertion to catch such issues earlier, and breaks
the cycle by checking the cache again.~~ This patch no longer does so
because that caused issues beyond the scope of this patch.
rdar://162317760
(cherry picked from commit f830b1c665)
Handle the following situation:
```swift
struct S {
func test() {}
static func test(_: S) {}
}
```
Calling `S.test(s)` where `s` has a type `S` without any other context
should prefer a complete call to a static member over a partial
application of an instance once based on the choice of the base type.
The behavior is consistent for double-applies as well i.e.
`S.test(s)()` if static method produced a function type it would be
preferred.
Resolves: rdar://165862285
(cherry picked from commit 7c32c2a21b)
We already had bookkeeping to track which statement in a multi-statement
closure we were looking at, but this was only used for the 'reasonable time'
diagnostic in the case that we hit the expression timer, which was almost
never hit, and is now off by default. The scope, memory, and trial limits
couldn't use this information, so they would always diagnose the entire
target being type checked.
Move it up from ExpressionTimer to ConstraintSystem, so that we get the
right source location there too. Also, factor out some code duplication
in BuilderTransform to ensure we get the same benefit for result builders
applied to function bodies too.
As with all other where clauses, we must resolve the requirements twice;
first in structural stage to build the generic signature, and second in
interface stage to check that any generic types that appear within
satisfy requirements. We weren't doing the latter for @specialize, which
would result in SIL crashes if such invalid SIL types appeared therein.
Fixes rdar://165909327.
During parallel clang module dependency resolution, an unintended side-effect of https://github.com/swiftlang/swift/pull/84929 is that we stopped uniquing the module identifiers we query to the Clang dependency scanner.
This change ensures we do not query the same identifier more than once.
Resolves rdar://165133617
Adding check to CMake to verify that we have the os_signpost and os_log
API available in order to accept enabling the runtime tracing.
(cherry picked from commit 20cfe0a4e0)
A previous change introduced the "resolveRemoteAddress" API in the
MemoryReader interface, along with one use of it. However, the resolved
memory address is created, but left accidentally unused.
rdar://161919584
(cherry picked from commit 3472c00cba)
By calling `printCommon` twice, this inserts a JSON object into
another JSON object without a key. This asserts inside LLVM's
JSON helper, but only if the compiler is built with assertions
enabled (which Xcode's compiler doesn't).
This also fixes the S-expression version, which is similarly busted:
```
(pattern_entry
(async_let type="Int" (pattern_any type="Int")
(original_init=call_expr type="Int" ...
```
This avoids infinite recursion when a function captures itself; e.g.,
```swift
func foo() {
func bar() {
bar()
}
bar()
}
```
It also just avoids printing unnecessarily verbose information,
since those decls would have already been dumped elsewhere in the
tree.
`ModuleType`s show up in some rare places, like the left-hand-side of
a `DotSyntaxBaseIgnoredExpr` for a module-qualified function call.
ASTMangler does not support these because they're not real types.
The type of an outermost property wrapper should be printed together
with (inferred) generic arguments because otherwise if a any wrapper
in the chain has generic parameters that are not involved in
`wrappedValue:` argument it won't be impossible to infer them while
type-checking the interface file where it appears.
Resolves: rdar://122963120
(cherry picked from commit 5b665a8426)
