[Lldb-commits] [PATCH] D151567: [LLVM][Support] Report EISDIR when opening a directory on AIX

2023-08-04 Thread Hubert Tong via Phabricator via lldb-commits
hubert.reinterpretcast added a comment. I believe the unit tests should be updated to ensure that we get `EISDIR` when opening directories for reading and for writing: `llvm/unittests/Support/Path.cpp`. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[Lldb-commits] [PATCH] D151567: [LLVM][Support] Report EISDIR when opening a directory on AIX

2023-08-04 Thread Hubert Tong via Phabricator via lldb-commits
hubert.reinterpretcast added inline comments. Comment at: llvm/lib/Support/Unix/Path.inc:1020 +struct stat Status; +if (stat(P.begin(), ) == -1) + return std::error_code(errno, std::generic_category()); Please try using `fstat` on the result of

[Lldb-commits] [PATCH] D151567: [LLVM][Support] Report EISDIR when opening a directory on AIX

2023-06-28 Thread Hubert Tong via Phabricator via lldb-commits
hubert.reinterpretcast added a comment. In D151567#4458232 , @hubert.reinterpretcast wrote: > @azhan92, please incorporate a revert of > https://reviews.llvm.org/rG64ca650cf9f180cc0b68c0005639028084066e10. Since it > is an `XFAIL`. once the problem is

[Lldb-commits] [PATCH] D151567: [LLVM][Support] Report EISDIR when opening a directory on AIX

2023-06-28 Thread Hubert Tong via Phabricator via lldb-commits
hubert.reinterpretcast added a comment. @azhan92, rG6ace52e5e49cff6664fc301fa4985fc28c88f26f and rGc14df228ff3ca73e3c5c00c495216bba56665fd5 should also

[Lldb-commits] [PATCH] D151567: [LLVM][Support] Report EISDIR when opening a directory on AIX

2023-06-28 Thread Hubert Tong via Phabricator via lldb-commits
hubert.reinterpretcast added a comment. @azhan92, please incorporate a revert of https://reviews.llvm.org/rG64ca650cf9f180cc0b68c0005639028084066e10. Since it is an `XFAIL`. once the problem is fixed, the test will end up being an "unexpected success" unless we remove the `XFAIL`.

[Lldb-commits] [PATCH] D76168: CPlusPlusNameParser does not handles templated operator< properly

2020-03-16 Thread Hubert Tong via Phabricator via lldb-commits
hubert.reinterpretcast added a comment. I am not sure what the usage scenario is that this is meant to support. Is it user input that tries to name a specialization of a template `operator<` without separation to prevent tokenization as `operator<<`? I think that case should qualify as user

[Lldb-commits] [PATCH] D64251: Don't depend on psutil on AIX

2019-07-05 Thread Hubert Tong via Phabricator via lldb-commits
hubert.reinterpretcast added inline comments. Comment at: llvm/utils/lit/lit/LitConfig.py:98 +self.fatal("Setting a timeout per test requires the" +" Python psutil module but it could not be" +" found.

[Lldb-commits] [PATCH] D58930: Add XCOFF triple object format type for AIX

2019-03-08 Thread Hubert Tong via Phabricator via lldb-commits
hubert.reinterpretcast added a comment. @jasonliu, you have had a number of patches committed into the project already (D22698 , D22702 , D34649 ). Please go ahead with requesting commit access,

[Lldb-commits] [PATCH] D58930: Add XCOFF triple object format type for AIX

2019-03-06 Thread Hubert Tong via Phabricator via lldb-commits
hubert.reinterpretcast added inline comments. Comment at: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp:2079 + if (log) +log->Printf("sorry: unimplemented for XCOFF"); + return false; davide wrote: >

[Lldb-commits] [PATCH] D58930: Add XCOFF triple object format type for AIX

2019-03-05 Thread Hubert Tong via Phabricator via lldb-commits
hubert.reinterpretcast added inline comments. Comment at: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp:2079 + if (log) +log->Printf("sorry: unimplemented for XCOFF"); + return false; JDevlieghere wrote: >

[Lldb-commits] [PATCH] D58930: Add XCOFF triple object format type for AIX

2019-03-04 Thread Hubert Tong via Phabricator via lldb-commits
hubert.reinterpretcast added inline comments. Comment at: llvm/lib/Support/Triple.cpp:537 return StringSwitch(EnvironmentName) +// FIXME: We have to put XCOFF before COFF; +// perhaps an order-independent pattern matching is desired? If the conclusion