[Lldb-commits] [PATCH] D152712: [lldb][Android] Use a lambda for calls to ::open in RetryAfterSignal

hans edited reviewers, added: labath; removed: hans. hans added a comment. Herald added a subscriber: JDevlieghere. +labath Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D152712/new/ https://reviews.llvm.org/D152712

[Lldb-commits] [PATCH] D151344: Reland "[CMake] Bumps minimum version to 3.20.0.

hans added a comment. This looks right to me. (I'm out of office at the moment, but this looks like what I tested in https://github.com/llvm/llvm-project/issues/62719 so it should work.) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D151344/new/ h

[Lldb-commits] [PATCH] D144509: [CMake] Bumps minimum version to 3.20.0.

hans added a comment. >>> Do you have a suggestion how we can move this patch forward? >> >> IIRC, D150688 + the diff in >> https://github.com/llvm/llvm-project/issues/62719#issuecomment-1552903385 + >> upgrading the pre-merge linux bot should take care of all

[Lldb-commits] [PATCH] D144509: [CMake] Bumps minimum version to 3.20.0.

hans added a comment. In D144509#4350052 , @Mordante wrote: > In D144509#4349921 , @thakis wrote: > >> Reverted this and follow-ups in d763c6e5e2d0a6b34097aa7dabca31e9aff9b0b6 >>

[Lldb-commits] [PATCH] D144509: [CMake] Bumps minimum version to 3.20.0.

hans added a comment. In D144509#4349399 , @mstorsjo wrote: > In D144509#4349051 , @hans wrote: > >> In D144509#4347562 , @glandium >> wrote: >> >>> FYI, 65429b9af6a2c99d

[Lldb-commits] [PATCH] D144509: [CMake] Bumps minimum version to 3.20.0.

hans added a comment. In D144509#4347562 , @glandium wrote: > FYI, 65429b9af6a2c99d340ab2dcddd41dab201f399c > is > causing problems on Windows compiler-rt for some reason I haven't id

[Lldb-commits] [PATCH] D112374: [clang] Implement ElaboratedType sugaring for types written bare

hans added a comment. Here's an example where I think this regressed a Clang diagnostic. Consider: template struct Template { Template(int x) {} }; struct S1 { struct Foo; typedef Template Typedef; }; struct S2 { struct Foo; typedef Template Typedef; }; typed

[Lldb-commits] [PATCH] D74727: Allow customized relative PYTHONHOME

hans added a comment. Herald added a project: All. In D74727#1887325 , @stella.stamenova wrote: > It looks like this broke the Windows LLDB Buildbot: > > http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/14048/steps/build/logs/stdio Seems i

[Lldb-commits] [PATCH] D123957: Update the developer policy to mention release notes

hans added a comment. Looks great to me! CHANGES SINCE LAST ACTION https://reviews.llvm.org/D123957/new/ https://reviews.llvm.org/D123957 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb

[Lldb-commits] [PATCH] D123957: Update the developer policy to mention release notes

hans added a comment. If it's possible, maybe this could be worded in a way that strongly suggests the release notes should ideally be updated in the same patch as the code change? I think we're generally good at doing this for tests. It would be great if we could treat release notes the same.

[Lldb-commits] [PATCH] D110216: [clang] retain type sugar in auto / template argument deduction

hans added a comment. Sorry, the attached file is here: F20424768: a.ii Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D110216/new/ https://reviews.llvm.org/D110216 __

[Lldb-commits] [PATCH] D110216: [clang] retain type sugar in auto / template argument deduction

hans added a comment. > I am not sure how to reproduce this. Attaching preprocessed source. With Clang built at 508aa4fe0c82b3b409e2e194d591ee6d665c8623 it reproduces for me like this: $ clang++ -c /tmp/a.ii ../../base/containers/span_unittest.cc:11:13: error: no viable conversion from 'sp

[Lldb-commits] [PATCH] D110216: [clang] retain type sugar in auto / template argument deduction

hans added a comment. We're seeing a diagnostic change in Chromium which looks funny. For the following code (span<> is our own class): int WontCompile() { const std::vector v; span s = make_span(v); } the diagnostic changes from: fatal error: no viable conversion from 'span' to

[Lldb-commits] [PATCH] D79219: [CMake] Simplify CMake handling for zlib

hans added inline comments. Comment at: llvm/cmake/config-ix.cmake:178 -if (LLVM_ENABLE_ZLIB STREQUAL "FORCE_ON" AND NOT HAVE_LIBZ) - message(FATAL_ERROR "Failed to configure zlib") Could this check be put back? E.g. for now it seems building with -DLLVM_USE_

[Lldb-commits] [PATCH] D79219: [CMake] Simplify CMake handling for zlib

hans added a comment. In D79219#2153585 , @phosek wrote: > In D79219#2152747 , @labath wrote: > >> I wouldn't mind separate (internal) cache variable, though I am somewhat >> surprised by this problem. A (non-cache

[Lldb-commits] [PATCH] D79219: [CMake] Simplify CMake handling for zlib

hans added a comment. Reverted in 3ab01550b632dad46f9595d74855749557ffd25c Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D79219/new/ https://reviews.llvm.org/D79219

[Lldb-commits] [PATCH] D84070: [LLDB] [COFF] Fix handling of symbols with more than one aux symbol

hans added a comment. In D84070#2162932 , @mstorsjo wrote: > @hans - I think this one could be a fairly safe backport to the release > branch. (Apparently phab lags behind regarding updating the reviews when they > are committed at the moment; this was c

[Lldb-commits] [PATCH] D79447: [Debug][CodeView] Emit fully qualified names for globals

hans added a comment. In D79447#2041250 , @hans wrote: > > - Added assert in `emitDebugInfoForUDTs` to ensure no lowering can occur > > during UDT emission, as suggested by @rnk > > It seems we hit the assert in Chromium. Here's a reproducer: > https://b

[Lldb-commits] [PATCH] D79447: [Debug][CodeView] Emit fully qualified names for globals

hans added a comment. > - Added assert in `emitDebugInfoForUDTs` to ensure no lowering can occur > during UDT emission, as suggested by @rnk It seems we hit the assert in Chromium. Here's a reproducer: https://bugs.chromium.org/p/chromium/issues/detail?id=1083877#c3 (I'll try to create a short

[Lldb-commits] [PATCH] D75406: Avoid including FileManager.h from SourceManager.h

hans accepted this revision. hans 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/D75406/new/ https://reviews.llvm.org/D75406 ___ lld

[Lldb-commits] [PATCH] D70764: build: reduce CMake handling for zlib

hans added a comment. There were some concerns raised on this patch, and also in PR44780. I think at this point it's safer to revert these changes and start over. I've pushed the revert in 916be8fd6a0a0feea4cefcbeb0c22c65848d7a2e

[Lldb-commits] [PATCH] D75279: Avoid SourceManager.h include in RawCommentList.h, add missing incs

hans accepted this revision. hans added a comment. Nice, lgtm! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D75279/new/ https://reviews.llvm.org/D75279 ___ lldb-commits mailing list lldb-commits@lists.

[Lldb-commits] [PATCH] D74084: [LLDB] Fix compilation with GCC 5

hans added a comment. In D74084#1861269 , @mstorsjo wrote: > @hans - this could be applied on 10.x (it seems to apply cleanly), to fix > PR44791. Thanks! Cherry-picked as 22633f85bb7d317ff97c86b6ae7817b678777d93

[Lldb-commits] [PATCH] D64881: [Cmake] Use the modern way to find Python when possible

hans added a comment. In D64881#1596920 , @labath wrote: > I think setting > -DPYTHON_EXECUTABLE=C:\Users\hwennborg\AppData\Local\Programs\Python\Python36-32\python.exe > (or something) should be enough to get cmake to select python3 for the > interpret

[Lldb-commits] [PATCH] D64881: [Cmake] Use the modern way to find Python when possible

hans added a comment. In D64881#1590204 , @amccarth wrote: > An aside ... > > I'm still trying to get back to a buildable state the earlier changes, like > the one that tries to enforce version consistency between the libs and the > interpreter. I'm cur