Many clients of the conformance lookup operations would prefer to get
an invalid conformance (== there is no conformance) rather than a
missing conformance. Parameterize the conformance lookup operations so
that most callers won't see missing conformances, by filtering them
out at the end. Opt-in those callers that do want to see missing
conformances so they can be diagnosed.
When looking up a conformance to Sendable fails, implicitly create a
"missing" builtin conformance. Such conformances allow type checking
to continue even in the presence of Sendable-related problems.
Diagnose these missing conformances when they are used in an actual
program, as part of availability checking for conformances and when we
are determining Sendability. This allows us to decide between an
error, a warning, and suppressing the diagnostic entirely without
affecting how the program is compiled. This is a step toward enabling
selective enforcement of Sendable.
Part of rdar://78269348.
Add implement conformance of structural types to Sendable as appropriate:
* A tuple type is Sendable when its element types are Sendable
* A metatype type is Sendable
* A function type is Sendable if it is @Sendable, thin, or C
* A builtin type is always Sendable
Implements rdar://76836578.
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
