[Lldb-commits] [PATCH] D112439: normalize file path when searching the source map

Xu Jun via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Tue Nov 2 04:50:40 PDT 2021


xujuntwt95329 added a comment.

In D112439#3102600 <https://reviews.llvm.org/D112439#3102600>, @teemperor wrote:

> In D112439#3102559 <https://reviews.llvm.org/D112439#3102559>, @xujuntwt95329 wrote:
>
>> In D112439#3102548 <https://reviews.llvm.org/D112439#3102548>, @teemperor wrote:
>>
>>> In D112439#3102533 <https://reviews.llvm.org/D112439#3102533>, @xujuntwt95329 wrote:
>>>
>>>> In D112439#3102506 <https://reviews.llvm.org/D112439#3102506>, @teemperor wrote:
>>>>
>>>>> In D112439#3098307 <https://reviews.llvm.org/D112439#3098307>, @xujuntwt95329 wrote:
>>>>>
>>>>>> Seems that patch can't build by CI because it is based on this patch. In my understanding we need to merge this patch firstly and rebase that NFC patch to let CI work, right?
>>>>>
>>>>> You can set parent/child revisions in Phabricator that should handle this situation (not sure if the premerge-checks are respecting that, but that's how Phab usually manages unmerged dependencies).
>>>>>
>>>>> But to be clear, the premerge checks on Phabricator are *not* building or testing LLDB at all. See the CI log:
>>>>>
>>>>>   INFO    projects: {'lldb'}
>>>>>   INFO    all excluded projects(*) {'check-cxxabi', 'flang', 'libunwind', 'compiler-rt', 'cross-project-tests', 'libcxx', 'libcxxabi', 'libc', 'openmp', 'lldb'}
>>>>>   INFO    effective projects list set()
>>>>
>>>> Thanks a lot for the detailed information!
>>>>
>>>> BTW, I see there are some test failure reported by CI, but I can't reproduce them in my local environment (X86_64 Ubuntu and Windows), is there any docker images to simulate the CI environment?
>>>
>>> Can you try a Release + Assert build? I'm looking at the failures at the moment too and it seems to only fail in non-Debug builds.
>>
>> Sure, I'll try the `release + assert` build. Thanks again!
>
> Actually the solution seems pretty straightforward. `ArrayRef<FileSpec> fails{ ...` is not actually extending the lifetime or copying the initializer list you're passing. You have to use a std::vector or something similar to actually store the FileSpecs (right now they are being destroyed before the `TestFileFindings` call).
>
> I'll go ahead and push a fix that just uses a std::vector.

You are right, thanks a lot!

Interestingly, I can't reproduce this problem even with release + assert build in my local environment


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D112439/new/

https://reviews.llvm.org/D112439



More information about the lldb-commits mailing list