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.
The availability macros definitions are parsed from the command line and
stored in a cache. The cache was in the Parser, which would have it be
computed for each file using availability macros. Let's move it to the
ASTContext instead where it can generally be computed once per invocation
and used across the module.
rdar://134797088
Use IncludeTreeFileList instead of full feature CASFS for swift
dependency filesystem. This allows smaller CAS based VFS that is smaller
and faster. This is enabled by the CAS enabled compilation does not
need to iterate file system.
rdar://136787368
With the upcoming `MemberImportVisibility` feature enabled, code built with Cxx
interop also enabled could be rejected by the compiler with cryptic errors
about the `__ObjC` module not being imported. This is the result of a
surprising implementation detail of Cxx interop. When importing C++ namespaces
and their members, the Clang importer puts these declarations in the Clang
header import module (a.k.a. the bridging header module, `__ObjC`). C++
namespaces don't have a logical modular home in the Swift AST because they can
span multiple modules, so it's understandable why this implementation was
chosen. However, the concrete members of namespaces also get placed in the
`__ObjC` module too, and this really confuses things.
To work around this idiosyncrasy of Cxx interop, I've introduced
`Decl::getModuleContextForNameLookup()` which returns the module that a
declaration would ideally belong to if Cxx interop didn't have this behavior.
This alternative to `Decl::getModuleContext()` is now used everywhere that
`MemberImportVisibility` rules are enforced to provide consistency.
Additionally, I found that I also had to further special-case the header import
module for Cxx interop because it turns out that there are some additional
declarations, beyond imported namespaces, that also live there and need to be
implicitly visible in every source file. The `__ObjC` module is not implicitly
imported in source files when Cxx interop is enabled, so these declarations are
not deemed visible under normal name lookup rules. When I tried to add an
implicit import of `__ObjC` when Cxx interop is enabled, it broke a bunch
tests. So for now, when a decl really belongs to the `__ObjC` module in Cxx
interop mode, we just always allow it to be referenced.
This Cxx interop behavior really needs a re-think in my opinion, but that will
require larger discussions.
Resolves rdar://136600598.
Make sure block-list file is read through VFS so CASFS can be used to
read the configuration to ensure sound caching, and also the path of the
blocklist can be canonicalized via path remapping.
And move a couple of StorageImplInfo member functions into it. In
preparation for making them use an ASTContext, to avoid importing that
header into StorageImpl.h, a lightweight header.
When the frontend option `-abi-comments-in-module-interface` is provided
during interface printing, the printed interface will contain
additional comments that provide the mangled names for public symbols.
This is an experiment in seeing how much information we can
meaningfully extract from a printed Swift interface for the purpose of
bridging with other languages.
The main change here is to associate a witness table with a `ProtocolConformance` instead of a `RootProtocolConformance`.
A `ProtocolConformance` is the base class and can be a `RootProtocolConformance` or a `SpecializedProtocolConformance`.
