Usually debug info only ever describes the *result* of a projectBox
call. To display a boxed parameter of an async continuation object,
however, the debug info can only describe the box itself and thus also
needs to emit a box type for it so the debugger knows to call into
Remote Mirrors to unbox the value.
SR-14059
rdar://problem/73358988
My goal was to reduce the size of SILLocation. It now contains only of a storage union, which is basically a pointer and a bitfield containing the Kind, StorageKind and flags. By far, most locations are only single pointers to an AST node. For the few cases where more data needs to be stored, this data is allocated separately: with the SILModule's bump pointer allocator.
While working on this, I couldn't resist to do a major refactoring to simplify the code:
* removed unused stuff
* The term "DebugLoc" was used for 3 completely different things:
- for `struct SILLocation::DebugLoc` -> renamed it to `FilePosition`
- for `hasDebugLoc()`/`getDebugSourceLoc()` -> renamed it to `hasASTNodeForDebugging()`/`getSourceLocForDebugging()`
- for `class SILDebugLocation` -> kept it as it is (though, `SILScopedLocation` would be a better name, IMO)
* made SILLocation more "functional", i.e. replaced some setters with corresponding constructors
* replaced the hand-written bitfield `KindData` with C bitfields
* updated and improved comments
Previously, the name of the entry point function was always main. Here,
a new frontend flag is added to enable an arbitrary name to be
specified.
rdar://58275758
The generic signature isn't used for a whole lot, so this all mostly
worked before; the test case I have hits the code path for mangling
a retroactive conformance.
Fixes <https://bugs.swift.org/browse/SR-14016> / <rdar://problem/72865083>.
Since these types have an implicit stored property, this requires
adding an abstraction over fields to IRGen, at least throughout
the class code. In some ways I think this significantly improves
the code, especially in how we approach missing members.
Fixes rdar://72202671.
This commit depends on changes to the coroutine-splitting pass in LLVM. Shadow
copies are also turned off for async function arguments, because they make it
impossible to track debug info during coroutine splitting. Instead we are
relying on LLVM's CoroSplit.cpp to emit shadow copies. The Swift frontend gives
CoroSplit license to move do this by describing the arguments using a
dbg.declare intrinsic, even though it points to chain of load/GEP/bitcase
instructions into the Swift context function argument.
rdar://71866936
To help consolidate our various types describing imports, this commit moves the following types and methods to Import.h:
* ImplicitImports
* ImplicitStdlibKind
* ImplicitImportInfo
* ModuleDecl::ImportedModule
* ModuleDecl::OrderImportedModules (as ImportedModule::Order)
* ModuleDecl::removeDuplicateImports() (as ImportedModule::removeDuplicates())
* SourceFile::ImportFlags
* SourceFile::ImportOptions
* SourceFile::ImportedModuleDesc
This commit is large and intentionally kept mechanical—nothing interesting to see here.
This patch includes a large number of changes to make sure that:
1. When ExtInfo values are created, we store a ClangTypeInfo if applicable.
2. We reduce dependence on storing SIL representations in ASTExtInfo values.
3. Reduce places where we sloppily create ASTExtInfo values which should
store a Clang type but don't. In certain places, this is unavoidable;
see [NOTE: ExtInfo-Clang-type-invariant].
Ideally, we would check that the appropriate SILExtInfo does always store
a ClangTypeInfo. However, the presence of the HasClangFunctionTypes option
means that we would need to condition that assertion based on a dynamic check.
Plumbing the setting down to SILExtInfoBuilder's checkInvariants would be too
much work. So we weaken the check for now; we should strengthen it once we
"turn on" HasClangFunctionTypes and remove the dynamic feature switch.
To avoid ambiguity, ImportResolution and a few other things used the term “decl path” instead of “access path”. Switch back to the correct terminology now that the compiler is becoming more consistent about it.
Instead of using `UnresolvedType` as a placeholder for a type hole,
let's switch over to a dedicated "rich" `HoleType` which is capable
of storing "originator" type - type variable or dependent member
type which couldn't be resolved.
This makes it easier for the solver to determine origins of
a hole which helps to diagnose certain problems better. It also
helps code completion to locate "expected type" of the context
even when it couldn't be completely resolved.
When we try to emit debug info from C++ types we crash because we can't deserialize them. This is a temporary fix to circumnavigate the crash before a real fix can be created.
* Apply -debug-prefix-map to isysroot
Previously the absolute path to the sysroot, which could differ across
machines in remote build scenarios, was included in the debug info of
object files:
```
!11 = distinct !DICompileUnit(language: DW_LANG_Swift, file: !12, producer: "Swift version 5.3-dev (LLVM 93caf26adb68d37, Swift 58b2ddc65afbd60)", isOptimized: false, runtimeVersion: 5, emissionKind: FullDebug, enums: !13, imports: !14, sysroot: "/Applications/Xcode-11.5.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk", sdk: "MacOSX.sdk")
```
With this change these are included in the remapping done by
`-debug-prefix-map`.
* Fix test
This makes it easier to specify OptionSet arguments.
Also modify appropriate uses of ModuleDecl::ImportFilter to take
advantage of the new constructor.
These line numbers are consumed by LLDB and stored in the Declaration object,
but as far as I can tell no user-facing feature relies on this.
Removing the line number can reduce the churn for incremental builds
significantly, since whitespace changes in one file may trigger a recompilation
of any file that uses a type declared below the whitespace change.
<rdar://problem/63156560>
This became necessary after recent function type changes that keep
substituted generic function types abstract even after substitution to
correctly handle automatic opaque result type substitution.
Instead of performing the opaque result type substitution as part of
substituting the generic args the underlying type will now be reified as
part of looking at the parameter/return types which happens as part of
the function convention apis.
rdar://62560867
