Obj-C subscripts don’t work on class objects, but you can declare class methods with the appropriate names. We don’t want to half-support this. Emit an error if you try to write “@objc class subscript” and test that we don’t import the methods as subscripts.
Okay, strictly we're checking the "signature conformances" of a newly-
declared conformance, but that wouldn't have fit on one line. This is
making sure that we don't have a requirement on an associated type (or
on the conforming type) that can only be satisfied using a conformance
in an implementation-only import.
These also create a dependency on the implementation module, even if
both the type and the protocol are public. As John puts it, a
conformance is basically a declaration that we name as part of another
declaration.
More rdar://problem/48991061
This fixes a test involving transitive captures of local functions,
as well as an infinite recursion possible with the old code.
Fixes <rdar://problem/34496304>.
Some diagnostics got worse, but I think the reduction in compiler complexity
is worth it, and copy-and-pasting Swift 2 code is not likely to produce great
results anyway.
Also, this corrects an oversight where we did not reject @pseudogeneric on
function types in AST parsing.
The new pass is based on existing asserts in DiagnoseStaticExclusivity.
They were compiled out in release builds and only checked for captures of
inout parameters. This patch converts the assertions into diagnostics and
adds checks for captures of non-escaping function values.
Unlike the Sema-based checks that this replaces, the new code handles
transitive captures from recursive local functions, which means certain
invalid code that used to compile will now be rejected with an error.
The new analysis also looks at the ultimate usages of a local function
instead of just assuming all local functions are escaping, which fixes
issues where the compiler would reject valid code.
Fixes a bunch of related issues, including:
- <rdar://problem/29403178>
- <https://bugs.swift.org/browse/SR-8546> / <rdar://problem/43355341>
- <https://bugs.swift.org/browse/SR-9043> / <rdar://problem/45511834>
Based on the existing access checker for types used in decls. There's
a common skeleton here but we can't seem to get it out, so for now
add a third DeclVisitor to this file. On the plus side, checking this
alongside access is an easy way to make sure everything gets checked.
Part of rdar://problem/48991061
Specifically the bad pattern was:
```
for (auto *vd : *caseStmt->getCaseBodyVariables()) { ... }
```
The problem is that the optional is not lifetime extended over the for loop. To
work around this, I changed the API of CaseStmt's getCaseBodyVariable methods to
never return the inner Optional<MutableArrayRef<T>>. Now we have the following 3
methods (ignoring const differences):
1. CaseStmt::hasCaseBodyVariables().
2. CaseStmt::getCaseBodyVariables(). Asserts if the case body variable array was
never specified.
3. CaseStmt::getCaseBodyVariablesOrEmptyArray(). Returns either the case body
variables array or an empty array if we were never given any case body
variable array.
This should prevent anyone else in the future from hitting this type of bug.
radar://49609717
module imports. This is useful when building redistributable static
archives, since any pointers into the CLang module cache won't be
portable.
When using this option the Clang type fallback path in LLDB will be
less useful since DWARF type information from those modules will not
be available unless another object file compiled without the option
imported the same modules.
rdar://problem/48827784
