The main point of this change is to make sure that a shared function always has a body: both, in the optimizer pipeline and in the swiftmodule file.
This is important because the compiler always needs to emit code for a shared function. Shared functions cannot be referenced from outside the module.
In several corner cases we missed to maintain this invariant which resulted in unresolved-symbol linker errors.
As side-effect of this change we can drop the shared_external SIL linkage and the IsSerializable flag, which simplifies the serialization and linkage concept.
This follows the design of how we handled this with
sil-verify-all. Specifically, the default behavior is to run only in asserts
builds, but one can use the two flags: enable-ast-verifier and
disable-ast-verifier to override the default behavior.
The reason why this is interesting is that this means that when compiling
normally, we will not run the verifier, so we won't have a perf hit. But we can
now ask the user to run with this flag (or in a future maybe a re-run in the
driver would do this for them), saving us time when screening bugs by avoiding
the need to build an asserts compiler to triage if the ASTVerifier would catch
the bug.
Fix use-after-free in helper function `printSILFunctionNameAndType`.
The address of a `DenseMap` local variable is used after the function returns.
Resolves SR-12239.
Instead of interleaving typechecking and parsing
for SIL files, first parse the file for Swift
decls by skipping over any intermixed SIL decls.
Then we can perform type checking, and finally SIL
parsing where we now skip over Swift decls.
This is an intermediate step to requestifying the
parsing of a source file for its Swift decls.
Being part of the type of a private declaration isn't sufficient,
because that could be used for the inferred type of a non-private
variable/constant/property.
Also, introduce a new kind of dependency test that shows both that a
file A changes its interface based on a change in another file B, and
that the swiftdeps output for file A includes the dependency on file B
as cascading.
https://bugs.swift.org/browse/SR-6149
introduce a common superclass, SILNode.
This is in preparation for allowing instructions to have multiple
results. It is also a somewhat more elegant representation for
instructions that have zero results. Instructions that are known
to have exactly one result inherit from a class, SingleValueInstruction,
that subclasses both ValueBase and SILInstruction. Some care must be
taken when working with SILNode pointers and testing for equality;
please see the comment on SILNode for more information.
A number of SIL passes needed to be updated in order to handle this
new distinction between SIL values and SIL instructions.
Note that the SIL parser is now stricter about not trying to assign
a result value from an instruction (like 'return' or 'strong_retain')
that does not produce any.
I don't have reduced test cases. The original test cases
were a series of frontend invocations in -parse-stdlib
mode.
While the original bugs seem to have been fixed, while
verifying I found a few places where we weren't checking
for null decls property in the ASTContext.
Probably not too useful to check this in, but I don't see it
causing any harm, either.
All we need to store is whether the SILDeclRef directly
references the declaration, or if it references a curry
thunk, and we already have an isCurried bit for that.
Previously we had more ad hoc logic that tried to decide if it was
worth desugaring a type based on its structure. Now we instead look
for a typealias that might actually benefit from desugaring, and if
we don't find one we won't show the 'aka' note.
The existence of a shared_external function in itself is not
an error; it just means we deserialized a witness table or
vtable but did not need to deserialize a thunk.
However, a direct reference to such a function is an error,
because we should have deserialized the body in that case.
This fixes a crasher, but the SIL crashers are kind of silly
because the SIL parser does not try at all not to crash on
invalid input.
Currently if destination is unresolved instead of trying to re-typecheck
it again and diagnose structural problems which led to such outcome, it
gets completely ignored in favor of trying to type-check source without
contextual type. That leads to missed diagnostic opportunities, which
results in problems on AST verification and SIL generation stages, and
generally missleading errors e.g. `.x = 0`.
Resolves: SR-3506.
- In functions called from resolveType(), consistently
use a Type() return value to indicate 'unsatisfied
dependency', and ErrorType to indicate failure.
- Plumb the unsatisfiedDependency callback through the
resolution of the arguments of BoundGenericTypes, and
also pass down the options.
- Before doing a conformance check on the argument of a
BoundGenericType, kick off a TypeCheckSuperclass request
if the type in question is a class. This ensures we don't
recurse through NominalTypeDecl::prepareConformanceTable(),
which wants to see a class with a valid superclass.
- The ResolveTypeOfDecl request was assuming that
the request was satisfied after calling validateDecl().
This is not the case when the ITC is invoked from a
recursive call to validateDecl(), hack this up by returning
*true* from isResolveTypeDeclSatisfied(); otherwise we
assert in satisfy(), and we can't make forward progress
in this case anyway.
- Fix a bug in cycle breaking; it seems if we don't invoke
the cycle break callback on all pending requests, we end
up looping forever in an outer call to satisfy().
- Remove unused TR_GlobalTypeAlias option.
Use a syntax that declares the layout's generic parameters and fields,
followed by the generic arguments to apply to the layout:
{ var Int, let String } // A concrete box layout with a mutable Int
// and immutable String field
<T, U> { var T, let U } <Int, String> // A generic box layout,
// applied to Int and String
// arguments
When a generic parameter list fails to parse, we don't call
DeclContext::setGenericParams(), even though the generic
parameters are still available for name lookup.
This causes various crashes, which this patch fixes by
mapping the generic parameters to ErrorTypes.
Use tok::NUM_TOKENS instead. tok::unknown can easily appear in source code.
For instance `skipUntil(tok::eof)` did not work as expected, because that was
`skipUntil(tok::eof, tok::unknown)` hence does stop at error tokens such as
`0xG` (invalid hex number literal).
Revert 2abc92bbb5, since that was
accidental side-effect of 45118037cc.
Forward references are not allowed actually.
SIL already does this where necessary, except with foreign throwing
functions; this patch changes Sema and the ClangImporter to give
them an ObjCBool foreign error result type explicitly.
This fixes a problem where calls to functions taking and returning
the C99 _Bool type were miscompiled on Mac OS X x86-64, because
IRGen was conflating the Objective-C BOOL type (which is a signed
char on some platforms) and C99 _Bool (which lowers as the LLVM
i1 type).
Fixes <rdar://problem/26506458> and <rdar://problem/27365520>.
make sure skipUntilGreaterInTypeList return a valid location even in the case
of parse errors. This ensures that we form a valid source range. Also,
improve parseExprIdentifier() to handle the case when skipUntilGreaterInTypeList
returns an empty archetype argument list. This fixes a couple of compiler
crashers.
