[Lldb-commits] [lldb] r325666 - Fix TestAppleTypesIsProduced after r324226

Davide Italiano via lldb-commits lldb-commits at lists.llvm.org
Thu Feb 22 17:36:28 PST 2018

On Wed, Feb 21, 2018 at 10:52 AM, Davide Italiano <dccitaliano at gmail.com> wrote:
> On Tue, Feb 20, 2018 at 10:20 PM, Frederic Riss via lldb-commits
> <lldb-commits at lists.llvm.org> wrote:
>> Author: friss
>> Date: Tue Feb 20 22:20:03 2018
>> New Revision: 325666
>> URL: http://llvm.org/viewvc/llvm-project?rev=325666&view=rev
>> Log:
>> Fix TestAppleTypesIsProduced after r324226
>> This test was accessing self.debug_info, which doesn't exist anymore. For
>> some reason the macOS bots are skipping this test because they think the
>> compiler is not clang. We'll look into this separately.
> I stumbled upon something similar this morning so I decided to take a look.
> The reason why this fails is that the test run is conditional to:
>         if not self.getCompiler().endswith('clang'):
> If you run with an in-tree clang, you might end up with getCompiler()
> returning:
> /Users/davide/work/llvm-monorepo/build/bin/clang-7.0
> which fails the check.
> The reason why you're seeing this only locally is maybe because you're
> running with the clang provided by the system instead of the one provided
> in-tree.
> The mismatch has been a cause of headache for me in the past already.
> Regardless, the way this test was setup was good to understand this mistake
> (so we should probably audit all the tests looking for this pattern), but I
> have my concerns about the place where the test is located.
> The program is just making sure clang emits the correct sections, so we
> might consider moving this test to clang.

I went ahead, wrote the clang test, and removed the lldb one.

r325850 - [Darwin] Add a test to check clang produces accelerator tables.
& r325851.



More information about the lldb-commits mailing list