There are similar tests for other architectures/OS pairs, but
android-aarch64 was missing. This should ensure that the conditional
compilation for Android works correctly in this case.
Android ARMv7 has an LLVM triple of armv7-none-linux-androideabi, but
the Swift module triple is just armv7-node-linux-android. The change
removes the "eabi" bit for the %module-target-triple substitution of lit
to avoid an error in the test
test/SourceKit/CursorInfo/cursor_swiftonly_systemmodule.swift.
Android AArch64 wasn't affected because the LLVM triple for it is just
aarch64-none-linux-android.
The GSB should avoid triggering declaration validation where
possible, to avoid problems resulting from circularity and as
a general performance rule-of-thumb.
This last call was there to catch self-recursive protocol
typealiases. However, we can diagnose this problem elsewhere,
which allows us to emit a more accurate diagnostic as well.
That OS doesn't have objc_readClassPair(). This test uses -target to
explicitly select a newer deployment target and then runs the binary
on an old OS to test the behavior. However this means arclite won't
get linked in unless we also pass in -link-objc-runtime.
Fixes <rdar://problem/50610877>.
This test checks that error bridging with ObjC bridging works when the stdlib is statically linked. We no longer support static linking of the stdlib on platforms with ObjC interop.
rdar://problem/49699316
This change permits UnresolvedDotExpr to have both a name and a base that are implicit, but a valid DotLoc, and to treat that DotLoc as the node’s location. It then changes the generation of string interpolation code so that `$stringInterpolation.appendInterpolation` references have a DotLoc corresponding to the backslash in the string literal.
This makes it possible for `ExprContextAnalyzer` in IDE to correctly detect when you are code-completing in a string interpolation and treat it as an `appendInterpolation` call.
Now that we manipulate the argument list to correct strange interpolations in Sema, we can parse interpolations directly as argument lists, simplifying the parser.
By itself, this refactoring causes a code completion regression; a subsequent commit will fix that.
This defers diagnosis until a stage where #if conditions have definitely been evaluated, at the cost of a slightly more complex implementation. We’ll gain some of that complexity back in a subsequent refactoring. Fixes SR-9937.
This is the complement to load canonicalization. Although store
canonicalization is not required before diagnostics, it should be
defined in the same utility.
Instead of always requiring a call to be made to pass argument
to `@autoclosure` parameter, it should be allowed to pass argument
by value to `@autoclosure` parameter which can return a function
type.
```swift
func foo<T>(_ fn: @autoclosure () -> T) {}
func bar(_ fn: @autoclosure @escaping () -> Int) { foo(fn) }
```
We use the just-built clang without any -target or -sdk flags. Keep things
simple and limit the test to macOS for now.
Fixes <rdar://problem/50586614>.
Previously 'isSystemModule()' returns true only if the module is:
- Standard library
- Clang module and that is `IsSystem`
- Swift overlay for clang `IsSystem` module
Now:
- Clang module and that is `IsSystem`; or
- Swift overlay for clang `IsSystem` module
- Swift module found in either of these directories:
- Runtime library directoris (including stdlib)
- Frameworks in `-Fsystem` directories
- Frameworks in `$SDKROOT/System/Library/Frameworks/` (Darwin)
- Frameworks in `$SDKROOT/Library/Frameworks/` (Darwin)
rdar://problem/50516314
When we remove Sema's UsedConformances list, conformances to _BridgedStoredNSError
are checked from SILGen, where its too late to check function bodies of synthesized
functions.
We could solve this by adding a callback to type check a synthesized function's
body, but in fact all synthesized functions are rather trivial so it's better to
build their bodies fully type checked.
Start by building fully checked expressions for various accessors in ClangImporter.
We don't require or allow '&' for the mutable parameters in
operator calls, since we want to write 'x += 10' and not
'&x += 10'.
The constraint sovler accepted '&x += 10' though, and we had
a separate pass in MiscDiagnostics for rejecting it.
Instead, let's just reject this in the solver.
The main difficulty is that we must now be prepared to fail
certain OperatorArgumentConversion and ApplicableFunction
constraints even when both the LHS and RHS types are equal.
Now covers following new areas (alongside simple assignments):
- Contextual type coercions:
- In assignment e.g. `let _: X = foo`
- In return type positions e.g. `func foo() -> A { return bar }`
- Argument-to-parameter applications (including @autoclosure)
