* Narrow allowance of 3+ components numeric literal to condition part of the
directive.
* Allow 3+ components in '#if' directive in decl list position as well.
When we're looking up all associated types with the same name in order
to find the right archetype anchor, skip extension members to avoid
circular deserialization.
Discovered while investigating <rdar://problem/30248571>.
Once we move to a copy-on-write implementation of existential value buffers we
can no longer consume or destroy values of an opened existential unless the
buffer is uniquely owned.
Therefore we need to track the allowed operation on opened values.
Add qualifiers "mutable_access" and "immutable_access" to open_existential_addr
instructions to indicate the allowed access to the opened value.
Once we move to a copy-on-write implementation, an "open_existential_addr
mutable_access" instruction will ensure unique ownership of the value buffer.
Temporarily loosen this test so I can cherry-pick an llvm fix that
throws away dead profile name variables. I will tighten it up again when
the llvm change lands.
While invoking the instrprof_increment intrinsic, we used to pass the
profile name variable by using a GEP instruction to get to the string
constant. That prevented llvm from uniquing the names. Use a constexpr
GEP to fix the issue.
There isn't a reason for it to be disabled.
It was disabled by this merge commit. I'll follow-up to see how we can
avoid this in the future.
commit 78b28243ff
Merge remote-tracking branch 'origin/master' into master-next
Or rather, when the name importer decides that the name it /would/
have should start with a number, and gives up. We should probably
fix that separately, but meanwhile don't crash.
> Roses are red
> Prefix-stripping can create an invalid remainder
> assert(!member->NextDecl &&
> "Already added to a container")
rdar://problem/30401506
It also uses the new mangling for type names in meta-data (except for top-level non-generic classes).
lldb has now support for new mangled metadata type names.
This reinstates commit 21ba292943.
In 74d979f0ac, the policy was changed
so that only value type accessors are ever marked transparent, and
not class accessors.
This was intended to fix a bug where inlining an accessor of an
Objective-C-derived class across module boundaries caused a linker
failure because the accessor referenced a field offset variable,
which has hidden visibility.
However, this also caused a performance regression for Swift native
classes. Bring back the old behavior for Swift native classes in
non-resilient modules.
Fixes <rdar://problem/29884727>.
This has the effect of propagating the search path to the clang importer as '-iframework'.
It doesn't affect whether a swift module is treated as system or not, this can be done as follow-up enhancement.
- Don't allow @_inlineable on stored properties; this generates
invalid SIL since clients can't know about stored properties of
resilient types. Accessors for stored properties of non-resilient
types are already @_inlineable anyway.
- Don't allow @_inlineable on declarations that are not public or
@_versioned, since it's simply redundant.
Use the generic type lowering algorithm described in
"docs/CallingConvention.rst#physical-lowering" to map from IRGen's explosion
type to the type expected by the ABI.
Change IRGen to use the swift calling convention (swiftcc) for native swift
functions.
Use the 'swiftself' attribute on self parameters and for closures contexts.
Use the 'swifterror' parameter for swift error parameters.
Change functions in the runtime that are called as native swift functions to use
the swift calling convention.
rdar://19978563
Rememebering that the verifier ensures that any edge that propagates ownership
along a cond_br can not be critical, we do this by sinking the use by the
cond_br into the destination blocks.
rdar://29791263
