[PATCH] Support/Unix: use lambda function to fix building errors with clang

[Hans Wennborg via llvm-commits]

I tried building Path.cpp using Clang built from r300080, but was
unable to reproduce the problem.

I suppose the declaration of ::open must be different than on my system.

Can you send a preprocessed source file and compiler invocation that
shows the error?

On Mon, Aug 27, 2018 at 12:25 PM, Mauro Rossi <issor.oruam at gmail.com> wrote:
> Re-added Pavel, Chih-We and llvm-commits ML,
> which had erronously omitted in my previous message
>
> Mauro
>
> Il giorno lun 27 ago 2018 alle ore 12:22 Mauro Rossi
> <issor.oruam at gmail.com> ha scritto:
>>
>> Hi Hans,
>> thanks for your response
>>
>> Il giorno lun 27 ago 2018 alle ore 10:35 Hans Wennborg
>> <hans at chromium.org> ha scritto:
>> >
>> > On Sat, Aug 25, 2018 at 1:22 PM, Mauro Rossi <issor.oruam at gmail.com> wrote:
>> > > Hi Pavel,
>> > >
>> > > Il giorno mar 17 lug 2018 alle ore 08:36 Mauro Rossi
>> > > <issor.oruam at gmail.com> ha scritto:
>> > >>
>> > >> Hi Pavel,
>> > >>
>> > >> Il giorno lun 16 lug 2018 alle ore 19:14 Pavel Labath <labath at google.com> ha scritto:
>> > >>>
>> > >>> I think all/most systems have open(2) defined as a variadic (...)
>> > >>> function, so that can't be the only reason why this is failing for
>> > >>> you. There must be something more which is specific to your platform.
>> > >>> Nevertheless, the workaround is not bad, so there's no harm in
>> > >>>
>> > >>> changing this. Some people would even prefer the lambda based syntax.
>> > >>
>> > >>
>> > >> We are using basically the same Build System/compilers of AOSP,
>> > >> it seam that just using clang can produce the error because of behavior different from gcc.
>> > >> In some comments in the web behaviors of gcc and clang were described as different.
>> > >>
>> > >> If you are also using clang, are you using the clang version with AOSP (8.1.0_r33 at the time of reporting)
>> > >> I propose to check in order to identify root cause, then evaluate how to proceed.
>> > >>
>> > >> Mauro
>> > >
>> > > The building error is happening using default AOSP 8.1.0_r41 clang tool chain
>> >
>> > Can you print the "clang --version" output of that toolchain? If we
>> > fix this, it would be good to put a comment about what compiler was
>> > having a problem.
>>
>> As seen from build log this is the clang version (also used by AOSP,
>> if I'm not wrong):
>>
>> maurossi at ANDROIDDEV:~/oreo-x86_kernel$
>> prebuilts/clang/host/linux-x86/clang-4053586/bin/clang --version
>> Android clang version 5.0.300080  (based on LLVM 5.0.300080)
>> Target: x86_64-unknown-linux
>> Thread model: posix
>> InstalledDir: /home/maurossi/oreo-x86_kernel/prebuilts/clang/host/linux-x86/clang-4053586/bin
>>
>>
>> >
>> > > If you don't see drawbacks, would it be possible to queue the patch
>> > > that solves the building problem
>> > > as candidate for llvm 7.0rc3?
>> > > This would prevent building issues for AOSP current and future Android releases
>> > >
>> > > After your feedback, I am adding Hans Wennborg to evaluate if the
>> > > patch is an acceptable candidate for llvm 7.0rc3
>> >
>> > I'm OK with this, but the patch would have to land soon.
>>
>> The patch was sent on llvm-commits mailing list on July, 8th 2018,
>> it can be applied in current release_70 branch as cherry-pick is working for me:
>>
>> http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20180702/567254.html
>>
>> Could you please modify the final commit message with clang version
>> information provided?
>> Thanks
>>
>> Kind regards
>> Mauro
>>
>>
>>
>>
>> >
>> > Thanks,
>> > Hans