Paul Robinson correctly pointed out this test was end-to-end so it
really didn't belong to clang.
After discussing with Adrian, I moved the test to the debuginfo-test
suite in rL325928.
We should be all set now.
On Thu, Feb 22, 2018 at 5:36 PM, Davide Italiano <dccitali...@gmail.com> wrote:
> On Wed, Feb 21, 2018 at 10:52 AM, Davide Italiano <dccitali...@gmail.com>
>> On Tue, Feb 20, 2018 at 10:20 PM, Frederic Riss via lldb-commits
>> <email@example.com> 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
>>> 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()
>> 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
>> 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.
lldb-commits mailing list