If possible, add imported members to the StructDecl's LookupTable rather than adding them directly as members. This will fix the issues with ordering that #39436 poorly attempted to solve during IRGen.
This also allows us to break out most of the test changes from #39436.
A non functional change replacing auto with
Decl* for some declarations using ClangImporter::Implementation::importDecl.
Increases clarity and makes subsequent planned changes easier.
The Swift runtime and the concurrency module both use -mcx16, so there seems to be little point in not enabling it for Swift code in general.
This allows packages like swift-atomics to rely on double wide atomics always being available.
https://bugs.swift.org/browse/SR-13781
Note: we only lazily load the result if it's a record, because otherwise it's trivial to load when importing the function. Also, we still eagerly import operator's results types.
This change makes ClangImporter import some C++ member functions as non-mutating, given that they satisfy two requirements:
* the function itself is marked as `const`
* the parent struct doesn't contain any `mutable` members
`get` accessors of subscript operators are now also imported as non-mutating if the C++ `operator[]` satisfies the requirements above.
Fixes SR-12795.
Previously a namespace declaration was imported along with all of its redeclarations, and their members were added to a single Swift extension. This was problematic when a single namespace is declared in multiple modules – the extension belonged to only one of them.
For an example of this, try printing a module interface for `std.string`/`std.iosfwd` – it will be empty, even though the declarations from those modules are actually imported into Swift correctly.
This change makes sure that when we're importing different redeclarations of the same namespace, we're adding them as separate extensions to appropriate modules.
Pass a wrapped VFS down into `clang::createInvocationFromCommandLine` so
that the working directory is set and then used in the underlying Clang
`CompilerInstance`.
Fixes the possibility of differing modules hashes when the same
arguments are used in Clang directly vs from the importer.
Resolves rdar://79376364
Before this change, we always use the Swift target triple to instantiate the internal
Clang instance. When loading a Swift module from the textual interface, we may pick up
a lower target triple to use to build the Swift module because the target is hard-coded
in the textual interface file. This implies we may end up building multiple versions of the
same Clang module, one for each target triple of the loading Swift module.
This change adds a new frontend flag -clang-target to allow clients to specify a
consistent clang target to use across the Swift module boundaries. This value won't change
because it's not part of .swiftinterface files.
swift-driver should pass down -clang-target for each frontend invocation, and its value should be
identical to -target.
Related to: rdar://72480261
If there is a `-fmodule-map-file` argument whose file doesn’t exist and SwiftShims is not in the module cache, we fail to build it, because clang throws an error about the missing module map. This causes SourceKit to drop all semantic functionality, even if the missing module map isn’t required.
To work around this, drop all `-fmodule-map-file` arguments with missing files from the clang importer’s arguments, reporting the eror that `clang` would throw manually.
Fixes rdar://77449671
Project versions are embedded in the .tbd files of Clang frameworks. This patch teaches the compiler
to check the desired version specified in `canImport` against the project version in .tbd file. The
condition returns true if the Clang module on disk has a version number greater or equal to the one from `canImport`
condition; it returns false otherwise.
Part of rdar://73992299
canImport should be able to take an additional parameter labeled by either version or
underlyingVersion. We need underlyingVersion for clang modules with Swift overlays because they
have separate version numbers. The library users are usually interested in checking the importability
of the underlying clang module instead of its Swift overlay.
Part of rdar://73992299
Commit the platform definition and build script work necessary to
cross-compile for arm64_32.
arm64_32 is a variant of AARCH64 that supports an ILP32 architecture.
The diagnostics system doesn't allow a diagnostic to be emitted while
another diagnostic is in flight. Doing so will cause an assertion in
the diagnostics machinery.
There's a longstanding cycle here when diagnostics emission
pretty-prints declarations that are imported from a Clang module, and
the Clang Importer emits a diagnostic. Squash this cycle forcefully,
dropping the diagnostic that the Clang importer would emit.
A change in the new clang branch seems to have caused it to start applying SwiftNameAttrs to forward declarations. We have apparently always tried to add these forward declarations to the lookup tables in PCH files, but never diagnosed the resulting failures because they did not have SwiftNameAttrs. Now they do, so we started emitting incorrect warnings.
We *probably* don’t need to process these at all, but there’s a risk of unintended behavior changes from that; instead, this commit takes a conservative approach and simply suppresses the warnings like we always have.
Fixes rdar://74710976.
