[PATCH] D87062: [DebugInfo] Add size to class declarations in debug info.

2020-09-03 Thread Amy Huang via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rGaaf1a96408b1: [DebugInfo] Add size to class declarations in debug info. (authored by akhuang). Repository: rG LLVM Github Monorepo CHANGES SINCE

[PATCH] D87066: Thread safety analysis: Improve documentation for scoped capabilities

2020-09-03 Thread Aaron Puchert via Phabricator via cfe-commits
aaronpuchert updated this revision to Diff 289826. aaronpuchert marked an inline comment as done. aaronpuchert added a comment. - More detailed description how scoped capabilities work. - Make the comment wording more consistent with existing comments and the previous explanation. - Properly impl

[libunwind] 673484b - [libunwind] Minor SJLJ config cleanup. NFCI.

2020-09-03 Thread Ryan Prichard via cfe-commits
Author: Ryan Prichard Date: 2020-09-03T15:59:45-07:00 New Revision: 673484b34189b1bccf73a2ec96968092bc8a26a7 URL: https://github.com/llvm/llvm-project/commit/673484b34189b1bccf73a2ec96968092bc8a26a7 DIFF: https://github.com/llvm/llvm-project/commit/673484b34189b1bccf73a2ec96968092bc8a26a7.diff

[PATCH] D84364: [CUDA][HIP] Defer overloading resolution diagnostics for host device functions

2020-09-03 Thread Artem Belevich via Phabricator via cfe-commits
tra added a comment. LGTM. Nice! To sum it up -- the patch introduces `-fgpu-defer-diag` flag which allows deferring overload resolution diagnostics, if overload set included candidates from both sides. We may be deferring cases when we don't have to (e.g. `df()->()callee2()` should've err

[PATCH] D84604: Thread safety analysis: Consider global variables in scope

2020-09-03 Thread Aaron Puchert via Phabricator via cfe-commits
aaronpuchert added inline comments. Comment at: clang/test/SemaCXX/warn-thread-safety-negative.cpp:87 +Mutex globalMutex; +void f() EXCLUSIVE_LOCKS_REQUIRED(!globalMutex); + aaron.ballman wrote: > Can you add a test that uses `!::globalMutex`? I'd like to verify

[PATCH] D84604: Thread safety analysis: Consider global variables in scope

2020-09-03 Thread Aaron Puchert via Phabricator via cfe-commits
aaronpuchert updated this revision to Diff 289833. aaronpuchert marked 2 inline comments as done. aaronpuchert added a comment. Add tests with qualified names, let tests rely on shadowing. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D84604/new/ ht

[PATCH] D87118: Add an explicit toggle for the static analyzer in clang-tidy

2020-09-03 Thread Nico Weber via Phabricator via cfe-commits
thakis created this revision. thakis added a reviewer: hans. Herald added subscribers: llvm-commits, ASDenysPetrov, dkrupp, donat.nagy, Szelethus, a.sidorin, baloghadamsoftware, mgorny. Herald added a project: LLVM. thakis requested review of this revision. Instead of using CLANG_ENABLE_STATIC_AN

[PATCH] D84364: [CUDA][HIP] Defer overloading resolution diagnostics for host device functions

2020-09-03 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl marked an inline comment as done. yaxunl added a comment. In D84364#2255572 , @tra wrote: > LGTM. > > Nice! > > To sum it up -- the patch introduces `-fgpu-defer-diag` flag which allows > deferring overload resolution diagnostics, if overload set

[PATCH] D86049: RFC: Implement optional exportable wrapper function generation for objc_direct methods.

2020-09-03 Thread Puyan Lotfi via Phabricator via cfe-commits
plotfi added a comment. In D86049#2253705 , @plotfi wrote: > I've updated the diff to reflect the alternate non-wrapper exposure. This way > requires the sanitizing of the exported objc_direct method name. @rjmccall Is there a process for discussing ABI

[PATCH] D86841: [clang] Add noprogress attribute deduction for infinite loops

2020-09-03 Thread Atmn Patel via Phabricator via cfe-commits
atmnpatel updated this revision to Diff 289849. atmnpatel added a comment. In Summary: - I changed the llvm loop metadata name to `mustprogress`, to indicate that loops with this attribute are required to have side-effects. - The `mayprogress` function attribute is applied to functions where an

[PATCH] D86049: RFC: Implement optional exportable wrapper function generation for objc_direct methods.

2020-09-03 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment. We just talk about it. I agree with Nathan that we shouldn't just add this as a short-term hack; we should design the ABI right and then do what we want. I think these are basically all the ABI questions: - Is there a good reason to preserve signature compatibility wi

[PATCH] D80344: [Windows SEH]: HARDWARE EXCEPTION HANDLING (MSVC -EHa) - Part 1

2020-09-03 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment. I've made some brief comments about the code, but I think I have much larger concerns here. The first is whether LLVM really intends to satisfy the constraints necessary to make these exceptions work, which I don't think you've gotten clear consensus about at all. Un

[PATCH] D85596: [Docs] Fix --print-supported-cpus option rendering

2020-09-03 Thread Travis Finkenauer via Phabricator via cfe-commits
tmfink accepted this revision. tmfink added a comment. @nickdesaulniers, could you merge my patch? I don't have commit access. Thanks! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D85596/new/ https://reviews.llvm.org/D85596 ___

[PATCH] D86921: [FPEnv] Partially implement #pragma STDC FENV_ROUND

2020-09-03 Thread John McCall via Phabricator via cfe-commits
rjmccall accepted this revision. rjmccall added a comment. This revision is now accepted and ready to land. LGTM Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D86921/new/ https://reviews.llvm.org/D86921 _

[PATCH] D85473: [Clang] Add option to allow marking pass-by-value args as noalias.

2020-09-03 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment. Is it acceptable to leave this as a -cc1 option while we're pursuing this with the language committee? Do we have any intent to pursue this with the language committee? Comment at: clang/include/clang/Basic/LangOptions.def:372 +LANGOPT(PassByValueIs

<    1   2