This reverts commit d27e6e1e46, reversing
changes made to f2e85a2b1f.
It causes an execution time failure in
`Interpreter/struct_extra_inhabitants.swift` with
```
ninja -C swift-macosx-x86_64 check-swift-optimize
```
rdar://86054209
The functions in llvm-project `AttributeList` have been
renamed/refactored to help remove uses of `AttributeList::*Index`.
Update to use these new functions where possible. There's one use of
`AttrIndex` remaining as `replaceAttributeTypeAtIndex` still takes the
index and there is no `param` equivalent. We could add one locally, but
presumably that will be added eventually.
This reverts commit 5ebb1b2fc6, reversing
changes made to 76260c2235.
This commit causes compiler crashes when using protocol composition
types involving objc.
Repo:
```
import Foundation
public class SomeObject : NSObject {}
public protocol ProtoA{}
public protocol SomeProtoType { }
public typealias Composition = SomeObject & SomeProtoType
public struct Thing<T: ProtoA> {
let a: Composition
let b: T
init(a: Composition,
b: T
) {
self.a = a
self.b = b
}
}
$ swiftc -c Repo.swift -O
```
While looking at this issue I noticed that it is not correct to use a
ScalarEntry of ObjCReference (or other ScalarKind::XXXReference) for
`AddressOnly##Name##ClassExistentialTypeInfo` types. These should be
calling the IGF.emit##Name##Destroy(addr, Refcounting); functions not
objc_release.
It is probably best to use the macro facilities in a similar fashion like
lib/IRGen/GenExistential.cpp does.
rdar://85269025
Summary:
As part of SR-14273, the type layout infrastructure needs to be able to be able
to differentiate between types of scalars so it knows how to release/retain
appropriately. Right now, for example, to destroy a scalar, it blindly calls
into typeInfo's irgen functions which means it's not able to generate any of
the needed information for itself.
This patch adds a field to ScalarTypeLayout to allow them to know what kind of
reference they are and strings through the machinery to provide the information
to set it.
This also moves ScalarTypeLayout::destroy to use the new information.
Test Plan: ninja check-swift
Reviewers: mren, #pika_compiler
Reviewed By: mren
Subscribers: apl, phabricatorlinter
Differential Revision: https://phabricator.intern.facebook.com/D30983093
Tasks: T100580959
Tags: swift-adoption
Signature: 30983093:1632340205:3bdd3218ae86ad6b3d199cc1b504a625e3650ec0
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
The majority of support comes in the form of emitting partial
application forwarders for partial applications of async functions.
Such a partial application forwarder must take an async context which
has been partially populated at the apply site. It is responsible for
populating it "the rest of the way". To do so, like sync partial
application forwarders, it takes a second argument, its context, from
which it pulls the additional arguments which were capture at
partial_apply time.
The size of the async context that is passed to the forwarder, however,
can't be known at the apply site by simply looking at the signature of
the function to be applied (not even by looking at the size associated
with the function in the special async function pointer constant which
will soon be emitted). The reason is that there are an unknown (at the
apply site) number of additional arguments which will be filled by the
partial apply forwarder (and in the case of repeated partial
applications, further filled in incrementally at each level). To enable
this, there will always be a heap object for thick async functions.
These heap objects will always store the size of the async context to be
allocated as their first element. (Note that it may be possible to
apply the same optimization that was applied for thick sync functions
where a single refcounted object could be used as the context; doing so,
however, must be made to interact properly with the async context size
stored in the heap object.)
To continue to allow promoting thin async functions to thick async
functions without incurring a thunk, at the apply site, a null-check
will be performed on the context pointer. If it is null, then the async
context size will be determined based on the signature. (When async
function pointers become pointers to a constant with a size i32 and a
relative address to the underlying function, the size will be read from
that constant.) When it is not-null, the size will be pulled from the
first field of the context (which will in that case be cast to
<{%swift.refcounted, i32}>).
To facilitate sharing code and preserving the original structure of
emitPartialApplicationForwarder (which weighed in at roughly 700 lines
prior to this change), a new small class hierarchy, descending from
PartialApplicationForwarderEmission has been added, with subclasses for
the sync and async case. The shuffling of arguments into and out of the
final explosion that was being performed in the synchronous case has
been preserved there, though the arguments are added and removed through
a number of methods on the superclass with more descriptive names. That
was necessary to enable the async class to handle these different
flavors of parameters correctly.
To get some initial test coverage, the preexisting
IRGen/partial_apply.sil and IRGen/partial_apply_forwarder.sil tests have
been duplicated into the async folder. Those tests cases within these
files which happened to have been crashing have each been extracted into
its own runnable test that both verifies that the compiler does not
crash and also that the partial application forwarder behaves correctly.
The FileChecks in these tests are extremely minimal, providing only
enough information to be sure that arguments are in fact squeezed into
an async context.
When the first element in the heap layout was non fixed we would use the
mininum size of the total heap layout for the initial offset. This would
create unneccessary large heap layouts.
rdar://61716736
Motivation: `GenericSignatureImpl::getCanonicalSignature` crashes for
`GenericSignature` with underlying `nullptr`. This led to verbose workarounds
when computing `CanGenericSignature` from `GenericSignature`.
Solution: `GenericSignature::getCanonicalSignature` is a wrapper around
`GenericSignatureImpl::getCanonicalSignature` that returns the canonical
signature, or `nullptr` if the underlying pointer is `nullptr`.
Rewrite all verbose workarounds using `GenericSignature::getCanonicalSignature`.
This mostly requires changing various entry points to pass around a
TypeConverter instead of a SILModule. I've left behind entry points
that take a SILModule for a few methods like SILType::subst() to
avoid creating even more churn.
box descriptors
We want to substitute opaque result types in addTypeRef but when we pass
SILFunctionTypes this would fail because AST type substitution does not
support lowered SIL types.
Instead add addLoweredTypeRef which substitutes based on SILTypes.
rdar://54529445
In too many places, we were calling into `emitDynamicTypeOfOpaqueHeapObject` even when we had
more specific type information about the heap object we were querying. Replace all calls with
`emitDynamicTypeOfHeapObject`, which uses the best available access path and completely avoids
runtime calls for pure Swift classes and heap objects. When targeting non-ObjC-interop platforms,
we also know we never need to call `swift_getObjectType`, so avoid doing so altogether.
This indicates that the "self" argument to the current function is always dynamically of the exact
static base class type, allowing metadata accesses in IRGen to use the local self metadata to answer
metadata requests for the class type. Set this attribute on allocating entry points of designated
inits, which is one of the most common places where we emit redundant metadata accesses.
Don't use the beginning of the basic block as insertion point if 'local
self' is an llvm::Instruction (i.e a cast from the argument llvm::Value
has been insterted) rather use the 'local self' value as insertion point.
Fixes a dominance issue because we inserted at the beginning of the
basic block.
rdar://51186963
An @objc convenience initializer can replace 'self'. Since IRGen
has no way to tell what the new 'self' value is from looking at
SIL, it always refers back to the original 'self' argument when
recovering DynamicSelfType metadata. This could cause a crash
if the metadata was used after the 'self' value had been
replaced.
To fix the crash, always insert the metadata recovery into the
entry block, where the 'self' value should be valid (even if
uninitialized, the 'isa' pointer should be correct).
Fixes <rdar://problem/50594689>.
This simplifies some boilerplate, and in particular, some SIL verifier
logic; and fixes a couple bugs related to always loadable reference
storage types.
At Odebug we print the full path to the file and in optimized mode no
file name will be included.
This mirrors what we do in Swift's asserts.
rdar://47880964
This silences the instances of the warning from Visual Studio about not all
codepaths returning a value. This makes the output more readable and less
likely to lose useful warnings. NFC.
This does the same thing as taking the AST type and running it through mapTypeOutOfContext, but
saves call sites from having to do the unwrap-rewrap dance.
These functions don't accept local variable heap memory, although the names make it sound like they work on anything. When you try, they mistakenly identify such things as ObjC objects, call through to the equivalent objc_* function, and crash confusingly. This adds Object to the name of each one to make it more clear what they accept.
rdar://problem/37285743
This allows us to layout-optimize Optional<T> when T is a struct with an
extra-inhabitant-bearing field anywhere in its definition, not only at
the beginning. rdar://problem/43019427
ClassDecl::getSuperclass() produces a complete interface type describing the
superclass of a class, including any generic arguments (for a generic type).
Most callers only need the referenced ClassDecl, which is (now) cheaper
to compute: switch those callers over to ClassDecl::getSuperclassDecl().
Fixes an existing test for SR-5993.
