Reformatting everything now that we have `llvm` namespaces. I've
separated this from the main commit to help manage merge-conflicts and
for making it a bit easier to read the mega-patch.
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
Windows requires a handle to get memory usage, so do a slight refactor
to collect the child's memory usage as it exits instead of as the parent
is cleaning up.
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
When providing the -parseable-output flag to the swift compiler, it will provide json formatted messages about tasks that run.
I added some optional usage information in form of user time, system time and maxrss to the output. This can be used by other tools using the compiler to get some insights about time and memory usage.
Since the output does not longer match processes run (in batch mode), I also added a real_pid field so the client could reason about jobs that belong together if needed.
rdar://39798231
* Add the signal number of the terminated task to the output of the driver on platforms for which the signal number is available. The new key in the parseable driver output is "signal".
* Add a test to verify that the signal number is emitted.
* Add documentation for the new "signal" key emitted in the parseable driver output.
https://bugs.swift.org/browse/SR-3175
- Added missing ifdef guard in PointerIntEnum header
- Consistent naming convention for ifdef guards
- Consistent 'end namespace swift'
- Consistent single EOL at end of header files
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
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
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
