[PATCH] Some code improvements (no functional change)

Duncan P. N. Exon Smith dexonsmith at apple.com
Thu Jun 12 08:38:27 PDT 2014

> On 2014 May 29, at 03:41, Artyom Skrobov <Artyom.Skrobov at arm.com> wrote:
>> It seems wrong to me that you're including regex2.h, as it looks like
> private
>> implementation details for the BSD regex code.  Adding include guards
> makes
>> the headers look less like shared (but private) implementation details and
>> more like public interfaces -- that's misleading to anyone reading the
> code.
>> I still think these should be left as is, as the current setup discourages
>> anyone from including them.
> Curiously enough, lib/Support/regex_impl.h is (and has always been) guarded
> by #ifndef _REGEX_H_ -- that's although the header's own name indicates it's
> a part of the implementation, and not an interface (public nor private).
> I've tried, and removing that guard doesn't have any effect on LLVM
> compilation; I can conclude that the historic (non-)usage of include guards
> in the regex headers isn't consistent enough to be taken as a guidance. 
> Out of the 395 headers in lib/, supposedly none of them belonging to LLVM
> public interface, 384 do have re-include guards, and only 11 don't (that's
> lib/Support/Windows/WindowsSupport.h lib/Target/ARM/ARMPerfectShuffle.h
> lib/Target/ARM64/ARM64PerfectShuffle.h
> lib/Target/Hexagon/HexagonVarargsCallingConvention.h
> lib/Target/NVPTX/NVPTXMachineFunctionInfo.h
> lib/Target/PowerPC/PPCPerfectShuffle.h and the 4 regex headers in question)
> -- I think this shows a prominent tendency to have such guards in private
> headers.

Good point.  SGTM.

Go ahead and add the guards if you have commit privileges, otherwise
please repost the patch here and I'll commit it for you.

More information about the llvm-commits mailing list