The crash on `SILFunction type mismatch` provides little information and
tends to be difficult to reproduce. Let's print some of the available
information and distinguish the two failure sites.
I'm not confident all required information is written down so we may
need to improve this further in the future. This version still crashes
the compiler, we may want a proper type-check to prevent this failure
with a clean diagnostic for the example used here.
rdar://53821031
When `-unavailable-decl-optimization=stub` is specified, insert a call to
`_diagnoseUnavailableCodeReached()` at the beginning of the function to cause
it to trap if executed at run time.
Part of rdar://107388493
We were not type checking the default argument initializer because `MacroDecl` is not an `AbstractFucntionDecl`. Add `MacroDecl` to the list of nodes we know how to get parameters from.
rdar://108163564
The substituon map might contain proper specialization (e.g. t_0_0 -> Double) that is required to fully specify a derivate type (e.g. during reabstraction conversion from fully specified function type to a substituted one)
Fixes#65073
to work with aggregates containing unknown values. Such aggregates
can be generated when an instruction is skipped during constant
evaluation and its results are used to create a struct.
To work around a build failure on MSVC,
f53e88b25b changed what was stored in the
verifier’s worklist from a `TaggedEnum<ValueDecl *, unsigned>` to two
fields `ValueDecl *` and `Optional<unsigned>` with the idea that only
one should ever be non-none. That change failed, however, to return the
_optional_ unsigned index represented by the value in the worklist,
instead returning the actual value. That’s a problem because the
worklist can’t contain `Optional<unsigned>` but only unsigned with
`UINT_MAX` indicating "none".
rdar://107709069
SIL symbol visitation wasn't visiting top-level auxiliary declarations,
which meant that it skipped peer and freestanding macros at module
scope. This would manifest in errors of the form
<symbol> is in the generated IR file, but not in TBD file
Fixes rdar://107426276.
This patch replaces the stateful generation of SILScope information in
SILGenFunction with data derived from the ASTScope hierarchy, which should be
100% in sync with the scopes needed for local variables. The goal is to
eliminate the surprising effects that the stack of cleanup operations can have
on the current state of SILBuilder leading to a fully deterministic (in the
sense of: predictible by a human) association of SILDebugScopes with
SILInstructions. The patch also eliminates the need to many workarounds. There
are still some accomodations for several Sema transformation passes such as
ResultBuilders, which don't correctly update the source locations when moving
around nodes. If these were implemented as macros, this problem would disappear.
This necessary rewrite of the macro scope handling included in this patch also
adds proper support nested macro expansions.
This fixes
rdar://88274783
and either fixes or at least partially addresses the following:
rdar://89252827
rdar://105186946
rdar://105757810
rdar://105997826
rdar://105102288
This is used to teach the checker that the thing being checked is supposed to be
uninitialized at the mark_must_check point so that we don't put a destroy_addr
there.
The way this is implemented is that we always initially add
assignable_but_not_consumable but in DI once we discover that the assign we are
guarding is an init, we convert the assignable to its initable variant.
rdar://106525988
In asserts builds, the lexicality of packs is verified via an
alternative code-path that walks into aggregates. That walk needs to
proceed through packs.
rdar://107283101
Substitution of a pack expansion type may now produce a pack type.
We immediately expand that pack when transforming a tuple, a function
parameter, or a pack.
I had to duplicate the component-wise transformation logic in the
simplifyType transform, which I'm not pleased about, but a little
code duplication seemed a lot better than trying to unify the code
in two very different places.
I think we're very close to being able to assert that pack expansion
shapes are either pack archetypes or pack parameters; unfortunately,
the pack matchers intentionally produce expansions of packs, and I
didn't want to add that to an already-large patch.
This change aims at reducing the need for SIL passes to check into the AST
storage of SILLocations. The end goal is to eventually merge this with the
autogenerated flag, but at the moment the emergent semantics of both properties
are not identical.
The pointsToEnd flag is only meaningful when combined with an AST node, and
moving it into the AST pointer frees up a bit in the flags bitfield for later
use.
needs to be lowered, use an opaque abstraction pattern.
As I argue in the comment, we know that the orig type is now either
an opaque type or a type with high-level structure that is invariant
to lowering. Substitution will not change the latter property, and
an opaque abstraction pattern is correct for the former. Attempting
to create a "truer" abstraction pattern that preserves more structure
from the orig type is both pointless and problematic. The
substitutions we just did may have replaced pack references with
non-pack types if there are active expansions in progress; this cannot
be easily explained in terms of substitutions. (In theory, we could
pass a more opaque concept of substitutions through AbstractionPattern,
which might help with this. That would also make it harder to catch
bugs with signature mismatches, though.)
whichever case it happens to be in.
This is a basic fix so that parallel walks on tuples and function
types in the substituted type will work . Separately, though, I
do not think the places that use this really need to be passed an
orig type; this is used for computing type properties, and I am
not aware of any reason we should need an orig type to compute
type properties. Additionally, the orig types computed by this
function are not really correct because of the substitution being
done in some cases, so it'd be very nice to rip this all out.
I'm not good to look into that right now, though.
