ASTContexts
This introduces swift::ide::CodeCompletionCache, which is a persistent code
completion result cache.
Right now REPL happens to use it (try importing Cocoa and doing code
completion), and the difference is noticeable. But completion in REPL is
still slow, because Cocoa goes through the AST Verifier on every completion
(for unknown reasons).
This commit does not implement cache invalidation yet, and it does not use
libcache to evict cache entries under memory pressure.
This commit also introduces two regressions:
- We get fewer Cocoa results that expected. Module::isModuleVisible in Clang
does not incorrectly reports that that ObjectiveC.NSObject submodule is not
visible from Cocoa.
- We are not implementing the decl hiding rules correctly. We used to rely on
visible decl lookup to do it for us, but now we have a different data structure
we have real decls from the current module and we have a text-only cache, so we
are forced to reimplement this part of name lookup in code completion.
Swift SVN r9633
Once we've opened method references via the interface type, we then
fold all levels of generic argument specialization into the
DeclRefExpr, rather than using SpecializeExpr. For reference, the call
to x.f in this example:
struct X<T> {
func f<U>(u : U) { }
}
func honk(x: X<Int>) {
x.f("hello")
}
goes from this double-specialized AST:
(specialize_expr implicit type='(u: String) -> ()'
(with U = String)
(dot_syntax_call_expr type='<U> (u: U) -> ()'
(specialize_expr implicit
type='(@inout X<Int>) -> <U> (u: U) -> ()'
(with T = Int)
(declref_expr type='<T> @inout X<T> -> <U> (u: U) -> ()'
decl=t.X.f@t.swift:2:8 specialized=no))
to the cleaner, SpecalizeExpr-free:
(dot_syntax_call_expr type='(u: String) -> ()'
(declref_expr type='(@inout X<Int>) -> (u: String) -> ()'
decl=t.X.f@t.swift:2:8 [with T=Int, U=String]
specialized=no)
which handles substitutions at both levels together. The minor SILGen
tweak
Note that there are numerous other places where we are still generated
SpecializeExprs.
Swift SVN r9614
When we're checking the signature of a generic function, we want
references to elements within an enclosing DeclContext (such as an
unspecialized reference to an enclosing generic class or a reference
to a typealias of a generic class) to involve generic parameters
rather than archetypes. Elsewhere, we want the
archetypes. GenericTypeResolver is responsible for handling this
distinction.
Swift SVN r9563
Replace DeclRefExpr's stored ValueDecl* with a ConcreteDeclRef,
allowing it to store the complete set of substitutions applied to
the declaration. Start storing those substitutions (without using them
yet).
Swift SVN r9535
Value witness markers note the location within a generic function
type's list of requirements where the value witness table will be
placed when calling a generic function with that type. It allows one
to get the same effect from walking the requirements of a generic
function that one would get from walking all levels of a
GenericParamList, with all archetypes of each generic parameter list,
along with all of the protocols to which each archetype conforms,
which SILGen and IRGen both do.
AST verification ensures that the property above holds; we're not
making use of it just yet.
Swift SVN r9509
When the type checker sees a reference to a generic non-member
function, open its interface type, which is expressed as a
GenericFunctionType, rather than its PolymorphicFunctionType. This is
a tiny step toward weaning the type checker off archetypes within the
interface.
Swift SVN r9504
The list of requirements within a generic function type is
functionally identical to the list of conformances in the list of "all
archetypes" that a given function carries. Synchronize these lists so
they have identical requirements in the same order, which allows us to
substitute the former for the latter.
Swift SVN r9472
Allows us to properly infer the type (Int, Int)[] from the array
literal [(1, 2)]. This is the last piece of functionality in
<rdar://problem/11293232>.
Swift SVN r9408
(This only fails under -DSWIFT_OPTIMIZED=NO; most likely due to an llvm bug.)
We've decided that it's best to specialize each arithmetic builtin that could overflow, instead of calling a separate generic "staticReport" builtin and passing it enough info to produce the message. The main advantage of this approach is that it would be possible for the compiler to customize the message and better link it to the builtin that overflows. For example, the constants that participated in the computation could be printed. In addition, less code will be generated and the compiler could, in the future, automatically emit the overflow diagnostics/trap at runtime.
This patch introduces new versions of op_with_overflow swift builtins. Which are lowered to llvm.op_with_overflow builtins in IRGen after the static diagnostics. If the last argument to the builtins evaluates to true, the overflow is unintentional. CCP uses the builtins to diagnose the overflow detectable at compile time. FixedPoint is changed to rely on these in implementation of primitive arithmetic operations.
Swift SVN r9328
- Change type attribute printing logic (in astprinter and the demangler)
to print in the new syntax
- Change the swift parser to only accept type attributes in the new syntax.
- Update canParseTypeTupleBody to lookahead over new-syntax type attributes.
- Update the testsuite to use the new syntax.
Swift SVN r9273
1) on decls, they say the decl is weak/unowned.
2) in sil mode, on types, they indicate that the type has weak/unowned storage.
Since these are different things, split the SIL type attributes out to new
attributes (sil_weak/sil_unowned) to crystalize the relationship.
Swift SVN r9270
specific to types. While we're at it, improve the diagnostic for when a decl-specific
attribute is applied to a type, or a type-specific attribute is applied to a decl.
Swift SVN r9268
of having a ton of ad-hoc bools in it. This allows us to consolidate a ton of
boilerplate, eliminating 250 lines of code:
17 files changed, 435 insertions(+), 662 deletions(-)
2) This eliminates the special case for weak and unowned attributes, which previously
didn't show up in Attr.def.
3) While we're at it, keep track of proper source locations for each attribute, and
use these to emit diagnostics pointing at the attribute in question instead of at
a funcdecl or the @ sign.
4) Fix axle attributes, which had vertex and fragment swapped.
Swift SVN r9263
wide
Currently integer literals are 64-bit. In order to allow checking for overflow
while converting an integer literal to swift.UInt/Int* types we need at least
65 bits. But floating point numbers (Float32, Float64, Float80) are
BuiltinIntegerLiteralConvertible. In order to allow spelling large floating
point constants, we allow 136-bit literals.
Rationale: 128 bits are enough to represent the absolute value of min/max IEEE
Binary32, and we need 1 bit to represent the sign. 136 is 129 rounded to the
next 8 bits.
The plan is to have builtins that do the overflow check and convert 136-bit
numbers to the required width. We need these builtins for both integers and
floating point numbers to ensure that 136-bit numbers are folded into sane
constants in SIL and don’t escape to LLVM IR.
Swift SVN r9253
