Each one has a different kind of lookup cache anyway, and there's no real
reason to have them share storage at the cost of type-safety.
Swift SVN r9242
Being able to pass -l to the driver isn't so interesting, and it's an
extra field that lives on TranslationUnit for no reason. Just remove it.
This doesn't interfere with autolinking, i.e. inferring -l flags based on
imported modules.
Swift SVN r9241
- Added 2 new builtins strunc_with_overflow and utrunc_with_overflow
that perform truncation and produce a compile time error when truncation
overflows.
- Used these builtins instead of trunc to implement "_convertFromBuiltinIntegerLiteral".
- Currently, the builtins are converted to trunc in IRGen, but we should
not be IRGenning code that uses them, since all uses of
"_convertFromBuiltinIntegerLiteral" should be inlined and the arguments
constant folded.
- I had to change a test and the implementation of operator '~' in the standard library
because they assumed that '0xFF' is a valid signed Int8. It is questionable if we should
allow this and if we should treat signed and unsigned integers differently depending on
how they are spelled (decimal or hexadecimal).
* This patch will be further improved (Ex: will start finding overflows on Int64, better
deal with '-128' after the negative integer literal patch is committed.)
Swift SVN r9226
Now that we have a solid Optional-based story for dynamic casts, it's no longer needed, and can be expressed as '(x as T)!'. Future refinement of the 'as' syntax will deal with the unfortunate extra parens.
Swift SVN r9181
docs/Resilience.rst describes the notion of a resilience component:
if the current source file is in the same component as a module being
used, it can use fragile access for everything in the other module,
with the assumption that everything in a component will always be
recompiled together.
However, nothing is actually using this today, and the interface we
have is probably not what we'll want in 2.0, when we actually implement
resilience.
Swift SVN r9174
Right now this is just an extra layer of indirection for the decls,
operators, and imports in a TU, but it's the first step towards compiling
multiple source files at once without pretending they're all in a single
file. This is important for the "implicit visibility" feature, where
declarations from other source files in the same module are accessible
from the file currently being compiled.
Swift SVN r9072
Pull the implicit 'Self' associated type out of the protocol and into
an implicitly-declared generic parameter list for the protocol. This
makes all of the methods of a protocol polymorphic, e.g., given
protocol P {
typealias Assoc
func getAssoc() -> Assoc
}
the type of P.getAssoc is:
<Self : P> (self : @inout P) -> () -> Self.Assoc
This directly expresses the notion that protocol methods are
polymorphic, even though 'Self' is always implicitly bound. It can be
used to simplify IRgen and some parts of the type checker, as well as
laying more of the groundwork for default definitions within
protocols as well as sundry other improvements to the generics
system.
There are a number of moving parts that needed to be updated in tandem
for this. In no particular order:
- Protocols always get an implicit generic parameter list, with a
single generic parameter 'Self' that conforms to the protocol itself.
- The 'Self' archetype type now knows which protocol it is
associated with (since we can no longer point it at the Self
associated type declaration).
- Protocol methods now get interface types (i.e., canonicalizable
dependent function types).
- The "all archetypes" list for a polymorphic function type does not
include the Self archetype nor its nested types, because they are
handled implicitly. This avoids the need to rework IRGen's handling
of archetypes for now.
- When (de-)serializing a XREF for a function type that has an
interface type, use the canonicalized interface type, which can be
meaningfully compared during deserialization (unlike the
PolymorphicFunctionType we'd otherwise be dealing with).
- Added a SIL-specific type attribute @sil_self, which extracts the
'Self' archetype of a protocol, because we can no longer refer to
the associated type "P.Self".
Swift SVN r9066
Semantic context describes the origin of the declaration and serves the same
purpose as opaque numeric "priority" in Clang -- to determine the most likely
completion.
This is the initial implementation. There are a few opportunities to bump the
priority of a certain decl by giving it SemanticContextKind::ExprSpecific
context that are not implemented yet.
Swift SVN r9052
This was causing massive failures at run-time.
This reverts commit 80081db973ccb7100741fea19ce8e8c116fc410f.
Conflicts:
lib/SILPasses/ConstantPropagation.cpp
test/SILPasses/constant_propagation.swift
test/SILPasses/constant_propagation2.sil
Swift SVN r9050
After talking to John, Joe, and Dave Z, 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 r9034
Rewrite ForEachStmt SILGen to use the Optional intrinsics with the Generator.next method to iterate through sequences, and kill off the Enumerator path in Sema. Cut over 'EnumeratorType.Element' requirements to instead require 'GeneratorType.Element' in the stdlib.
There are a couple of bugs remaining that need follow-up work. There appears to be a bug in nested enum layout (e.g. T??) that's causing test/Interpreter/enum to break; I'll investigate and fix. There's also a lingering type-checker bug with inferred associated types that causes them to fail requirement checks <rdar://problem/15172101>, which I think Doug needs to look into.
Swift SVN r9017
UnqualifiedLookup to ask an external source for
names. There are two phases to this external lookup:
- Before consulting globals in other modules,
UnqualifiedLookup calls lookupOverrides() to see
if there are any results that should override the
results from modules. (N.b.: these should not be
able to override names that are locally defined.)
- After consulting globals in other modules,
UnqualifiedLookup as a last resort calls
lookupFallbacks() to see if there's anything out
there at all that could serve that name. This may
be more computationally expensive.
These hooks are used by LLDB's expression parser to
resolve names for persistent variables (akin to the
existing $0, $1, ... variables) and variables local
to the current frame.
Swift SVN r9014
Unfortunately I can't figure out a way to do the suggested refactoring of
packing the identifier into the PointerUnion as well, since some clients
ask for the identifier back even after name-binding has occurred.
Swift SVN r9009
Now that TypeChecker is being used to check all sorts of things (not all
from a single TU), it's not really correct to have a single top-level TU
that gets used everywhere. Instead, we should be using the TU that's
appropriate for whatever's being checked. This is a small correctness win
for order-independent type-checking, but is critical for multi-file
translation units, which is needed for implicit visibility.
This basically involves passing around DeclContexts much more.
Caveat: we aren't smart about, say, filtering extensions based on the
current context, so we're still not 100% correct here.
Swift SVN r9006
