The diagnostics formatter from swift-syntax previously only handled
fully-formed diagnostics anchored at a particular syntax node.
Therefore, the compiler would fall back to the existing LLVM-based
diagnostic formatter for diagnostics that had no source location.
Adopt new API in the swift-syntax diagnostics formatter that renders a
diagnostic message without requiring source location information, so
that we consistently use the swift-syntax formatter when it is
selected (which is the default).
Print diagnostic groups as part of the LLVM printer in the same manner as the
Swift one does, always. Make `-print-diagnostic-groups` an inert option, since we
always print diagnostic group names with the `[#GroupName]` syntax.
As part of this, we no longer render the diagnostic group name as part
of the diagnostic *text*, instead leaving it up to the diagnostic
renderer to handle the category appropriately. Update all of the tests
that were depending on `-print-diagnostic-groups` putting it into the
text to instead use the `{{documentation-file=<file name>}}`
diagnostic verification syntax.
We're moving over to a model where we provide direct links to educational notes /
diagnostic group notes whenever relevant. Rendering the Markdown from these
files to the terminal is less relevant with this approach, so remove it from the
compiler.
When printing diagnostics, category names are printed as [#<category-name>]
at the end of a diagnostic. For all of the category names that are mentioned
in this manner, print "footnotes" at the end of compilation providing
documentation references to each category, e.g.,
[#deprecated]: <http://example.com/deprecated>
[#StrictMemorySafety]: <http://example.com/memory-safety>
Right now, these point into the markdown files in the installed toolchain,
same as the URLs behind references. That is subject to change in the future.
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
We were re-parsing each source file for each top-level diagnostic emitted,
which is... rather inefficient. Cache the parsed source files until
the PrintingDiagnosticConsumer goes away.
Merge with BasicBridging and ASTBridging
respectively. The changes here should be pretty
uncontroversial, I tried to keep it to just moving
code about.
* BridgedString for ASTGen -> C++ string returnings
* Null terminated C-strings for C++ -> ASTGen string arguments
* UnsafeMutableRawPointer for C++ -> ASTGen diagnostic engine arguments
For whatever reason, using standard headers in modules imported from
Swift code (i.e. depending on Darwin overlay) is no longer an issue.
rdar://115438609
Conflicts:
- `CMakeLists.txt` caused by the extra `-D` added in rebranch to
reduce the number of deprecation warnings.
- `lib/Frontend/PrintingDiagnosticConsumer.cpp` caused by the removal
of one of the `#if SWIFT_SWIFT_PARSER` on rebranch (probably should
have been done on main).
Use FetchContent to include swift-syntax directly in swift. This can be
thought of as an `add_subdirectory` for a directory outside the root.
The default build directory will be `_deps/swiftsyntax-subbuild/`, though
the modules and shared libraries will be built in `lib/swift/host` by
passing down `SWIFT_HOST_LIBRARIES_DEST_DIR` to avoid copying them as we
were doing previously.
We'll be using the new swift-syntax diagnostic formatter in the near
future, as it is nearly available on all host platforms. So, remove
the C++ formatter that did source-line annotation, falling back to the
"LLVM" style when swift-syntax is not compiled in.
The "grouped diagnostics" feature can handle multiple
warnings/errors/remarks in a single grouping, but doing so isn't very
ergonomic for users because the primary warning/error/remark can be
buried in the source file. As a first step toward improving this
situation, always break up groups at a new warning/error/remark.
We're going to move toward the new swift-syntax formatter. Use it for
the "swift" diagnostic style instead of the experimental formatter
written in C++.
There are some tests for the experimental formatter in C++ that test
precise formatting of diagnostics. I've disabled them in the same
places where the new swift-syntax formatter is enabled, for now. We
may choose to remove them entirely, because swift-syntax itself is
where the specific format is defined, and has those same kinds of
tests already.
Use the new "grouped diagnostics" feature of the swift-syntax
diagnostic rendering to emit printed diagnostics under the
swift-syntax diagnostic style. This emits macro expansion buffers as
text to the terminal, inset in a box where the macro was expanded, so
that there is more context for understanding how the macro was
expanded and what went wrong inside it.
Add frontend flag `-emit-macro-expansion-files diagnostics` to emit any
macro expansion buffers referenced by diagnostics into files in a
temporary directory. This makes debugging type-checking failures in
macro expansions far easier, because you can see them after the
compiler process has exited.
The SwiftDiagnostics module within swift-syntax has a diagnostic
pretty-printer that does a nice rendering of the source code with
diagnostics placed inside gaps between the code lines.
Introduce another `-diagnostic-style` argument, `swift-syntax`,
to bridge from the pretty-printed C++ diagnostics over to the
swift-syntax diagnostics engine.
This default formatting style remains the same "LLVM style". "Swift style"
is what was previously enabled via -enable-experimental-diagnostic-formatting
- Always use the line number in the actual source file when extracting excerpts and adding highlights/fix-its
- Always use the display name when printing excerpt titles
- Don't print surrounding lines when an annotated line is in a virtual file
This reverts commit f919e047834eddf8863723b9db1fcb8d344d2006.
