Diagnostic categories are entirely unused and arguably useless as
implemented, as they merely denote the sub-component of the
compiler.
As far as categorizing warnings are concerned, I'm abandoning the
effort for now, as the utility is marginal and Swift and the Swift
compiler are probalby not ready for these to be nailed down. For the
sake of cleanliness, the CATEGORY field is also stripped from
WARNINGS.
If there's a need for automatic identifying of compiler sub-components
for diagnstics in the future, there are better ways to do this.
NFC
This is an internal-only affordance for the numerics team to be able to work on SIMD-compatible types. For now, it can only increase alignment of fixed-layout structs and enums; dynamic layout, classes, and other obvious extensions are left to another day when we can design a proper layout control design.
Swift SVN r27323
It can be enabled with the -num-threads <n> option.
Without this option there should be NFC.
When enabled, the LLVM IR is split into multiple modules: one module for each input file.
And for each module an output file is generated. All output files must be specified with -o options:
for each input file in the command line there must be an -o <outputfile> option.
LLVM compilation is performed on each module separately.
This means that the generated code is different than with regular -wmo.
But performance and code size should be approximately the same because important inter-file
optimizations are already done at SIL level (e.g. inlining, specialization).
There is still no support in the driver for this feature.
Swift SVN r25930
Thanks to the way we've set up our diagnostics engine, there's not actually
a reason for /everything/ to get rebuilt when /one/ diagnostic changes.
I've split them up into five categories for now: Parse, Sema, SIL, IRGen,
and Frontend, plus a set of "Common" diagnostics that are used in multiple
areas of the compiler. We can massage this later.
No functionality change, but should speed up compile times!
Swift SVN r12438
