Twine is non-owning and the lifetime of the result ends at the semicolon
here unless it is consumed into an owning abstraction. Convert to
a std::string first then insert that into the buffer here.
Not a big deal since this is along a catastrophic error path.
To smooth over an ABI transition, disable the standard substitutions
for the _Concurrency module within the AST mangler when the
_Concurrency module we are using predates custom executors. This is a
short-term hack that should be removed when we settle the ABI.
Addresses rdar://79298287.
If a conformance is found in an imported module as well as the current module,
and one of the two conformances is conditionally unavailable on the current
deployment target, pick the one that is always available.
Fixes <rdar://problem/78633800>.
Introduce a second level of standard substitutions to the mangling,
all of the form `Sc<character>`, and use it to provide standard
substitutions for most of the _Concurrency types.
This is a precursor to rdar://78269642 and a good mangling-size
optimization in its own right.
If the `-static` option is specified, store that in the generated
swiftmodule file. When de-serializing, recover this information in the
representative SILModule.
This will be used for code generation on Windows. It is the missing
piece to allow static linking to function properly. It additionally
opens the path to additional optimization on ELF-ish targets - GOT, PLT
references can be avoided when the linked module is known to be static.
Co-authored by: Saleem Abdulrasool <compnerd@compnerd.org>
The locations stored in .swiftsourceinfo included the presumed file,
line, and column. When a location is requested it would read these, open
the external file, create a line map, and find the offset corresponding
to that line/column.
The offset is known during serialization though, so output it as well to
avoid having to read the file and generate the line map.
Since the serialized location is returned from `Decl::getLoc()`, it
should not be the presumed location. Instead, also output the line
directives so that the presumed location can be built as per normal
locations.
Finally, move the cache out of `Decl` and into `ASTContext`, since very
few declarations will actually have their locations deserialized. Make
sure to actually write to that cache so it's used - the old cache was
never written to.
Cross-module incremental builds require a stable source of fingerprint
information for iterable decl contexts. This is provided by the
incremental frontends when they produce partial swift module files.
Embedded in these files is a table of fingerprints, which are consumed
by merge-modules to construct a module-wide dependency graph that is
then serialized into the final merged swift module file. Unfortunately,
the implementation here iterated through the files in the module and
asked for the first fingerprint that would load for a particular
iterable decl context. If (more likely, when) the DeclID for that
serialized iterable decl context collided with another DeclID in the
wrong file, we would load that fingerprint instead.
Locate up to the module-scope context for an iterable decl context and
only load the fingerprint from there. This ensures that the fingerprints
in the partial modules matches the fingerprints in the merged modules.
rdar://77005039
The start and end lines were only used while constructing the comments,
so move the line tracking into that method instead of storing it in each
comment.
Intro the concept of library access or distribution level to identify
layers of libraries and report public imports of private libraries from
public ones.
rdar://62934005
When requestifying the synthesis of the main function for the type
annotated @main via SynthesizeMainFunctionRequest, what were previously
were bailouts from AttributeChecker::visitMainTypeAttr had to become
returns of nullptr from SynthesizeMainFunctionRequest::evaluate.
Consequently, AttributeChecker::visitMainTypeAttr must check whether
synthesis actually succeeded before proceeding to to register the main
decl for a file.
In simple cases, this happened to work because
SourceFile::registerMainDecl would return early if the decl being
registered was the same as the already registered main decl and in
particular if the decl being registered was nullptr and the previously
registered one was nullptr as well. When, however, there are multiple
types annotated @main, if a function is successfully synthesized for one
type but synthesis fails for the second, an attempt will be made to
register nullptr as the main decl and will move past the check at the
beginning of SourceFile::registerMainDecl, resulting in a crash.
Here, we bail from AttributeChecker::visitMainTypeAttr if function
synthesis fails and add an assert to SourceFile::registerMainDecl that
the provided decl is non-null.
rdar://75547146
Using `-module-abi-name` for the `_Concurrency` module breaks older
Swift compilers. Instead, hard-code that "Swift" is the ABI name of the
"_Concurrency" module in the compiler to dodge the problem.
There is a known issue with module interfaces where a type with the same name as a module will disrupt references to types in that module. Fully fixing it will require a new language feature (SR-898) which is not yet available. In the meantime, module interfaces support a workaround flag (“-Xfrontend -module-interface-preserve-types-as-written”) which prints an alternate form that usually works. However, you have to know to add this flag, and it’s not obvious because nothing breaks until a compiler tries to consume the affected module interface (or sometimes even one of its clients).
This commit emits a warning during module interface emission whenever the module interface either imports a type with the same name as the module being built, or declares a type with the same name as a visible module. This lets the user know that the type may cause problems and they might need to implement a workaround.
If a function uses a type imported as implementationOnly (or similar), it cannot be serialized.
I added a new API in ModuleDecl (canBeUsedForCrossModuleOptimization), which performs this check.
rdar://72864719
When importing Clang types.
This is not an option with Explicit Module Builds. If the module being built does not (directly or transitively) depend on `Foundation`, then attempting to load it will produce an error because Implicit module loading is no longer allowed..
This change addresses a small number of cases where ClangImporter relies on being able to load `Foundation` on-demand:
- When importing a single Decl from a clang module, we check whether it has certain conformances by checking all extensions of the NominalTypeDecl of the Decl in question, to see if any of the extensions contain the conformance we are looking for, but we only check extensions whose parent module is either the original module of the NominalTypeDecl or the overlay module of the NominalTypeDecl or Foundation. It seems that we do not need to actually import `Foundation` here, just checking the module Identifier should be sufficient.
- In `maybeImportNSErrorOutParameter`, change the behavior to have an exit condition based on whether `Foundation` can be imported, before attempting to load it.
- When checking whether or not we are allowed to bridge an Objective-C type, it also looks sufficient the query whether or not `Foundation` *can* be imported, without loading it.
