With `ARCMigrate` and `arcmt-test` removed from clang in
https://github.com/llvm/llvm-project/pull/119269 and the new code
migration experience under way (see
https://github.com/swiftlang/swift-evolution/pull/2673), these options
are no longer relevant nor known to be in use. They were introduced
long ago to support fix-it application in Xcode.
For now, turn them into a no-op and emit a obsoletion warning.
(cherry picked from commit 46c394788a84d5932289c71274dd32ea2d61d9dc)
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've been converging the implementations of educational notes and
diagnostic groups, where both provide category information in
diagnostics (e.g., `[#StrictMemorySafety]`) and corresponding
short-form documentation files. The diagnostic group model is more
useful in a few ways:
* It provides warnings-as-errors control for warnings in the group
* It is easier to associate a diagnostic with a group with
GROUPED_ERROR/GROUPED_WARNING than it is to have a separate diagnostic
ID -> mapping.
* It is easier to see our progress on diagnostic-group coverage
* It provides an easy name to use for diagnostic purposes.
Collapse the educational-notes infrastructure into diagnostic groups,
migrating all of the existing educational notes into new groups.
Simplify the code paths that dealt with multiple educational notes to
have a single, possibly-missing "category documentation URL", which is
how we're treating this.
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.
Emit the category documentation URL into serialized diagnostics as part of
the existing RECORD_CATEGORY, using the form
<category name>@<category URL>
and keeping the existing "category name length" field referring to the
length of the category name itself (up to the @). There is a corresponding
update to libclang to process such category names correctly and add
API, but it isn't strictly necessary: readers that use the category
name length field correctly will see no behavior change, whereas
readers that ignore it will merely see the extra `@<category URL>`.
This is a step toward staging out our (mis)use of the "flags" field as
the place to stash educational note and diagnostic group documentation
URLs.
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.
The serialized diagnostic format has some extra fields that we can
adopt for diagnostic groups. Specifically:
* Category: store the diagnostic group name here
* Flags: extend the hack used by educational notes of placing Markdown file paths here
While here, also sort and deduplicate output entries, and stop having
the Python script try to
The Python script is still messing up the files in some cases, but
I haven't tracked it down. Instead, I have a small Swift program
that does the same thing more easily.
Adjust the valid position checking and special handle EOF position.
If the requested location is at EOF, use the last token, but still
emit the diagnostics at the specificied location.
rdar://138426038
The diagnostics engine has some code to pretty-print a declaration when
there is no source location for that declaration. The declaration is
pretty-printed into a source buffer, and a source location into that
buffer is synthesizes. This applies to synthesized declarations as well
as those imported from Swift modules (without source code) or from Clang.
Reimplement this pretty-printing for declarations as a request. In
doing so, change the manner in which we do the printing: the
diagnostics engine printed the entire enclosing type into a buffer
whose name was the module + that type. This meant that the buffer was
shared by every member of that type, but also meant that we would end
up deserializing a lot of declarations just for printing and
potentially doing a lot more work for these diagnostics.
This commit adds new compiler options -no-warning-as-error/-warning-as-error which allows users to specify behavior for exact warnings and warning groups.
These tests are using FileCheck to check the result of diagnostic
formatting in ways that don't match the new formatter. Force the old
formatter or, where possible, generalize so that they match both
formatters.
When a file defining an API is included in two modules, clients calling
that API may get an error about the ambiguity on the duplicated API.
That error is not very helpful when it takes into account the
swiftsourceinfo data and points to the source file instead of the
module. In such a case the notes point twice to the same file and line
of code.
Improve this diagnostic by appending the module name to the notes when a
candidate is found outside of the module.
rdar://116255141
Use flag record (currently unused) to emit semi-colon separated
list of paths to educational notes associated with a diagnostic.
Resolves: rdar://118993780
The serialized diagnostics reader has one very specific limitation it
places on filenames: they must not end in `/`, because that makes them
look like a directory. This is not documented, and the diagnostics
reader will unceremoniously crash when trying to read such a file.
While the reader should be fixed to at least fail gracefully in such
cases, Swift also shouldn't generate such filenames. Right now, they
can be generated when referencing an entity named `/` that is
synthesized or comes from a module. When we encounter such file names,
append `_operator` to avoid the problem.
Fixes rdar://118217560.
Show the same error for both decls and imports when using the package
access level and no package name is set. Also brings up this check to
run once on decls and avoid repeated diagnostics.
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.
`module.map` as a module map name has been discouraged since 2014, and
Clang will soon warn on its usage. This patch renames all instances of
`module.map` in the Swift tests to `module.modulemap` in preparation
for this change to Clang.
rdar://106123303
The swift driver emits extra newlines because it applies the LF ->
CRLF conversions again on the outpt from the child processes. Fix it
by using the binary mode when outputting the output from the child
processes.
Fixes: #64413
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.
