- Don't require "OverloadedBuiltinKind::" to be in the invocation
of a bunch of builtins for their specification of overload info.
Eliminating this makes the file fit in 80 columns.
- Eliminate a bunch of classifications that only classify one thing,
in favor of a "BUILTIN_MISC_OPERATION" dumping ground for all the
custom stuff. This eliminates a bunch of boilerplate.
No functionality change.
Swift SVN r3615
diagnostic strip of lvalue wrappers, make the base diagnostic mention the
member name, and add a radar number for a really terrible diagnostic that
needs to be solved in another way (12939553)
Swift SVN r3614
base type 'module<swift>' has no valid '.' expression for this field var error = swift.nonexistent_member"
to:
module 'swift' has no member named 'nonexistent_member'
Swift SVN r3610
By splitting out the expression used to allocate 'this' (which exists
in the AST but cannot be written in the Swift language proper), we
make it possible to emit non-allocating constructors for imported
Objective-C classes, which are the only classes that have an
allocate-this expression.
Swift SVN r3558
While we haven't worked out the details of whether methods in
extensions can be overridden in Swift, it's something that does happen
in Objective-C, so we need to deal with it.
With this change, note that our demo application can both allocate
Objective-C objects with "new" (which John recently fixed) and also
subscript mutable arrays to both read and write.
Swift SVN r3485
The IR generation for this conversion is different from
derived-to-base conversions, because converting from an archetype to
its superclass type means projecting the buffer and then performing
the conversion.
Swift SVN r3462
This change enables inheritance constraints such as "T : NSObject",
which specifies that the type parameter T must inherit (directly or
indirectly) from NSObject. One can then implicit convert from T to
NSObject and perform (checked) downcasts from an NSObject to a T. With
this, we can type-
IR generation still needs to be updated to handle these implicit
conversions and downcasts. New AST nodes may follow.
Swift SVN r3459
Note: this is an experiment.
When we're asked to render a diagnostic for a declaration that does
not have source information, pretty-print the declaration into a
buffer and synthesize a location pointing into that buffer. This gives
the illusion of Clang-style diagnostics where we have all of the
source headers, but without actually requiring that source location
information. It may prove useful or infuriating, but at the very least
it might help us understand how the importer works. Example:
cfuncs_diags.swift:14:7: error: no candidates found for call
exit(5)
~~~~^~~
cfuncs_diags.swift:6:6: note: found this candidate
func exit(_ : Float) {}
^
cfuncs.exit:1:6: note: found this candidate
func exit(_ : CInt)
^
Swift SVN r3434
The interesting thing here is that we need runtime support in
order to generate references to metatypes for classes, mostly
because normal ObjC classes don't have all the information we want
in a metatype (which for now just means the VWT pointer).
We'll need to be able to reverse this mapping when finding a
class pointer to hand off to, say, an Objective-C class method,
of course.
Swift SVN r3424
Currently only used for parsing. The immediate intent of these attributes is
to have them behave like [objc] for the purpose of emitting method
implementations; however, they are semantically distinct and should only be
used to expose outlets and actions to Interface Builder.
Swift SVN r3416
Swift's diagnostic system is built on the quaint notion that every
declaration known to the front end has a valid source location to
which diagnostics mentioning that declaration (say, in a "here is a
candidate" note) can point. However, with a real module system, the
source corresponding to a declaration in a module does not need to be
present, so we can't rely on source locations.
Instead of source locations, allow diagnostics to be anchored at a
declaration. If that declaration has source-location information, it
is used. Otherwise, we just drop source-location information for
now. In the future, we'll find a better way to render this information
so it feels natural for the programmer.
Swift SVN r3413
Note that the constructors we emit don't function yet, since they rely
on the not-yet-implemented class message sends to Objective-C
methods.
Swift SVN r3370
This implementation is very lame, because we don't currently have a
way to detect (in Sema or SIL) where 'this' gets uniquely assigned,
and turn that assignment into initialization.
Also, I'm starting to hate the name 'allocating' constructor, because
it's the opposite of the Itanium C++'s notion of the allocating
constructor. Will think up a better name.
Swift SVN r3347
This introduces support for the syntax
Derived(baseObj)
to downcast from a class type to one of its subclasses. This still
needs more language design and implementation work, including:
- This overloads the X(y) syntax again, which already means either
"coerce y to type X, performing implicit conversions if necessary"
or "construct a value of type X from y". It's no actually ambiguous,
because the first case won't apply for downcasts and the second case
is limited to value types, but it makes me wonder whether we want a
different syntax for the first case.
- We need this to be a checked cast, but don't have the runtime
infrastructure to do so yet. I've left this as a FIXME.
However, the Objective-C importer is fairly useless because everything
that creates an object returns an "id", "id" maps to "NSObject", and
then the type system doesn't let you get from NSObject back to the
type you care about. So, this lets you explicitly do the cast.
Swift SVN r3279
No functionality change: the only subclass is CoerceExpr, for cases
where the user has forced an expression to a given type, e.g., Int32(17).
Swift SVN r3278
There is no protection whatsoever if the Clang-to-Swift type
conversion produces something that Swift doesn't lower in an
ABI-compatible way. That will be dealt with later.
Swift SVN r3249
From a user's perspective, one imports Clang modules using the normal
Swift syntax for module imports, e.g.,
import Cocoa
However, to enable importing Clang modules, one needs to point Swift
at a particular SDK with the -sdk= argument, e.g.,
swift -sdk=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9M.sdk
and, of course, that SDK needs to provide support for modules.
There are a number of moving parts here. The major pieces are:
CMake support for linking Clang into Swift: CMake users will now need
to set the SWIFT_PATH_TO_CLANG_SOURCE and SWIFT_PATH_TO_CLANG_BUILD
to the locations of the Clang source tree (which defaults to
tools/clang under your LLVM source tree) and the Clang build tree.
Makefile support for linking Clang into Swift: Makefile users will
need to have Clang located in tools/clang and Swift located in
tools/swift, and builds should just work.
Module loader abstraction: similar to Clang's module loader,
a module loader is responsible for resolving a module name to an
actual module, loading that module in the process. It will also be
responsible for performing name lookup into that module.
Clang importer: the only implementation of the module loader
abstraction, the importer creates a Clang compiler instance capable of
building and loading Clang modules. The approach we take here is to
parse a dummy .m file in Objective-C ARC mode with modules enabled,
but never tear down that compilation unit. Then, when we get a request
to import a Clang module, we turn that into a module-load request to
Clang's module loader, which will build an appropriate module
on-the-fly or used a cached module file.
Note that name lookup into Clang modules is not yet
implemented. That's the next major step.
Swift SVN r3199
