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
This adds two things:
- Calling `swiftc -dump-ast foo.swift [...] -o foo.ast` will dump the AST to the file `foo.ast`, instead of dumping it to `stderr` as usual.
- Calling `swiftc -dump-ast -output-file-map=outputFileMap.json *.swift [...]`, given an `outputFileMap.json` file that contains entries in the form `"ast-dump": "foo.ast"`, will dump the ASTs of the input files to their respective output files in the file map.
This should serve as a valid workaround to a bug mentioned in [the forums](https://forums.swift.org/t/error-when-dumping-the-ast-for-hundreds-of-files/17578) where the AST dump functionality crashes when called with too many input files. A few implementation details were also discussed in the same forum post.
As an aside, this also fixes a comment in `include/swift/Basic/PrimarySpecificPaths.h` that was incorrect.
There's no place to put the bridging header in a swiftinterface, and
they don't make sense with the intended use case of distribution.
Just disallow it up front.
rdar://problem/44113493
Commit to a command line option spelling so that build systems can
start testing it. I deliberately picked one of the longer names we
were considering because we can always decide to add a shorter alias,
but can't decide a shorter name was too generic.
Like the other supplementary output flags,
-emit-parseable-module-interface-path will emit a .swiftinterface file
to a particular path, while -emit-parseable-module-interface will put
it next to the main output (the one specified with -o).
rdar://problem/43776945
We already have something called "module interfaces" -- it's the
generated interface view that you can see in Xcode, the interface
that's meant for developers using a library. Of course, that's also a
textual format. To reduce confusion, rename the new module stability
feature to "parseable [module] interfaces".
This silences the instances of the warning from Visual Studio about not all
codepaths returning a value. This makes the output more readable and less
likely to lose useful warnings. NFC.
StringMap always copies its strings into its own storage. A DenseMap
of StringRefs has the same caveats as any other use of StringRef, but
in the cases I've changed the string has very clear ownership that
outlives the map.
No functionality change, but should reduce memory usage and malloc
traffic a little.
The OutputInfo, ToolChain, and Triple can all be retrieved from the
Compilation, so now that we're passing one of those around we don't
need to pass the others explicitly.
No functionality change.
Previously if you passed `-embed-bitcode-marker` to a command that
wasn't producing an object file, it would silently be ignored. This
change puts it inline with `-embed-bitcode` in this same case, which
generates a warning.
...but don't hook it up to anything yet.
This is the very very start of the module stability / textual
interfaces feature described at
https://forums.swift.org/t/plan-for-module-stability/14551/
For now I've just made it a frontend option (not a driver option),
which is good enough for testing.
Introduces the -name-bind frontend action that is intended as an intermediary between the parse-only actions and a full typechecking pass. In this phase, module imports will be validated and resolved, making it possible to emit full make-style dependencies files among other things.
Note that all information available to a parse-only pass is available to name binding, but because it does not continue-on to typecheck input files, full semantic information is not.
This flag is based on Clang's -fdebug-prefix-map, which lets the user remap absolute paths in debug info. This is necessary for reproducible builds and allows debugging to work on a different machine than the one that built the code when paths to the source may be different.
