When creating a skeleton Compile Unit, the DIFile passed
in, it always uses the include path. This leads to the DW_AT_comp_dir
being wrong, if the -file-compilation-dir option is passed, we need to
use the remapped compilation dir passed in to the DIFile instead.
This patch fixes that problem.
(cherry picked from commit b286b1c3a5)
* [CS] Decline to handle InlineArray in shrink
Previously we would try the contextual type `(<int>, <element>)`,
which is wrong. Given we want to eliminate shrink, let's just bail.
* [Sema] Sink `ValueMatchVisitor` into `applyUnboundGenericArguments`
Make sure it's called for sugar code paths too. Also let's just always
run it since it should be a pretty cheap check.
* [Sema] Diagnose passing integer to non-integer type parameter
This was previously missed, though would have been diagnosed later
as a requirement failure.
* [Parse] Split up `canParseType`
While here, address the FIXME in `canParseTypeSimpleOrComposition`
and only check to see if we can parse a type-simple, including
`each`, `some`, and `any` for better recovery.
* Introduce type sugar for InlineArray
Parse e.g `[3 x Int]` as type sugar for InlineArray. Gated behind
an experimental feature flag for now.
This reverts the problematic parts of
fcbebc51c7 which had caused a lot of
unintended fallout, while preserving the actual feature supported by
the patch.
Before that patch (fcbeb), and after this one, we don't emit members
of specialized bound generic types, because these can be reconstructed
by substituting the "template parameters" in the unspecialized
type. This patch carves out an exception for inline arrays, because
DWARF has special support for arrays, which allows debuggers to reason
about them without needing special support.
rdar://146326633
When creating an ExtendedASTNodeLoc from a SILLocation, if the
SILLocation passed in belongs to a swift::Stmt, we only ever use the
Stmt's StartLoc for the SourceLocation. If the SILLocation passed in,
has a SourceLocation that matches the EndLoc of the Stmt, we should
correctly set the primary ASTNodeTy PointerUnion's integer to 1, to
denote that the SourceLocation dervied from the Stmt points to the
EndLoc.
for recursive classes. This is achieved by treating types created with
DebugTypeInfo::createFrowardDecl() as unconditional forward
declarations when emitting debug info instead of applying a heuristic
to determine this.
rdar://146688269
This patch adds support for emitting the flag
llvm::DINode::FlagAllCallsDescribed when generating LLVM IR from the
Swift compiler to get call-site information for swift source code.
When emitting an LValue of a LoadExpr during SILGen, the Expression
passed as a SILLocation for the LValue was the parent LoadExpr instead
of the SubExpr that contains the LValue for the load. This leads to
the SILLocation to be marked as implicit, because a LoadExpr is always
an implicit expression.
An implicit SILLocation is not emitted when doing IRGen as it is
considered to be hidden from debug info and thus we lose the debug
location for the LValue of a LoadExpr.
This patch fixes this issue.
The option -sil-print-debuginfo-verbose will print the values of the
fields, implicit, and autoGenerated for a SILLocation, as well as
whether the SILLocation is considered hidden from debug information
by calling SILLocation::isHiddenFromDebugInfo()
This commit also changes how specialized types are being emitted. Previously we
would not emitthe detailed member information in the specialized type itself,
and instead rely on the fact that it was present in the unspecialized type,
however, this wold prevent us from emitting any bound generic members, so we're
now emitting the members in both variants of the type.
This uncovered a with type aliases that this commit also addresses: Because we
don't canonicalize types prior to caching in order to preserve type sugar,
alternative representations of recursive types (with one or more levels of
recursion unfolded) could create potential infinite chains of types. This is
addressed by checking whether a sugared type has an already emitted canonical
representation first, and if yes, creating a typedef node pointing directly to
it.
The donwside of doing this is that it can lead to the disappearnce of type
aliases definitions when they are used as parameters in bound generic
types. However, we still preserve that a type was `MyClass<MyAlias>`. We just
might have a typedef pointing director from `MyClass<MyAlias>` ->
`MyClass<CanonicalType>`.
rdar://144315592
PredictableMemoryAccessOptimizations has become unmaintainable as-is.
RedundantLoadElimination does (almost) the same thing as PredictableMemoryAccessOptimizations.
It's not as powerful but good enough because PredictableMemoryAccessOptimizations is actually only needed for promoting integer values for mandatory constant propagation.
And most importantly: RedundantLoadElimination does not insert additional copies which was a big problem in PredictableMemoryAccessOptimizations.
Fixes rdar://142814676
This relands commit 45d4648bdb while ensuring that
sanityCheckCachedType uses the exact same condition (now factored into a helper
function) as createType() to determine whether a type is sized or not.
rdar://143833326
We use the formal source type do decide whether a checked_cast_br is
known to succeed/fail. If we don't update it we loose that optimization
That is:
```
checked_cast_br AnyObject in %2 : X to X, bb1, bb2
```
Will not be simplified even though the operand and the destintation type
matches.
Debug Info generation already has a check to stop it from generating
debug info for a type with the same mangled name. However, most of the
code paths in debug info generation would not add the mangled name to
the cache while generation was not done. This patch fixes that so types
that are in-flight don't have their debug info generated twice.
rdar://142500619
Types with @_originallyDefinedIn cannot be round tripped,
Types declared inside functions have their mangling affected by the
function signature. If the generic signature mentions an
@_originallyDefinedIn type, the type inside the function cannot be round
tripped either.
This commit disables round tripping for this scenario.
Emit an imported declaration for @_originallyDefinedIn under the
real module that these types live in.
This patch also changes the mangling for the debugger to respect
@_originallyDefinedIn, and fixes a bug where @_originallyDefinedIn
that should be ignored was still being used when mangling.
rdar://137146961
This patch adds false positive detection to sil-stats-lost-variables.
We will now only detect a debug_value as lost if there is a real
instruction which belongs to the same scope or a child scope of the
scope of the debug_value and if they are both inline at the same
location.
//a
Type annotations for instruction operands are omitted, e.g.
```
%3 = struct $S(%1, %2)
```
Operand types are redundant anyway and were only used for sanity checking in the SIL parser.
But: operand types _are_ printed if the definition of the operand value was not printed yet.
This happens:
* if the block with the definition appears after the block where the operand's instruction is located
* if a block or instruction is printed in isolation, e.g. in a debugger
The old behavior can be restored with `-Xllvm -sil-print-types`.
This option is added to many existing test files which check for operand types in their check-lines.
A previous commit added a check for a store of `i32`, which would not
work for 32-bit targets. In order to avoid having multiple test, this
commit addresses the issue by requiring a 64-bit architecture for the
target. This follows the example of other async debug info tests.
Prior to this commit, when lowering SIL instructions that should are
"hidden" for the purposes of debugging, the compiler just attaches the
location of the previous instruction in the name of keeping a simpler
line table.
However, this is wrong for many reasons. One such reason is this: at the
start of a basic block, inheriting the previous debug location will
almost certainly cause the instruction to have a random location in the
code, as it will depend on whatever BB was visited previously.
Other examples can be seen in the tests affect by this commit, which
changes lowering to use Line 0 instead of the line number of the
previous instruction.
CodeView doesn't handle line 0 the same way DWARF does, so this commit
preserves the old behavior for the CodeView path.
The test changes here are effectively undoing some of the diffs from
158772c2ab.
rdar://139826231&110187845
