Handles clang::DiagnosticsEngine and clang::DiagnosticIDs.
For DiagnosticIDs, this mostly migrates from `new DiagnosticIDs` to
convenience method `DiagnosticIDs::create()`.
Part of cleanup https://github.com/llvm/llvm-project/issues/151026
This patch integrates JSON as the source to generate HTML Mustache templates. The Mustache generator calls the JSON generator and reads JSON files on the disk to produce HTML serially.
This patch contains changes for the JSON generator that will enable compatibility with Mustache templates, like booleans to check for the existence and bounds of arrays to avoid duplication.
This patch changes JSON file serialization. Now, files are serialized
to a single directory instead of nesting them based on namespaces. The
global namespace retains the "index.json" name.
This solves the problem of class template specializations being serialized to the
same file as its base template. This is also planned as part of
future integration with the Mustache generator which will consume the JSON files.
Parse friends into a new FriendInfo and serialize them in JSON. We keep track of the friend declaration's template and function information if applicable.
Add support for documenting concepts. This handles concepts and constraints on function and class templates.
Atomic constraints are not considered yet. We don't order constraints based on their conjunctive or disjunctive properties.
LLVM style prefers no default label on fully covered switches to warn if
new enums are added. This patch removes the default label for that
purpose or uses IT_default instead of default if that was the only enum
not covered.
Adds a JSON generator backend to emit mapped information as JSON. This will enable a better testing format for upcoming changes. It can also potentially serve to feed our other backend generators in the future, like Mustache which already serializes information to JSON before emitting as HTML.
This patch contains functionality to emit classes and provides most of the basis of the generator.
This patch refactors CommentKind handling in clang-doc by introducing a
strongly typed enum class for better type safety and clarity. It updates
all relevant places, including YAML traits and serialization, to work
with the new enum. Additionally, it enhances the Mustache-based HTML
generation by fully supporting all comment kinds, ensuring accurate
structured rendering of comment blocks. The changes simplify future
maintenance, improve robustness by eliminating unchecked defaults, and
ensure consistency between generators.
Fixes https://github.com/llvm/llvm-project/issues/142083
namespace-template.mustache only rendered placeholder text. Enum and
record tags were added to the template. Now, we can render an index.html
for the global namespace and other namespaces.
Added tests and deleted some of the disabled unit tests.
This patch implements the business logic for setupTemplateValue, which
was split from #133161. The implementation configures the relative path
relationships between the various HTML components, and prepares them
prior to their use in the generator.
Co-authored-by: Peter Chou <peter.chou@mail.utoronto.ca>
In #138062 it was brought up that this was an anti-pattern. We'll need
to Migrate all of the mustache unittests that need to read template
files to lit tests, and disable them until tool support lands.
This patch adds or fills in some helper functions related to template
setup when initializing the mustache backend. It was split from #133161.
Co-authored-by: Peter Chou <peter.chou@mail.utoronto.ca>
This reverts commit e2a885537f11f8d9ced1c80c2c90069ab5adeb1d. Build failures were fixed right away and reverting the original commit without the fixes breaks the build again.
The `DiagnosticOptions` class is currently intrusively
reference-counted, which makes reasoning about its lifetime very
difficult in some cases. For example, `CompilerInvocation` owns the
`DiagnosticOptions` instance (wrapped in `llvm::IntrusiveRefCntPtr`) and
only exposes an accessor returning `DiagnosticOptions &`. One would
think this gives `CompilerInvocation` exclusive ownership of the object,
but that's not the case:
```c++
void shareOwnership(CompilerInvocation &CI) {
llvm::IntrusiveRefCntPtr<DiagnosticOptions> CoOwner = &CI.getDiagnosticOptions();
// ...
}
```
This is a perfectly valid pattern that is being actually used in the
codebase.
I would like to ensure the ownership of `DiagnosticOptions` by
`CompilerInvocation` is guaranteed to be exclusive. This can be
leveraged for a copy-on-write optimization later on. This PR changes
usages of `DiagnosticOptions` across `clang`, `clang-tools-extra` and
`lldb` to not be intrusively reference-counted.
Split from #133161. This patch fills in the implementation for a number
of the MustacheHTMLGenerator methods. Many of these APIs are just
stubbed out, and will have their implementation filled in by later
patches.
Co-authored-by: Peter Chou <peter.chou@mail.utoronto.ca>
Split from #133161. This patch adds HTMLMustacheGenerator.cpp, and
the most basic class defintion for the generator. Future patches will
add functionality.
Co-authored-by: Peter Chou <peter.chou@mail.utoronto.ca>
This patch adds start and end line numbers to clang-doc. Currently
clang-doc only encodes the start line numbers of records, struct, etc.
This patch adds start and end line number to clang-doc bitcode which is
passed to the generator. This will be used by the mustache backend to
generate line ranges. Based on the orginal patch in #135081.
Co-author: Paul Kirth <paulkirth@google.com>
Co-authored-by: PeterChou1 <peter.chou@mail.utoronto.ca>
This PR adds a new command-line option that allows users to specify the
prefix used for line-based anchors in repository URLs. Different
repository interfaces use different formats for line anchors (GitHub
uses `#L123`, googlesource uses `#123`, etc.). This option enables users
to customize the line prefix to match their repository platform without
requiring hard-coded values for each service.
Fixes#59814
Currently, when we set URLs from JS, we set them only using the protocol
and host locations. This works fine when docs are served from the base
directory of the site, but if you want to nest it under another
directory, our JS fails to set the correct path, leading to broken
links.
This patch adds a --base option to specify the path prefix to use, which
is set in the generated index_json.js file. index.json can then fill in
the prefix appropriately when generating links in a browser. This flag
has no effect for non HTML output.
Given an index hosted at: www.docs.com/base_directory/index.html
we used to generate the following link:
www.docs.com/file.html
Using --base base_directory we now generate:
www.docs.com/base_directory/file.html
This allows such links to work when hosting pages without using a custom
index.js.
The current check in writeFileDefinition() is incorrect, and prevents us
from ever emitting the URL from the clang-doc tool. The unit tests do
test this, but call the API directly circumventing the check.
This is the first step towards addressing #59814.
The implementation in the clang-doc serializer failed to take in the
LangOpts from the declaration. As a result, we'd do things like print
`_Bool` instead of `bool`, even in C++ code.
Fixes#62970
This patch improves, but doens't fully resolve the layering violation,
which stems from relying on Sema. There's one function that needs to
convert enumerator to a string (`buildQualifier` in
`FixItHintUtils.cpp`), but `Qualifiers::TQ` doesn't offer such function.
Even more, the set of enumerators is not complete compared to
`DeclSpec::TQ`, so I'm afraid that this would be a functional change.
Some `FileManager` APIs still return `{File,Directory}Entry` instead of
the preferred `{File,Directory}EntryRef`. These are documented to be
deprecated, but don't have the attribute that warns on their usage. This
PR marks them as such with `LLVM_DEPRECATED()` and replaces their usage
with the recommended counterparts. NFCI.
Part of https://github.com/llvm/llvm-project/issues/101129
This patch adds support for attaching comments to enums for HTML in
clang-doc. It changes the enum generation to table tags where as
perviously we're using lists which is more in line with what other doc
generators are doing. It also gives clang-doc the ability to show user
specified enum values
Reapply https://github.com/llvm/llvm-project/pull/94717
Adds a new option --asset which allows users to specified the asset
folder for the html output of clang-doc.
This patch adds a better test for --asset option + fixes bug where
clang-doc assumes that user supplied js file is assume to be index.js
…and operators that have non-const overloads.
This allows `unnecessary-copy-initialization` to warn on more cases.
The common case is a class with a a set of const/non-sconst overloads
(e.g. std::vector::operator[]).
```
void F() {
std::vector<Expensive> v;
// ...
const Expensive e = v[i];
}
```
Update the folder titles for targets in the monorepository that have not
seen taken care of for some time. These are the folders that targets are
organized in Visual Studio and XCode
(`set_property(TARGET <target> PROPERTY FOLDER "<title>")`)
when using the respective CMake's IDE generator.
* Ensure that every target is in a folder
* Use a folder hierarchy with each LLVM subproject as a top-level folder
* Use consistent folder names between subprojects
* When using target-creating functions from AddLLVM.cmake, automatically
deduce the folder. This reduces the number of
`set_property`/`set_target_property`, but are still necessary when
`add_custom_target`, `add_executable`, `add_library`, etc. are used. A
LLVM_SUBPROJECT_TITLE definition is used for that in each subproject's
root CMakeLists.txt.
This functionality was added about three years ago, but has been in a
significantly broken state since it was added. It has begun to cause a
maintenance burden for work in Clang (largely due to the complexity of
having two levels of code generation involved), and the original author
is unable to help maintain it. Because it only worked under limited
circumstances and because of the maintenance burden, it is being
removed. If someone wishes to resurrect the functionality, they should
hopefully be able to do so from this one commit.
Fixes#82591
The clang-query tool has the ability to execute or pre-load queries from
a file when the tool is launched, but doesn't have the ability to do the
same from the interactive REPL prompt. Because the prompt also doesn't
seem to allow multi-line matchers, this can make prototyping and
iterating on more complicated matchers difficult.
Supporting a dynamic load at REPL time allows the cost of reading the
compilation database and building the AST to be imposed just once, and
allows faster prototyping.
This uses a more systematic approach for determining whcich
`DeclRefExpr`s mutate the underlying object: Instead of using a few
matchers, we walk up the AST until we find a parent that we can prove
cannot change the underlying object.
This allows us to handle most address taking and dereference, bindings
to value and const& variables, and track constness of pointee (see
changes in DeclRefExprUtilsTest.cpp).
This allows supporting more patterns in
`performance-unnecessary-copy-initialization`.
Those two patterns are relatively common:
```
const auto e = (*vector_ptr)[i]
```
and
```
const auto e = vector_ptr->at(i);
```
In our codebase, we have around 25% additional findings from
`performance-unnecessary-copy-initialization` with this change. I did
not see any additional false positives.
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
We received some user feedback around this being disruptful rather than
useful in certain workflows so add an option to control the output behaviour.
Differential Revision: https://reviews.llvm.org/D157390
Current implementation outputs the parameter name when used with @param
(or @tparam) doxygen tag but not the comment itself.
Differential Revision: https://reviews.llvm.org/D156322
Until now when determining all the const uses of a VarDecl we only considered
how the variable itself was used. This change extends checking for const usages
of the type's members as well.
This increases the number of true positives for various performance checks that
share the same const usage analysis.
Path by Felix Berger
Reviewed By: njames93, PiotrZSL
Differential Revision: https://reviews.llvm.org/D97567
