Temporarily reverting @_specialize because stdlib unit tests are
failing on an internal branch during deserialization.
This reverts commit e2c43cfe14, reversing
changes made to 9078011f93.
This turns on the remote reflection metadata by default for swift
invocations and the standard library. The size delta for all of the
sections is:
Section __swift3_typeref: 20176
Section __swift3_reflstr: 2556
Section __swift3_fieldmd: 8172
Section __swift3_assocty: 18112
Recognizing that this is a nontrivial increase in binary size, we can
reduce this with a few methods:
- Trie for strings (typerefs and field names are both strings) but would
need an implementation
- Compress the entire sections: this would need an implementation
available on all platforms where we support the functionality.
- Don't use the AST mangler but a custom mangling, which may be slightly
more compact because it can specialize by need and maybe not include
some mangle nodes that typerefs don't need.
Value witness tables have a well-known symbol name, so there is nothing
that the debug info adds on top of it.
On top of that, the DWARF type we previously were emitting them with was
bogus.
rdar://problem/21777112
We were failing to find init() decls whenever there was more than one
candidate.
The mangled function type we get will be (args...) -> T, but the real
thing is (T.Type) -> (args...) -> T. Strip the metatype so we can match
successfully.
This change follows up on an idea from Michael (thanks!).
It enables debugging and profiling on SIL level, which is useful for compiler debugging.
There is a new frontend option -gsil which lets the compiler write a SIL file and generated debug info for it.
For details see docs/DebuggingTheCompiler.rst and the comments in SILDebugInfoGenerator.cpp.
Introduce a new SILPrintContext class which is the main handle passed to the SILModule's and SILFunction's print functions.
It also allows to let derived classes implement call backs on instruction printing.
NFC for now, but needed for the upcoming SIL-debuginfo change.
Generalized bridging has fully subsumed most of these. NSError is
still special, and _convertStringToNSString remains for the the
runtime's implementation of SwiftObject's -description method.
It is a common point of confusion that code like:
switch value {
case .Foo, .Bar where someNumber != 100:
Only applies the where clause to the second pattern, not every pattern in the case.
Resolve this by warning about the ambiguity, providing two notes (with fixits) that
resolve the issue in different ways:
t.swift:25:17: warning: 'where' only applies to the second pattern match in this case
case .Foo, .Bar where someNumber != 100:
~~~~ ^ ~~~~~~~~~~~~~~~~~
t.swift:25:12: note: disambiguate by adding a line break between them if this is desired
case .Foo, .Bar where someNumber != 100:
^
t.swift:25:6: note: duplicate the 'where' on both patterns to check both patterns
case .Foo, .Bar where someNumber != 100:
^~~~
where someNumber != 100
This pass finds generic functions with @_specialized attributes and
generates specialized code for the attribute's concrete types. It
inserts type checks and guarded dispatch at the beginning of the
generic function for each specialization. Since we don't currently
expose this attribute as API and don't specialize vtables and witness
tables yet, the only way to reach the specialized code is by calling
the generic function which performs the guarded dispatch.
In the future, we can build on this work in several ways:
- cross module dispatch directly to specialized code
- dynamic dispatch directly to specialized code
- automated specialization based on less specific hints
- partial specialization
- and so on...
I reorganized and refactored the optimizer's generic utilities to
support direct function specialization as opposed to apply
specialization.
Fix a crash in emitBuiltinCall() which occurs because we drop function
linkage information when creating SILCoverageMaps.
This re-applies 45c7e4e86 with the MachO-specific checks in the test
case removed.
We really only need the analysis to tell whether a function has caller
inside the module or not. We do not need to know the callsites.
Remove them for now to make the analysis more memory efficient.
Add a note to indicate it can be extended.
- Read the Parent pointer out of Class/Value metadata and create
typerefs for them.
- Add Parent fields to NominalTypeRef and BoundGenericTypeRef.
- Add TypeRef::getSubstMap(), which creates a new generic argument
map after substitution has taken place on it. This is used to
continue to burrow into nested value types, where generic type
parameters may have a different index.
- Use a DenseMap as that generic argument map.
- Unconditionally key the generic argument map with (Depth, Index)
- Clean up ordering and presentation of Index and Depth. In the rest
of the compiler, Depth comes before Index.
This attribute can be attached to generic functions. The attribute's
arguments must be a list of concrete types to be substituted in the
function's generic signature. Any number of specializations may be
associated with a generic function.
This attribute provides a hint to the compiler. At -O, the compiler
will generate the specified specializations and emit calls to the
specialized code in the original generic function guarded by type
checks.
The current attribute is designed to be an internal tool for
performance experimentation. It does not affect the language or
API. This work may be extended in the future to add user-visible
attributes that do provide API guarantees and/or direct dispatch to
specialized code.
This attribute works on any generic function: a freestanding function
with generic type parameters, a nongeneric method declared in a
generic class, a generic method in a nongeneric class or a generic
method in a generic class. A function's generic signature is a
concatenation of the generic context and the function's own generic
type parameters.
e.g.
struct S<T> {
var x: T
@_specialize(Int, Float)
mutating func exchangeSecond<U>(u: U, _ t: T) -> (U, T) {
x = t
return (u, x)
}
}
// Substitutes: <T, U> with <Int, Float> producing:
// S<Int>::exchangeSecond<Float>(u: Float, t: Int) -> (Float, Int)
With the exception of a specific whitelist of cases where the
Foundation module defines conformances to _ObjectiveCBridgeable for
standard library types, only permit an _ObjectiveCBridgeable
conformance in the same module as the type that's conforming to the
protocol. Among other things, this prevents the optimizer from
concluding that a dynamic cast between a Swift value type and its
bridged Objective-C class type can never succeed. See
34ff1c8e6d
for the optimizer issue. As part of this, bring the whitelist in sync
with reality, now that the compiler enforces it.
In 2e3c0b6, code was added to emit unique trap blocks for each
cond_fail, in order to make post-mortem debugging simpler (e.g. stack
traces have correct line/column information for the trapping location,
and it's easy to trace back to the specific jump that reaches the trap).
We didn't, however, do anything to ensure that LLVM wouldn't merge these
back together again. This is an attempt to do exactly that, after seeing
BranchFolding in the code generator merging traps into a single block.
The idea here is to emit empty inline asm strings marked as
side-effecting, and taking a unique integer argument. These come before
the trap call, so they should block any valid attempt at merging the
blocks back together.
Ideally trap would take an argument which uniquely identifies it, but
that isn't possible today.
This solution is potentially brittle in that in theory LLVM could still
merge the trap/unreachable and then branch to those after the unique asm
calls. We cannot fix that by putting another asm call after the trap,
because LLVM's CFG simplification will delete code after a trap.
rdar://problem/25216969
Let's say I am a good citizen and document my private symbols:
/** My TOP SECRET DOCUMENTATION */
private class Foo {
}
When I go to distribute the compiled binary, I find out my private
documentation is distributed as well:
$ swiftc test.swift -emit-module -module-name "test"
$ strings test.swiftdoc
My TOP SECRET DOCUMENTATION
/** My TOP SECRET DOCUMENTATION */
If a client can't use a symbol (e.g. it's private [or internal and not
-enable-testing]) don't emit the documentation for a symbol in the
swiftdoc.
Fixes: SR-762, rdar://21453624
The test coverage implements this truth table:
| visibility | -enable-testing | documentation? |
|------------|-----------------|----------------|
| private | no | ❌ |
| internal | no | ❌ |
| public | no | ✅ |
| private | yes | ❌ |
| internal | yes | ✅ |
| public | yes | ✅ |
Modified the existing comments test coverage to expect non-public
documentation not to be emitted.
Don't rely on existing comment structure
Refuse to emit comments if the decl cannot actually have one. To
accomplish this, we move `canHaveComment` into the Decl instance. It
must also be marked `const`, since one of its existing usages operates
on a const pointer.
Perform fewer checks when serializing the standard library.
Eliminate the String/Array/Dictionary/Set special cases, using
_ObjectiveCBridgeable conformances instead.
Note: Clang update required for the test to success.
SILGen's bridging logic was recognizing the various bridged types
(String/Array/Dictionary/Set) using ad-hoc logic, then jumping into
the generic, _ObjectiveCBridgeable-based bridging logic. Replace the
ad-hoc logic with an _ObjectiveCBridgeable conformance query.
SILGen still has Array/Dictionary/Set-specific hacks for collection
up/downcasting, but the bridging code is now generic.
Add an invalidateAnalysisForDeadFunction API. This API calls the invalidateAnalysis
by default unless overriden by analysis pass themselves. This API passes the extra
information that this function is dead and going to be removed from the module.
CallerAnalysis overrides this API and only invalidate caller/callee relations but
does not push this into the recompute list.
We also considered the possibility of keeping a computed list, instead of recompute
list but that would introduce a O(n^2) complexity as every time we try to complete
the computed list, we need to walk over all the functions that currently exist in the
module to make sure the computed list is complete.
I feel eventually we can do a handleDeleteNotification for function deletion and we
wont need the API added in this change.
It appears we were only using this to see if an associated type was
derived or defaulted. This code didn't mesh well with the other stuff
I was doing for default implementations, so I'd rather rip it out and
just rely on calling 'isImplicit' to check for derived associated
types instead.
Note that there's a small change of behavior -- if an associated type
is derived for one conformance, and then used as a witness in another,
we were previously only marking it as defaulted in the first one,
but now it is marked as defaulted in both. I do not believe this has
any meaningful consequences.
