Language features like erasing concrete metatype
values are also left for the future. Still, baby steps.
The singleton ordinary metatype for existential types
is still potentially useful; we allow it to be written
as P.Protocol.
I've been somewhat cavalier in making code accept
AnyMetatypeType instead of a more specific type, and
it's likely that a number of these places can and
should be more restrictive.
When T is an existential type, parse T.Type as an
ExistentialMetatypeType instead of a MetatypeType.
An existential metatype is the formal type
\exists t:P . (t.Type)
whereas the ordinary metatype is the formal type
(\exists t:P . t).Type
which is singleton. Our inability to express that
difference was leading to an ever-increasing cascade
of hacks where information is shadily passed behind
the scenes in order to make various operations with
static members of protocols work correctly.
This patch takes the first step towards fixing that
by splitting out existential metatypes and giving
them a pointer representation. Eventually, we will
need them to be able to carry protocol witness tables
Swift SVN r15716
in the plist file.
This was exposed by r15694, but probably did not manifest as
the string escaping logic previously only happened on B&I submissions.
In this approach, the final version quad is turned into a string
within Version.cpp, not at the -D invocation.
Swift SVN r15708
This is meant to be utilized for a narrow set of scenarios specific to dogfooding our pre-1.0 compiler, so please do not take any dependencies on this. In fact, I'll be removing this in the next milestone. (See rdar://problem/16380797.)
Also included - improve error recovery when parsing broken build configuration clauses.
Swift SVN r15694
recursive positions.
Also change the representation of certain <global>s in the
demangling tree by sinking <directness> down as a child of
the affected node.
Swift SVN r14537
Adding these asserts would help debugging. Without the asserts it would fail
anyway, but in a more obscure place, usually with a null pointer dereference.
Swift SVN r14512
A short-term fix to <rdar://problem/16079822> that keeps generic overloads from creating symbol collisions without requiring a larger migration of the debugger or other tools.
Swift SVN r14353
We can attach comments to declarations. Right now we only support comments
that precede the declarations (trailing comments will be supported later).
The implementation approach is different from one we have in Clang. In Swift
the Lexer attaches the comments to the next token, and parser checks if
comments are present on the first token of the declaration. This is much
cleaner, and faster than Clang's approach (where we perform a binary search on
source locations and do ad-hoc fixups afterwards).
The comment <-> decl correspondence is modeled as "virtual" attributes that can
not be spelled in the source. These attributes are not serialized at the
moment -- this will be implemented later.
Swift SVN r14031
This is more in line with all other modules currently on our system.
If/when we get our final name for the language, we're at least now set
up to rename the library without /too/ much trouble. (This is mostly just
a lot of searching for "import swift", "swift.", "'swift'", and '"swift"'.
The compiler itself is pretty much just using STDLIB_NAME consistently now,
per r13758.)
<rdar://problem/15972383>
Swift SVN r14001
We allow overloads on foo(() -> T) and foo(@auto_closure () -> T) in Sema, so they need distinct manglings. Fixes <rdar://problem/16045566>.
Swift SVN r13856
Implement the demangling for generic signatures and their requirements, dependent parameters, and member types, now that we actually use these manglings when naming reabstraction thunks.
Swift SVN r13764
This is mostly useful for the standard library, whose name is going to
change to "Swift" soon. (See <rdar://problem/15972383>.) But it's good DRY.
Swift SVN r13758
Added a TaskSignalledCallback to TaskQueue, which will be called instead of
TaskFinishedCallback if the task exited abnormally.
In Unix/TaskQueue.inc, check WIFSIGNALED if the task did not pass WIFEXITED,
and call the TaskSignalledCallback if necessary. In Default/TaskQueue.inc, check
for a return code of -2; if present, call the TaskSignalledCallback instead of
the TaskFinishedCallback.
Updated Compilation to pass a TaskSignalledCallback.
Added diagnostics to indicate when a command signalled as well as when a command
failed with either poor diagnostics or a non-1 exit code. (These match Clang’s
diagnostics.) Added tests to ensure these diagnostics are emitted when the
frontend crashes or fails an assertion (if assertions are available).
This fixes <rdar://problem/16012199>.
Swift SVN r13654
This time, be sure to reset the demangler state after demangling the
specialization header, because it is a prefix of the demangled symbol
name.
Swift SVN r13378
- Int and UInt are now struct types backed by Builtin.Word. Previously they
were typealiases for Int64; Int and Int64 are now distinct types.
- Mangled names 'i' and 'u' are now Int and UInt. Int64 is mangled longhand.
- Word is a typealias for Int. It is expected to go away in the future.
- Builtin.Word is unchanged.
- CLong and CUnsignedLong are typealiases for Int and UInt.
- FixedPoint.swift is now FixedPoint32.swift and FixedPoint64.swift.
Reunifying these requires better builtins, especially for checked
conversions (rdar://15472770).
- Updated many tests, mostly because Int is no longer spelled Int64 in sil.
- One check was removed from test decl/operator/operators.swift
because it changed behavior when Int became a non-typealias
type (rdar://15934688).
Swift SVN r13109
type, so we emit them. Add mangler (and demangler) support for these.
Enhance our testcase to check to make sure that stores within these
specifiers are direct, they don't cause recursive infinite loops.
John, I picked w/W for the mangling letters, let me know if this is ok.
Swift SVN r13050
Added swift::ExecuteInPlace(), which on Unix acts as a wrapper for execv()
and execve(). On other platforms, swift::ExecuteInPlace() is a wrapper for
llvm::sys::ExecuteAndWait(), so callers must be prepared for ExecuteInPlace()
to return in a non-error situation.
Added support in Compilation::performJobs() to detect that the Compilation has
exactly one Command to run. If that's the case, and buffered output isn't
required, execute that Command using swift::ExecuteInPlace() (instead of
creating a TaskQueue, which may unconditionally buffer output).
This change will allow the driver to invoke the frontend's REPL and immediate
modes without buffering output (and, on Unix, without a separate process being
spawned).
Also updated test/Driver/basic.swift to emit output with these changes in place.
Swift SVN r12544
While this is not yet used, Compilation will be able to adopt this for easier testing of driver-level task execution (instead of forcing all driver-level tests to invoke the frontend, linker, etc.).
Swift SVN r12349
For the Unix implementation, this returns NumberOfParallelTasks (unless that value is 0, in which case it returns the default value of 1).
For the Default implementation, this always returns 1, since it does not support parallelism.
Swift SVN r12348
Instead of always calling waitpid() and looking for the termination of a task, call poll() and watch for events on the pipes which are used for buffering subtask output. When we receive a POLLIN or POLLPRI event, ask the corresponding Task to read from the pipe; when we receive a POLLHUP or POLLERR event, wait for the subtask to finish and then ask the Task to perform its post-execution tasks.
Now that the Unix implementation properly handles large amounts of subtask output, re-enable the Unix implementation (if supported).
This fixes <rdar://problem/15795234>.
Swift SVN r12293
When we're using Objective-C's memory allocation, emit .cxx_construct
methods whenever we have instance variables with in-class
initializers. Presently, these methods are just empty stubs.
Swift SVN r12211
The Objective-C runtime executes the .cxx_destruct method after the
last -dealloc has executed when destroying an object, allowing the
instance variables to remain live even after the subclass's
destructor/-dealloc has executed, which is important for memory
safety. This fixes the majority of <rdar://problem/15136592>.
Note that IRGenModule::getAddrOfIVarDestroyer() contains an egregious
hack to find the ivar destructor SIL function via a linear
search. We need a better way to find SIL functions that we know exist,
because LinkEntity does not suffice.
Swift SVN r12206
The current implementation does not read() from each Task's pipe until execution
finishes. This causes subtasks to block in write() if the pipe is full, which
only happens if there is a large amount of output (such as in -dump-ast mode).
Fixing output buffering and reenabling the Unix TaskQueue implementation is
tracked by <rdar://problem/15795234>.
Swift SVN r12135
Due to the nature of this class, there are two implementations of TaskQueue:
a Unix-specific implementation which supports both parallel execution and output
buffering, and a default implementation which supports neither of these features.
(The default implementation uses the functions from llvm/Support/Program.h for execution.)
TaskQueue allows clients to provide a TaskBeganCallback and a TaskFinishedCallback,
each of which will be called when a new task begins or when a task finishes execution,
respectively. Clients may add tasks to the TaskQueue in either of these callbacks,
and clients can stop further execution by returning TaskFinishedResponse::StopExecution
from the TaskFinishedCallback.
Swift SVN r12059
Revert "add a hackaround for rdar://15753317. I don't unerstand the code enough to tell if this is the right fix."
This reverts commit 416983b0734dde6979c98971948068c7a157e336.
Swift SVN r11942
