The clang nodes associated with Swift's Core Foundation types can already be
represented by a pointer. The interop code does not need to add an extra
layer of indirection in those cases.
rdar://119840281
I've seen a crash due to importDeclContextOf returning a null decl
context in importAccessorParamsAndReturnType. Most other call sites of
importDeclContextOf check the returned value, so add a check in
importAccessorParamsAndReturnType too.
rdar://127847162
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
Make sure the `-Xcc` options to the scanner are correctly considered
when creating ClangImporterCC1 arguments for constructed swift interface
compilation job. Under directcc1 mode, `-Xcc` options should be used to
constructed sub-invocation but should not be added to GenericArgs for
constructing interface compilation jobs.
rdar://128873665
Teach dependency scanner to report all the module canImport check result
to swift-frontend, so swift-frontend doesn't need to parse swiftmodule
or parse TBD file to determine the versions. This ensures dependency
scanner and swift-frontend will have the same resolution for all
canImport checks.
This also fixes two related issues:
* Previously, in order to get consistant results between scanner and
frontend, scanner will request building the module in canImport check
even it is not imported later. This slightly alters the definition of
the canImport to only succeed when the module can be found AND be
built. This also can affect the auto-link in such cases.
* For caching build, the location of the clang module is abstracted away
so swift-frontend cannot locate the TBD file to resolve
underlyingVersion.
rdar://128067152
There is no need to pass output path of the PCM compilation twice, once
as swift `-o` flag and other time as `-Xcc -o` flag to clang importer.
This can also cause swift caching to miss when output path is different
because `-Xcc` options are not modeled in caching model to understand
`-o` output path doesn't affect compilation output content.
rdar://128650954
We were accidentally setting `requiresBuiltinHeadersInSystemModules` because
the `else` here gets executed for things that are not WASI or Musl. Fix
by making it conditional.
rdar://128219177
When a C++ type `ForeignTy` is imported as a foreign reference type, Swift should strip a level of indirection from parameters of that type, so e.g. `ForeignTy *` and `ForeignTy &` should be imported to Swift as just `ForeignTy`. However, it should only strip *one* level of indirection. importType() was instead stripping *all* levels, so things like `ForeignTy **` and `ForeignTy *&` were *also* being incorrectly imported as `ForeignTy`. Narrow this behavior so it only applies to a single level of indirection and add a few test cases to pin down the specifics.
Fixes rdar://123905345.
…for extensions. This change also removes @implementation(CategoryName); you should attach the category name to the @objc attribute instead. And there are small changes to how much checking the compiler will do on an @objc @implementation after the decl checker has discovered a problem with it.
A few things:
1. Internally except for in the parser and the clang importer, we only represent
'sending'. This means that it will be easy to remove 'transferring' once enough
time has passed.
2. I included a warning that suggested to the user to change 'transferring' ->
'sending'.
3. I duplicated the parsing diagnostics for 'sending' so both will still get
different sets of diagnostics for parsing issues... but anywhere below parsing,
I have just changed 'transferring' to 'sending' since transferring isn't
represented at those lower levels.
4. Since SendingArgsAndResults is always enabled when TransferringArgsAndResults
is enabled (NOTE not vis-a-versa), we know that we can always parse sending. So
we import "transferring" as "sending". This means that even if one marks a
function with "transferring", the compiler will guard it behind a
SendingArgsAndResults -D flag and in the imported header print out sending.
rdar://128216574
This now specifies a category name that’s used in TBDGen, IRGen, and PrintAsClang. There are also now category name conflict diagnostics; these subsume some @implementation diagnostics.
(It turns out there was already a check for @objc(CustomName) to make sure it wasn’t a selector!)
Several offsetting bugs both broke the caching of `ObjCInterfaceAndImplementationRequest` and caused it to usually miss. Fix this whole painful mess. Also has collateral improvements to simple_display().
We still only parse transferring... but this sets us up for adding the new
'sending' syntax by first validating that this internal change does not mess up
the current transferring impl since we want both to keep working for now.
rdar://128216574
We haven't yet solved the underlying issue in rdar://128013193 and the
workaround to make it conditionally use the better importing strategy of
Unsafe{Mutable}Pointer no longer will apply, since NoncopyableGenerics
is here.
We do iterate into extern C declarations when building the Swift lookup table during PCH generation.
0fad799f51/lib/ClangImporter/SwiftLookupTable.cpp (L2140-L2146)
However, we don’t import `extern "C"` declarations while parsing the bridging header (eg. when no `-pch-output-dir` is specified during code completion). This caused us to miss functions annotated as `extern "C"` in code completion.
rdar://127512985
