…at least in the specific case of initializers.
Normally, clang validates that a SwiftNameAttr’s specified name seems to have the right number of argument labels for the declaration it’s applied to; if it doesn’t, it diagnoses and drops the attribute. However, this checking isn’t perfect because clang doesn’t know all of Clang Importer’s throwing rules. The upshot is that it’s possible to get a mismatched SwiftNameAttr into Clang Importer if the last parameter looks like an out parameter. This trips an assertion in asserts compilers, but release compilers get past that and don’t seem to notice the mismatch at all.
Add code to the compiler to tolerate this condition, at least in initializers, by modifying the Swift name to have the correct number of argument labels and deprecating the declaration with a message explaining the problem.
Fixes rdar://141124373.
Initializers should always have Swift names that have the special `DeclBaseName::createConstructor()` base name. Although there is an assertion to this effect in the constructor for ConstructorDecl, ClangImporter did not actually reject custom Swift names for initializers that violated this rule. This meant that asserts compilers would crash if they encountered code with an invalid `swift_name` attribute, while release compilers would silently accept them (while excluding these decls from certain checks since lookups that were supposed to find all initializers didn’t find them).
Modify ClangImporter to diagnose this condition and ignore the custom Swift name.
This relands commit 45d4648bdb while ensuring that
sanityCheckCachedType uses the exact same condition (now factored into a helper
function) as createType() to determine whether a type is sized or not.
rdar://143833326
It fails with enabled OSSA modules and when run in optimize mode.
The problem is that TestErrorDomain (a NSString pointer) is null, but it's not imported as Optional<NSString>.
rdar://143681997
Consider code like:
```
// Foo.h
typealias NSString * FooKey NS_EXTENSIBLE_TYPED_ENUM;
// Foo.swift
extension FooKey { … }
```
When Swift binds the extension to `FooKey`, that forces ClangImporter to import `FooKey`. ClangImporter’s newtype logic, among other things, checks whether the underlying type (`Swift.String` here) is Objective-C bridgeable and, if so, makes `FooKey` bridgeable too.
But what happens if this code is actually *in* Foundation, which is where the `extension String: _ObjectiveCBridgeable` lives? Well, if the compiler has already bound that extension, it works fine…but if it hasn’t, `FooKey` ends up unbridgeable, which can cause both type checking failures and IRGen crashes when code tries to use its bridging capabilities. And these symptoms are sensitive to precise details of the order Swift happens to bind extensions in, so e.g. adding empty files to the project can make the bug appear or disappear. Spooky.
Add a narrow hack to ClangImporter (only active for types in Foundation) to *assume* that `String` is bridgeable even if the extension declaring this hasn’t been bound yet.
Fixes rdar://142693093.
When Swift passes search paths to clang, it does so directly into the HeaderSearch. That means that those paths get ordered inconsistently compared to the equivalent clang flag, and causes inconsistencies when building clang modules with clang and with Swift. Instead of touching the HeaderSearch directly, pass Swift search paths as driver flags, just do them after the -Xcc ones.
Swift doesn't have a way to pass a search path to clang as -isystem, only as -I which usually isn't the right flag. Add an -Isystem Swift flag so that those paths can be passed to clang as -isystem.
rdar://93951328
Which consists of
* removing redundant `address_to_pointer`-`pointer_to_address` pairs
* optimize `index_raw_pointer` of a manually computed stride to `index_addr`
* remove or increase the alignment based on a "assumeAlignment" builtin
This is a big code cleanup but also has some functional differences for the `address_to_pointer`-`pointer_to_address` pair removal:
* It's not done if the resulting SIL would result in a (detectable) use-after-dealloc_stack memory lifetime failure.
* It's not done if `copy_value`s must be inserted or borrow-scopes must be extended to comply with ownership rules (this was the task of the OwnershipRAUWHelper).
Inserting copies is bad anyway.
Extending borrow-scopes would only be required if the original lifetime of the pointer extends a borrow scope - which shouldn't happen in save code. Therefore this is a very rare case which is not worth handling.
I tried to port this behavior to another test that validated the behavior using
RBI. When I tried to do so I ran into the issue that the behavior in this test
only reproduces in targeted mode not in complete mode which is required for rbi
to run.
Type annotations for instruction operands are omitted, e.g.
```
%3 = struct $S(%1, %2)
```
Operand types are redundant anyway and were only used for sanity checking in the SIL parser.
But: operand types _are_ printed if the definition of the operand value was not printed yet.
This happens:
* if the block with the definition appears after the block where the operand's instruction is located
* if a block or instruction is printed in isolation, e.g. in a debugger
The old behavior can be restored with `-Xllvm -sil-print-types`.
This option is added to many existing test files which check for operand types in their check-lines.
Fixes an issue where parent type wasn't set for qualified ObjC
pointers which leads to crashes during Sema because non-pointer
uses are imported correctly.
Resolves: rdar://102564592
Sometimes features are removed from `Features.def`, but they are not
removed from the test files. The compiler ignores every feature that
does not exist. This leads to removed features still being tested, and
with the introduction of #76740, `REQUIRED:`.
Modify the code that generates the active feature set for testing to
also generate the set of existing features, and pass this list of
existing features to the verifier script. If a feature is trying to be
activated and does not exist, the verifier will warn the user.
- `SwiftParser` feature was renamed `ParserASTGen`, but some tests were
using both spellings. Remove the mentions of `SwiftParser` in the
tests.
- `ImportObjcForwardDeclarations` was spelled with upper case `C` in
a couple of tests. Fix it so the matching is easier.
- `TransferringArgsAndResults` was an experimental feature that was
removed.
- Ignore the usage of inexisting feature in `swift-export-as.swift`
because it seems to be what the test is actually testing.
- Ignore the test `availability_define.swift` because it tests the
pseudo-feature `AvailabilityMacro=` which is not part of
`Features.def`.
Find all the usages of `--enable-experimental-feature` or
`--enable-upcoming-feature` in the tests and replace some of the
`REQUIRES: asserts` to use `REQUIRES: swift-feature-Foo` instead, which
should correctly apply to depending on the asserts/noasserts mode of the
toolchain for each feature.
Remove some comments that talked about enabling asserts since they don't
apply anymore (but I might had miss some).
All this was done with an automated script, so some formatting weirdness
might happen, but I hope I fixed most of those.
There might be some tests that were `REQUIRES: asserts` that might run
in `noasserts` toolchains now. This will normally be because their
feature went from experimental to upcoming/base and the tests were not
updated.
A recent PR (#77204) started to import C++ source locations into Swift.
This PR flips a switch so these locations are actually used more widely.
Now some of the diagnostic locations are changed, but they generally
improved the quality of the diagnostics, pointing out conformances
imported from Obj-C code right when they are declared.
https://github.com/swiftlang/swift/pull/77236 caused a source compatibility
regression because `extractEnumElement()` does not suppress its diagnostics in
the context of pattern matching. Potentially unavailable enum elements should
not be diagnosed when pattern matching since the generated code will not
retrieve the potentially unavailable element value on versions where it is
unavailable.
Fixes rdar://138771328.
* [cxx-interop] Add Hashable conformance to imported enums
Previously, imported enums only conformed to RawRepresentable and Equatable,
so they could not be used as members of a Set or keys of a Dictionary.
This patch adds Hashable conformance to give them that ability,
as well as some test cases to clarify the expected behavior.
Existing test cases are updated to reflect this new conformance.
rdar://129713687
The diagnostics engine has some code to pretty-print a declaration when
there is no source location for that declaration. The declaration is
pretty-printed into a source buffer, and a source location into that
buffer is synthesizes. This applies to synthesized declarations as well
as those imported from Swift modules (without source code) or from Clang.
Reimplement this pretty-printing for declarations as a request. In
doing so, change the manner in which we do the printing: the
diagnostics engine printed the entire enclosing type into a buffer
whose name was the module + that type. This meant that the buffer was
shared by every member of that type, but also meant that we would end
up deserializing a lot of declarations just for printing and
potentially doing a lot more work for these diagnostics.
- Don't attempt to insert fixes if there are restrictions present, they'd inform the failures.
Inserting fixes too early doesn't help the solver because restriction matching logic would
record the same fixes.
- Adjust impact of the fixes.
Optional conversions shouldn't impact the score in any way because
they are not the source of the issue.
- Look through one level of optional when failure is related to optional injection.
The diagnostic is going to be about underlying type, so there is no reason to print
optional on right-hand side.
Honour the SDK for APINotes to augment the system libraries. This allows
us to distribute APINotes with the Swift SDK and impact the system
without having to map the APINotes into the filesystem.
Also, dump the module map paths when `-Xfrontend -dump-clang-diagnostics` is
passed in, both so we can check that manually and in these tests, and fix
another Frontend test to be more specific now that this other output trips it up.
