[PATCH] D59555: [analyzer] Add yaml parser to GenericTaintChecker

2019-08-13 Thread Alex Langford via Phabricator via cfe-commits
xiaobai added inline comments. Comment at: cfe/trunk/lib/StaticAnalyzer/Checkers/GenericTaintChecker.cpp:74 +TaintConfiguration() = default; +TaintConfiguration(const TaintConfiguration &) = delete; +TaintConfiguration(TaintConfiguration &&) = default; ---

[PATCH] D66192: [analyzer] Don't delete TaintConfig copy constructor

2019-08-13 Thread Alex Langford via Phabricator via cfe-commits
xiaobai created this revision. xiaobai added reviewers: compnerd, Szelethus, boga95, NoQ, alexshap. Herald added subscribers: Charusso, dkrupp, donat.nagy, mikhail.ramalho, a.sidorin, szepet, baloghadamsoftware, xazax.hun. Herald added a project: clang. Explicitly deleting the copy constructor ma

[PATCH] D66192: [analyzer] Don't delete TaintConfig copy constructor

2019-08-13 Thread Alex Langford via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes. Closed by commit rL368779: [analyzer] Don't delete TaintConfig copy constructor (authored by xiaobai, committed by ). Herald added a project: LLVM. Changed prior to commit: https://reviews.llvm.org/D66192?vs=214998&id=214

[PATCH] D66265: [NFCI] Always initialize BugReport const fields

2019-08-14 Thread Alex Langford via Phabricator via cfe-commits
xiaobai created this revision. xiaobai added reviewers: compnerd, Szelethus, NoQ. Herald added a project: clang. Some compilers require that const fields of an object must be explicitly initialized by the constructor. I ran into this issue building with clang 3.8 on Ubuntu 16.04. Repository: r

[PATCH] D66265: [NFCI] Always initialize BugReport const fields

2019-08-14 Thread Alex Langford via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes. Closed by commit rL368950: [NFCI] Always initialize BugReport const fields (authored by xiaobai, committed by ). Herald added a project: LLVM. Changed prior to commit: https://reviews.llvm.org/D66265?vs=215292&id=215299#t

[PATCH] D122691: [clang][Sema] Add flag to LookupName to force C/ObjC codepath

2022-03-29 Thread Alex Langford via Phabricator via cfe-commits
bulbazord created this revision. bulbazord added a reviewer: arphaman. Herald added a project: All. bulbazord requested review of this revision. Herald added a project: clang. Herald added a subscriber: cfe-commits. Motivation: The intent here is for use in Swift. When building a clang module for

[PATCH] D121748: [clang][Sema] Better support for ObjC++ in Sema::LookupName

2022-03-15 Thread Alex Langford via Phabricator via cfe-commits
bulbazord created this revision. bulbazord added a reviewer: arphaman. Herald added a project: All. bulbazord requested review of this revision. Herald added a project: clang. `Sema::LookupName` essentially has two possible code paths based on what language is currently being used. The predicate s

[PATCH] D121748: [clang][Sema] Better support for ObjC++ in Sema::LookupName

2022-03-15 Thread Alex Langford via Phabricator via cfe-commits
bulbazord added a comment. I'm not quite sure the best way to test this. Looks like `Sema::LookupName` isn't currently directly tested. I've run the test suite and did not find any new failing tests. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D1

[PATCH] D121748: [clang][Sema] Better support for ObjC++ in Sema::LookupName

2022-03-16 Thread Alex Langford via Phabricator via cfe-commits
bulbazord added a comment. In D121748#3384357 , @arphaman wrote: > Is there a Swift-based test case you have that demonstrates the original > problem from Swift's clang importer side? I'm curious to see where it > manifests in Swift. % cat Test.h

[PATCH] D121748: [clang][Sema] Better support for ObjC++ in Sema::LookupName

2022-03-21 Thread Alex Langford via Phabricator via cfe-commits
bulbazord added a comment. In D121748#3397715 , @arphaman wrote: > I don't think this patch is sound. I found this problem with this change when > the following file is compiled in Objective-C++ mode: > > template > T umax(T a, T b) { > return a

[PATCH] D122691: [clang][Sema] Add flag to LookupName to force C/ObjC codepath

2022-04-18 Thread Alex Langford via Phabricator via cfe-commits
bulbazord updated this revision to Diff 423437. bulbazord edited the summary of this revision. bulbazord added a comment. Herald added a subscriber: mgorny. Added a test CHANGES SINCE LAST ACTION https://reviews.llvm.org/D122691/new/ https://reviews.llvm.org/D122691 Files: clang/include/cl

[PATCH] D122691: [clang][Sema] Add flag to LookupName to force C/ObjC codepath

2022-04-19 Thread Alex Langford via Phabricator via cfe-commits
bulbazord closed this revision. bulbazord added a comment. Gah, forgot to add the phabricator link to the commit message. I added the commit object to this diff, hopefully people can track it down the review if needed. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D122691/new/ https://

[PATCH] D134911: [clang][DebugInfo] Respect fmodule-file-home-is-cwd in skeleton CUs for clang modules

2022-09-29 Thread Alex Langford via Phabricator via cfe-commits
bulbazord created this revision. bulbazord added reviewers: rmaz, aprantl. Herald added a project: All. bulbazord requested review of this revision. Herald added a project: clang. Herald added a subscriber: cfe-commits. When `-fmodule-file-home-is-cwd` and the path to the PCM is relative, we shou

[PATCH] D134911: [clang][DebugInfo] Respect fmodule-file-home-is-cwd in skeleton CUs for clang modules

2022-10-04 Thread Alex Langford via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes. Closed by commit rG266ec801fb23: [clang][DebugInfo] Respect fmodule-file-home-is-cwd in skeleton CUs for clang… (authored by bulbazord). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llv

[PATCH] D157497: feat: Migrate isArch16Bit

2023-08-14 Thread Alex Langford via Phabricator via cfe-commits
bulbazord added a comment. In D157497#4586165 , @MaskRay wrote: > In D157497#4584621 , @Pivnoy wrote: > >> This discussion was the main motivation for this change. >> https://discourse.llvm.org/t/rfc-refactor-trip

[PATCH] D157497: feat: Migrate isArch16Bit

2023-08-22 Thread Alex Langford via Phabricator via cfe-commits
bulbazord requested changes to this revision. bulbazord added a comment. In D157497#4592330 , @Pivnoy wrote: > At the moment, the TargetParser architecture is extensible. This complicates > the addition of new architectures, operating systems, and so on.

[PATCH] D71585: [perf-training] Change profile file pattern string to use %4m instead of %p

2019-12-17 Thread Alex Langford via Phabricator via cfe-commits
xiaobai added a reviewer: vsk. xiaobai added a subscriber: vsk. xiaobai added a comment. Adding @vsk since he added the code that you're referencing in your summary. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D71585/new/ https://reviews.llvm.org/

[PATCH] D71585: [perf-training] Change profile file pattern string to use %4m instead of %p

2019-12-17 Thread Alex Langford via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes. Closed by commit rGb3f789e037cb: [perf-training] Change profile file pattern string to use %4m instead of %p (authored by xinxinw1, committed by xiaobai). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION h

[PATCH] D146595: [clang] Add clang trampoline_mangled_target attribute

2023-03-24 Thread Alex Langford via Phabricator via cfe-commits
bulbazord added a comment. I had one question about this: I think through the comments you've made it quite clear that the intent is for this to be used by compiler-generated code (i.e. "tooling"). Given that even tools have bugs, what does the debugging/remediation story look like when a tool