If diagnostics are produced as part of a transaction, let's copy
strings associated with arguments into a separate long(er) term
storage which is going to be cleaned up when diagnostic is actually
emit to the consumers.
If a syntax sugared type like Array had an unresolved type, it used to print as `[_]` in diagnostics, which could be confusing.
Instead, desugar these unresolved types before printing, so Array, for example, prints as `Array<_>`.
Currently this only applies to Array, Dictionary, and Optional.
Currently only works for types that are /just/ a 'some' type, not in a
nested position. Also won't show them for opaque types with different
requirements, to avoid noise when it's not strictly necessary. This
does mean that 'some P' vs. 'some P & Q' won't get the origin part.
Part of rdar://problem/50346954
This is an option only intending to help compiler developers triage/track down
why a warning is being emitted in a quick manner. It will only be in asserts
builds since it is an LLVM option.
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
Take away the type checker constructor that allows one to provide a
diagnostic engine different from the one associated with the ASTContext. It
doesn’t actually work to suppress diagnostics. Switch all clients over to
the constructor that takes only an ASTContext.
Introduce the DiagnosticSuppression RAII class so clients that want to
suppress diagnostics can suppress *all* diagnostics. Use it where we
were previously suppressing diagnostics.
By formalizing ReferenceOwnership as a diagnostic argument kind, we get
less boilerplate, better type safety, better output consistency, and
last but not least: future proofing.
Rather than relying on the NameAliasType we get by default for references
to non-generic typealiases, use BoundNameAliasType consistently to handle
references to typealiases that are formed by the type checker.
This doesn't have a specific effect now, because all of these places
are likely to only see NameAliasType, but it is refactoring with the
intent of eliminating NameAliasType entirely.
Introduce a new Type node, BoundNameAliasType, which describes a
reference to a typealias that requires substitutions to produce the
underlying type. This new type node is used both for references to
generic typealiases and for references to (non-generic) typealiases
that occur within generic contexts, e.g., Array<Int>.Element.
At present, the new type node is mainly useful in preserving type
sugar for diagnostics purposes, as well as being reflected in other
tools (indexing, code completion, etc.). The intent is to completely
replace NameAliasType in the future.
This enables one to easily drop down into the debugger in such cases. This is
enabled by the option swift-diagnostics-assert-on-error and can only happen in
an asserts build.
rdar://34222540
This allows reporting successful and unsuccessful optimizations similar to
clang/llvm.
This first patch adds support for the
options -Rpass=<pass-name-regex> -Rpass-missed=<pass-name-regex>. These allow
reporting successful/unsuccessful optimization on the compiler output for passes
specified by the regex. I've also added one missed and one passed remark type
to the inliner to test the infrastructure.
Clang also has the option of collecting these records in an external YAML data
file. This will be added in a later patch.
A few notes:
* The goal is to use this facility for both user-lever "performance" warnings
and expert-level performance analysis. There will probably be a flag in the
future differentiating the verbosity.
* The intent is match clang/llvm as much as it makes sense. On the other hand I
did make some changes. Unlike in llvm, the emitter is not a pass which
simplifies things. Also the remark class hierarchy is greatly simplified since
we don't derive from DiagnosticInfo. We also don't derive from Diagnostic to
support the streaming API for arbitrary named-value pairs.
* Currently function names are printed mangled which should be fixed.
Previously we had more ad hoc logic that tried to decide if it was
worth desugaring a type based on its structure. Now we instead look
for a typealias that might actually benefit from desugaring, and if
we don't find one we won't show the 'aka' note.
The typedef `swift::Module` was a temporary solution that allowed
`swift::Module` to be renamed to `swift::ModuleDecl` without requiring
every single callsite to be modified.
Modify all the callsites, and get rid of the typedef.
