| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[clang] Use SmallString::operator std::string (NFC) | 2 年前 | |
[clang] NFCI: Use FileEntryRef for FileID creation (#67838) This patch removes the SourceManager APIs that create FileID from a const FileEntry * in favor of APIs that take FileEntryRef. This also removes a misleading documentation that claims nullptr file entry represents stdin. I don't think that's right, since we just try to dereference that pointer anyways. | 2 年前 | |
| 2 年前 | ||
Adjust MSVC version range for ARM64 build performance regression (#90731) This is follow up for #65215 Mentioned regression was fixed in MSVC 19.39 (VS 17.9.0), so it makes sense to not apply fix for that (and newer) compiler versions. Same as original change, this patch is narrowly scoped to not affect any other compiler. | 1 年前 | |
[clang][NFC] Trim license header comments to 81 characters (#82919) clang-format would format these headers poorly by splitting it into multiple lines. | 2 年前 | |
[clangd] Fix crash with null check for Token at Loc (#94528) Fixes https://github.com/llvm/llvm-project/issues/94599 | 2 年前 | |
[clang] Avoid 'raw_string_ostream::str' (NFC) Since raw_string_ostream doesn't own the string buffer, it is desirable (in terms of memory safety) for users to directly reference the string buffer rather than use raw_string_ostream::str(). Work towards TODO comment to remove raw_string_ostream::str(). | 1 年前 | |
Rename llvm::ThreadPool -> llvm::DefaultThreadPool (NFC) (#83702) The base class llvm::ThreadPoolInterface will be renamed llvm::ThreadPool in a subsequent commit. This is a breaking change: clients who use to create a ThreadPool must now create a DefaultThreadPool instead. | 2 年前 | |
[clang] Use StringRef::{starts,ends}_with (NFC) (#75149) 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. | 2 年前 | |
[clang-scan-deps] Infer the tool locations from PATH (#108539) This allows the clang driver to know which tool is meant to be executed, which allows the clang driver to load the right clang config files, and allows clang to find colocated sysroots. This makes sure that doing clang-scan-deps -- <tool> ... looks up things in the same way as if one just would execute <tool> ..., when <tool> isn't an absolute or relative path. (cherry picked from commit a26ec542371652e1d774696e90016fd5b0b1c191) | 1 年前 | |
CommandLine: add and use cl::SubCommand::get{All,TopLevel} Prefer using these accessors to access the special sub-commands corresponding to the top-level (no subcommand) and all sub-commands. This is a preparatory step towards removing the use of ManagedStatic: with a subsequent change, these global instances will be moved to be regular function-scope statics. It is split up to give downstream projects a (albeit short) window in which they can switch to using the accessors in a forward-compatible way. Differential Revision: https://reviews.llvm.org/D129118 | 3 年前 | |
[clang] Use SmallString::operator std::string (NFC) | 2 年前 | |
[NFC] Refactor Registry loops to range for | 5 年前 | |
[clangd] Move standard options adaptor to CommandMangler There is a discrepancy between how clangd processes CDB loaded from JSON file on disk and pushed via LSP. Thus the same CDB pushed via LSP protocol may not work as expected. Some difference between these two paths is expected but we still need to insert driver mode and target from binary name and expand response files. Test Plan: check-clang-tools Differential Revision: https://reviews.llvm.org/D143436 | 3 年前 | |
[clang][Tooling] Try to avoid file system access if there is no record for the file in compile_commads.json Summary: If there is no record in compile_commands.json, we try to find suitable record with MatchTrie.findEquivalent() call. This is very expensive operation with a lot of llvm::sys::fs::equivalent() calls in some cases. This patch disables file symlinks for performance reasons. Example scenario without this patch: - compile_commands.json generated at clangd build (contains ~3000 files). - it tooks more than 1 second to get compile command for newly created file in the root folder of LLVM project. - we wait for 1 second every time when clangd requests compile command for this file (at file change). Reviewers: sammccall, kadircet, hokein Reviewed By: sammccall Subscribers: chandlerc, djasper, klimek, ilya-biryukov, kadircet, usaxena95, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D83621 | 5 年前 | |
[LibTooling] Add "SourceCode" library for functions relating to source-code manipulation. Summary: Introduces a utility library in Refactoring/ to collect routines related to source-code manipulation. In this change, we move "extended-range" functions from the FixIt library (in clangTooling) to this new library. We need to use this functionality in Refactoring/ and cannot access it if it resides in Tooling/, because that would cause clangToolingRefactor to depend on clangTooling, which would be a circular dependency. Reviewers: ilya-biryukov, ioeric Reviewed By: ilya-biryukov Subscribers: mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D60269 llvm-svn: 357764 | 7 年前 | |
[Clang] Migrate llvm::make_unique to std::make_unique Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. Differential revision: https://reviews.llvm.org/D66259 llvm-svn: 368942 | 6 年前 | |
[Driver] Refactor to use llvm Option's new Visibility flags This is a big refactor of the clang driver's option handling to use the Visibility flags introduced in https://reviews.llvm.org/D157149. There are a few distinct parts, but they can't really be split into separate commits and still be made to compile. 1. We split out some of the flags in ClangFlags to ClangVisibility. Note that this does not include any subtractive flags. 2. We update the Flag definitions and OptIn/OptOut constructs in Options.td by hand. 3. We introduce and use a script, update_options_td_flags, to ease migration of flag definitions in Options.td, and we run that on Options.td. I intend to remove this later, but I'm committing it so that downstream forks can use the script to simplify merging. 4. We update calls to OptTable in the clang driver, cc1as, flang, and clangd to use the visibility APIs instead of Include/Exclude flags. 5. We deprecate the Include/Exclude APIs and add a release note. *if you are running into conflicts with this change:* Note that https://reviews.llvm.org/D157150 may also be the culprit and if so it should be handled first. The script in clang/utils/update_options_td_flags.py can help. Take the downstream side of all conflicts and then run the following: % cd clang/include/clang/Driver % ../../../utils/update_options_td_flags.py Options.td > Options.td.new % mv Options.td.new Options.td This will hopefully be sufficient, please take a look at the diff. Differential Revision: https://reviews.llvm.org/D157151 | 2 年前 | |
remove goma support from clang (#93942) goma is deprecated and not maintained anymore. https://chromium.googlesource.com/infra/goma/client/ | 2 年前 | |
[clang-scan-deps] Infer the tool locations from PATH (#108539) This allows the clang driver to know which tool is meant to be executed, which allows the clang driver to load the right clang config files, and allows clang to find colocated sysroots. This makes sure that doing clang-scan-deps -- <tool> ... looks up things in the same way as if one just would execute <tool> ..., when <tool> isn't an absolute or relative path. (cherry picked from commit a26ec542371652e1d774696e90016fd5b0b1c191) | 1 年前 | |
[clang] NFCI: Use FileEntryRef for FileID creation (#67838) This patch removes the SourceManager APIs that create FileID from a const FileEntry * in favor of APIs that take FileEntryRef. This also removes a misleading documentation that claims nullptr file entry represents stdin. I don't think that's right, since we just try to dereference that pointer anyways. | 2 年前 | |
Make llvm::StringRef to std::string conversions explicit. This is how it should've been and brings it more in line with std::string_view. There should be no functional change here. This is mostly mechanical from a custom clang-tidy check, with a lot of manual fixups. It uncovers a lot of minor inefficiencies. This doesn't actually modify StringRef yet, I'll do that in a follow-up. | 6 年前 | |
[Clang] Migrate llvm::make_unique to std::make_unique Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. Differential revision: https://reviews.llvm.org/D66259 llvm-svn: 368942 | 6 年前 | |
[clang] Use StringRef::operator== instead of StringRef::equals (NFC) (#91844) I'm planning to remove StringRef::equals in favor of StringRef::operator==. - StringRef::operator==/!= outnumber StringRef::equals by a factor of 24 under clang/ in terms of their usage. - The elimination of StringRef::equals brings StringRef closer to std::string_view, which has operator== but not equals. - S == "foo" is more readable than S.equals("foo"), especially for !Long.Expression.equals("str") vs Long.Expression != "str". | 2 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 5 年前 | ||
| 7 年前 | ||
| 6 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 6 年前 | ||
| 6 年前 | ||
| 2 年前 |