This causes problems for cross-compilation -parse-stdlib tests that
emit debug info. At the moment we have zero of those, but we're
trying to add one.
Also, don't try to load new modules when recording imports. (This
isn't harmful, just inefficient.)
Introduce some metaprogramming of accessors and generally prepare
for storing less-structured accessor lists.
NFC except for a change to the serialization format.
instead of using name and decl context.
The advantages of this approach are three-fold:
- This is necessary to support inlined generic functions.
- We can retire the debugger-specific type name manfgling mode for archetypes.
- This saves 270kb of debug information in the x86_64 libSwiftCore.dylib alone.
<rdar://problem/38306256>
Upstream has renamed the DEBUG() macro to LLVM_DEBUG. This updates swift
accordingly:
$ find . -name \*.cpp -print -exec sed -i "" -E "s/ DEBUG\(/ LLVM_DEBUG(/g" {} \;
In the majority of the use-cases transparent functions are inlined by
the mandatory inliner which by design drops all debug info and
pretends the inlined instructions were always part of the
caller. Since an outlined copy of the function is often still
generated, attaching debug locations to it is inconsistent and can
create the false impression that it were possible to set a breakpoint
in such a function when in reality these functions are only there for
very few edge cases.
<rdar://problem/40258813>
Note that this is only correct unless the variable uses inline
storage. This makes the majority of resilient types in Foundation work
as global variables. The correct solution would be for LLDB to poke
at the runtime to figure out whether the storage is inline or not, but
until then this is the next best thing.
rdar://problem/39722386
Introduce a new Type node, BoundNameAliasType, which describes a
reference to a typealias that requires substitutions to produce the
underlying type. This new type node is used both for references to
generic typealiases and for references to (non-generic) typealiases
that occur within generic contexts, e.g., Array<Int>.Element.
At present, the new type node is mainly useful in preserving type
sugar for diagnostics purposes, as well as being reflected in other
tools (indexing, code completion, etc.). The intent is to completely
replace NameAliasType in the future.
For the majority of artificial helper functions the filename is
actively misleading since it usually represents the file of the caller
that triggered the helper to be generated. Instead, this patch creates
a virtual filname `<compiler-generated>` to make it very obvious that
the function has not correspondence to any source code.
<rdar://problem/33809560>
This has three principal advantages:
- It gives some additional type-safety when working
with known accessors.
- It makes it significantly easier to test whether a declaration
is an accessor and encourages the use of a common idiom.
- It saves a small amount of memory in both FuncDecl and its
serialized form.
1) Move existing SyntaxSugarTypes under a new subclass called UnarySyntaxSugarType.
2) Make DictionaryType subclass SyntaxSugarType.
This helps improve getDesugaredType() performance by ensuring that
ImplOrContext is stored at the same field offset in memory.
This also de-boilerplates some AST walking.
Switch statements generate at least one anonymous match variable per
case, which consumes both a lot of stack space and an explosion of
range extension depencies due to the way case statements are scoped.
rdar://problem/34326355
LLVM r313825 replaced llvm::FindAllocaDbgDeclare with FindDbgAddrUses,
and we also need to include LLVM's IntrinsicInst.h header now.
rdar://problem/34574938
(cherry picked from commit 6b446a0d38)
This commit is mostly refactoring.
*) Introduce a new OptimizationMode enum and use that in SILOptions and IRGenOptions
*) Allow the optimization mode also be specified for specific SILFunctions. This is not used in this commit yet and thus still a NFC.
Also, fixes a minor bug: we didn’t run mandatory IRGen passes for functions with @_semantics("optimize.sil.never")
