Re: [PATCH] D31702: Append -w when LLVM_ENABLE_WARNINGS is Off.

[Sean Silva via cfe-commits]

Can we revert this?

In our downstream project we were bitten by this:
https://github.com/google/mlir-npcomp/commit/cd7258dbd48bd9254c6741cab2d3f4e36cbd3c84

It seems that now by default anybody that depends on LLVM with CMake will
globally get a `-w` passed to their compiler. That doesn't seem like good
behavior.

-- Sean Silva

On Wed, Apr 12, 2017 at 1:56 PM Vassil Vassilev via Phabricator via
llvm-commits  wrote:

> v.g.vassilev closed this revision.
> v.g.vassilev added a comment.
>
> Landed in r300100.
>
>
> https://reviews.llvm.org/D31702
>
>
>
> ___
> llvm-commits mailing list
> llvm-comm...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r284137 - [ThinLTO] Update doc to include lld (now supported).

[Sean Silva via cfe-commits]

Nice to see this land!

One nit:
Currently, doesn't LLD/ELF ignore -plugin-opt? That will mean that if a
user uses the "gold syntax" then LLD will silently ignore it, which isn't
good. At the very least, can we issue an error if we see `-plugin-opt
jobs=N` and suggest the LLD spelling?

Or maybe just accept the gold syntax? Our current handling of `-plugin` and
`-plugin-opt` is intended to make LLD transparently Do The Right Thing when
LLD is invoked as if it were gold, so clearly gold compatibility is
important enough for that. This suggests it is important enough to be
compatible from a ThinLTO perspective too.

-- Sean Silva

On Thu, Oct 13, 2016 at 10:42 AM, Davide Italiano via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: davide
> Date: Thu Oct 13 12:42:38 2016
> New Revision: 284137
>
> URL: http://llvm.org/viewvc/llvm-project?rev=284137&view=rev
> Log:
> [ThinLTO] Update doc to include lld (now supported).
>
> Differential Revision:  https://reviews.llvm.org/D25537
>
> Modified:
> cfe/trunk/docs/ThinLTO.rst
>
> Modified: cfe/trunk/docs/ThinLTO.rst
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/
> ThinLTO.rst?rev=284137&r1=284136&r2=284137&view=diff
> 
> ==
> --- cfe/trunk/docs/ThinLTO.rst (original)
> +++ cfe/trunk/docs/ThinLTO.rst Thu Oct 13 12:42:38 2016
> @@ -62,8 +62,8 @@ ThinLTO is currently supported for the f
>`_.
>  - **ld64**:
>Starting with `Xcode 8 `_.
> -
> -Additionally, support is being added to the *lld* linker.
> +- **lld**:
> +  Starting with r284050 (ELF only).
>
>  Usage
>  =
> @@ -109,6 +109,8 @@ be reduced to ``N`` via:
>``-Wl,-plugin-opt,jobs=N``
>  - ld64:
>``-Wl,-mllvm,-threads=N``
> +- lld:
> +  ``-Wl,--thinlto-jobs=N``
>
>  Incremental
>  ---
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r290792 - [c++17] Implement P0522R0 as written. This allows a template template argument

[Sean Silva via cfe-commits]

On Sat, Dec 31, 2016 at 1:41 PM, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rsmith
> Date: Sat Dec 31 15:41:23 2016
> New Revision: 290792
>
> URL: http://llvm.org/viewvc/llvm-project?rev=290792&view=rev
> Log:
> [c++17] Implement P0522R0 as written. This allows a template template
> argument
> to be specified for a template template parameter whenever the parameter
> is at
> least as specialized as the argument (when there's an obvious and correct
> mapping from uses of the parameter to uses of the argument). For example, a
> template with more parameters can be passed to a template template
> parameter
> with fewer, if those trailing parameters have default arguments.
>
> This is disabled by default, despite being a DR resolution, as it's fairly
> broken in its current state: there are no partial ordering rules to cope
> with
> template template parameters that have different parameter lists, meaning
> that
> code that attempts to decompose template-ids based on arity can hit
> unavoidable
> ambiguity issues.
>
> The diagnostics produced on a non-matching argument are also pretty bad
> right
> now, but I aim to improve them in a subsequent commit.
>
> Added:
> cfe/trunk/test/SemaTemplate/temp_arg_template_cxx1z.cpp
> Modified:
> cfe/trunk/include/clang/Basic/LangOptions.def
> cfe/trunk/include/clang/Driver/Options.td
> cfe/trunk/include/clang/Sema/Sema.h
> cfe/trunk/lib/Driver/Tools.cpp
> cfe/trunk/lib/Frontend/CompilerInvocation.cpp
> cfe/trunk/lib/Sema/SemaTemplate.cpp
> cfe/trunk/lib/Sema/SemaTemplateDeduction.cpp
> cfe/trunk/test/SemaTemplate/temp_arg_template.cpp
> cfe/trunk/www/cxx_status.html
>
> Modified: cfe/trunk/include/clang/Basic/LangOptions.def
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/Basic/LangOptions.def?rev=290792&r1=290791&r2=290792&view=diff
> 
> ==
> --- cfe/trunk/include/clang/Basic/LangOptions.def (original)
> +++ cfe/trunk/include/clang/Basic/LangOptions.def Sat Dec 31 15:41:23 2016
> @@ -134,6 +134,7 @@ LANGOPT(NoBuiltin , 1, 0, "disab
>  LANGOPT(NoMathBuiltin , 1, 0, "disable math builtin functions")
>  LANGOPT(GNUAsm, 1, 1, "GNU-style inline assembly")
>  LANGOPT(CoroutinesTS  , 1, 0, "C++ coroutines TS")
> +LANGOPT(RelaxedTemplateTemplateArgs, 1, 0, "C++17 relaxed matching of
> tempalte template arguments")
>

Typo: tempalte

-- Sean Silva


>
>  BENIGN_LANGOPT(ThreadsafeStatics , 1, 1, "thread-safe static
> initializers")
>  LANGOPT(POSIXThreads  , 1, 0, "POSIX thread support")
>
> Modified: cfe/trunk/include/clang/Driver/Options.td
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/Driver/Options.td?rev=290792&r1=290791&r2=290792&view=diff
> 
> ==
> --- cfe/trunk/include/clang/Driver/Options.td (original)
> +++ cfe/trunk/include/clang/Driver/Options.td Sat Dec 31 15:41:23 2016
> @@ -1088,6 +1088,11 @@ def fapplication_extension : Flag<["-"],
>HelpText<"Restrict code to those available for App Extensions">;
>  def fno_application_extension : Flag<["-"], "fno-application-extension">,
>Group;
> +def frelaxed_template_template_args : Flag<["-"],
> "frelaxed-template-template-args">,
> +  Flags<[CC1Option]>, HelpText<"Enable C++17 relaxed template template
> argument matching">,
> +  Group;
> +def fno_relaxed_template_template_args : Flag<["-"],
> "fno-relaxed-template-template-args">,
> +  Group;
>  def fsized_deallocation : Flag<["-"], "fsized-deallocation">,
> Flags<[CC1Option]>,
>HelpText<"Enable C++14 sized global deallocation functions">,
> Group;
>  def fno_sized_deallocation: Flag<["-"], "fno-sized-deallocation">,
> Group;
>
> Modified: cfe/trunk/include/clang/Sema/Sema.h
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/Sema/Sema.h?rev=290792&r1=290791&r2=290792&view=diff
> 
> ==
> --- cfe/trunk/include/clang/Sema/Sema.h (original)
> +++ cfe/trunk/include/clang/Sema/Sema.h Sat Dec 31 15:41:23 2016
> @@ -6719,6 +6719,9 @@ public:
>bool isMoreSpecializedThanPrimary(VarTemplatePartialSpecializationDecl
> *T,
>  sema::TemplateDeductionInfo &Info);
>
> +  bool isTemplateTemplateParameterAtLeastAsSpecializedAs(
> +  TemplateParameterList *P, TemplateDecl *AArg, SourceLocation Loc);
> +
>void MarkUsedTemplateParameters(const TemplateArgumentList
> &TemplateArgs,
>bool OnlyDeduced,
>unsigned Depth,
>
> Modified: cfe/trunk/lib/Driver/Tools.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/
> Tools.cpp?rev=290792&r1=290791&r2=290792&view=diff
> 
> ==
> --- cfe/trun

Re: r291123 - CodeGen: plumb header search down to the IAS

[Sean Silva via cfe-commits]

On Sat, Jan 7, 2017 at 1:27 PM, Saleem Abdulrasool via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> I agree with Eric, I don't think that serializing the structure to
> std::cout is the right way to handle this.
>
> What were you thinking of mocking?  Wouldn't you really end up mocking the
> entire backend?
>
> That is the small wrinkle with the way that we deal with inline assembly.
> It really doesn't mesh too well with LTO if you do something like
> `.include`.  What happens if you relocated the bitcode between the
> compile/link phase?  The header search path may be entirely inaccessible at
> this point.  Or they may be relocated, and the paths may need adjustment.
>

Another bad case: two different TU's that are linked into the same LTO
invocation might have conflicting paths. I.e. one says to search
/path/to/foo/ first but the other says to search /path/to/bar/ first. When
both paths could satisfy the include, who wins? I don't think we can
provide any coherent expectations for users about what will happen.

-- Sean Silva


>   But, I agree with you (Eric) here as well, I find the idea of
> serializing the header search options into the module distasteful.
>
> On Fri, Jan 6, 2017 at 6:22 PM, Eric Christopher 
> wrote:
>
>>
>>
>> On Fri, Jan 6, 2017 at 5:56 AM Hal Finkel  wrote:
>>
>>>
>>> On 01/05/2017 08:30 PM, Eric Christopher via cfe-commits wrote:
>>>
>>> Ok, thanks. I agree that it's a problem. I'm definitely open for testing
>>> ideas here. There are a few other things in the
>>> TargetOptions/MCTargetOptions area that are already problematic to test.
>>>
>>>
>>> I think that we need to add serialization for these structures, and a
>>> printing option for them, so that we can test these kinds of things. That
>>> having been said, a lot of these things need to end up in attributes so
>>> that they work correctly with LTO. Is this one of them?
>>>
>>>
>> We definitely need to figure out testing for this, but I don't know that
>> serializing them to std::out is right. Might want to come up with either a
>> gtest or gmock way?
>>
>> That said, ultimately anything that involves parsing at code generation
>> time could involve putting it into a module - that said, I really disagree
>> with all of the include paths etc being serialized into the module.
>>
>> -eric
>>
>>
>>
>>>  -Hal
>>>
>>>
>>>
>>> -eric
>>>
>>> On Thu, Jan 5, 2017 at 6:27 PM Saleem Abdulrasool 
>>> wrote:
>>>
>>> This was certainly the problem that I had.  The test really needs a way
>>> to check that the field was set.  As you state, this is a problematic
>>> area.  The backend already has a test to ensure that the paths are honored,
>>> but, I didn't see any way to actually ensure that it was getting sent to
>>> the backend otherwise.
>>>
>>> The module itself doesnt encode the search path, nor is the information
>>> in the command line.  I can see the argument that the test itself doesn't
>>> add much value especially with the backend side testing that the processing
>>> of the inclusion does occur correctly.  I'll go ahead and remove the test
>>> (which already has ended up being a pain to test).
>>>
>>> On Thu, Jan 5, 2017 at 6:11 PM, Eric Christopher 
>>> wrote:
>>>
>>> Hi Saleem,
>>>
>>> Love that you wanted to add a test for it, but I'd really prefer that
>>> you not engage the backend here in order to do it. You can verify some of
>>> it from the backend and just that the module is correct via the front end
>>> if you'd like. Ensuring the paths are correct is a bit of a sticky problem,
>>> but this is an API boundary that we just have problems with.
>>>
>>> TL;DR: Would you mind splitting this test into front end and back end
>>> tests and avoid using the backend in clang's test harness?
>>>
>>> Thanks!
>>>
>>> -eric
>>>
>>> On Thu, Jan 5, 2017 at 8:13 AM Saleem Abdulrasool via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
>>> Author: compnerd
>>> Date: Thu Jan  5 10:02:32 2017
>>> New Revision: 291123
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=291123&view=rev
>>> Log:
>>> CodeGen: plumb header search down to the IAS
>>>
>>> inline assembly may use the `.include` directive to include other
>>> content into the file.  Without the integrated assembler, the `-I` group
>>> gets passed to the assembler.  Emulate this by collecting the header
>>> search paths and passing them to the IAS.
>>>
>>> Resolves PR24811!
>>>
>>> Added:
>>> cfe/trunk/test/CodeGen/include/
>>> cfe/trunk/test/CodeGen/include/function.x
>>> cfe/trunk/test/CodeGen/include/module.x
>>> cfe/trunk/test/CodeGen/inline-asm-inclusion.c
>>> Modified:
>>> cfe/trunk/include/clang/CodeGen/BackendUtil.h
>>> cfe/trunk/lib/CodeGen/BackendUtil.cpp
>>> cfe/trunk/lib/CodeGen/CodeGenAction.cpp
>>> cfe/trunk/lib/CodeGen/ObjectFilePCHContainerOperations.cpp
>>>
>>> Modified: cfe/trunk/include/clang/CodeGen/BackendUtil.h
>>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/
>>> CodeGen/BackendUtil.h?rev=2

Re: r278882 - If possible, set the stack rlimit to at least 8MiB on cc1 startup, and work

[Sean Silva via cfe-commits]

On Fri, Aug 19, 2016 at 4:33 PM, Joerg Sonnenberger via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On Fri, Aug 19, 2016 at 03:30:42PM -0700, Richard Smith wrote:
> > It typically does; the default stack ulimit is likely tuned for "normal"
> > applications that are not expected (by an ISO standard) to cope with
> > recursing a thousand levels deep. If the system administrator really
> wants
> > to control the stack space for some stupid reason, they can set a hard
> > ulimit. If people actually do that, and then file bugs on clang crashing
> > (which they do today), we may want to resort to spawning a separate
> thread
> > with a higher ulimit if we detect the problem.
>
> Thread stacks by default are even smaller and for good reason.
>

Could you elaborate on this a bit more? I don't understand how a process
adjusting its own soft stack limit is "abusive" in any way.

Richard's patch is in cc1_main.cpp so it is at the top-level entry point of
the program, so we already know how many threads we intend to spawn etc. so
the issue of VA exhaustion on 32-bit seems moot. (libc might spawn threads
internally though, which could be an issue; Richard mentioned a workaround
though which is spawning the entire compilation onto a separate thread with
sufficient stack; would that work for you?)

-- Sean Silva


> Especially on 32bit platforms, it would be unusable otherwise. To put
> this into perspective: if you need to support a recursion level of 1000
> and can't do that with a 4MB stack, it means you are using more than 4KB
> per recursion level. That's a very high stack use and certainly
> something that qualifies as the kind of abusive behavior the process
> limit is designed for in first place.
>
> > It *is* unreasonable to expect them to fiddle with stack ulimits to get
> the
> > compiler to accept programs that, say, use certain components of boost
> (and
> > fit within the standard's recommended limits).
>
> I fundamentally disagree with this statement. Effectively, this seems to
> me to be papering over excessive stack use and nothing else.
>
> Joerg
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r293065 - Clarify how to forward-declare __llvm_profile symbols.

[Sean Silva via cfe-commits]

Thanks!

On Wed, Jan 25, 2017 at 8:01 AM, Nico Weber via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: nico
> Date: Wed Jan 25 10:01:32 2017
> New Revision: 293065
>
> URL: http://llvm.org/viewvc/llvm-project?rev=293065&view=rev
> Log:
> Clarify how to forward-declare __llvm_profile symbols.
>
> Modified:
> cfe/trunk/docs/SourceBasedCodeCoverage.rst
>
> Modified: cfe/trunk/docs/SourceBasedCodeCoverage.rst
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/
> SourceBasedCodeCoverage.rst?rev=293065&r1=293064&r2=293065&view=diff
> 
> ==
> --- cfe/trunk/docs/SourceBasedCodeCoverage.rst (original)
> +++ cfe/trunk/docs/SourceBasedCodeCoverage.rst Wed Jan 25 10:01:32 2017
> @@ -256,6 +256,8 @@ without using static initializers, do th
>otherwise. Calling this function multiple times appends profile data to
> an
>existing on-disk raw profile.
>
> +In C++ files, declare these as ``extern "C"``.
> +
>  Collecting coverage reports for the llvm project
>  
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r294401 - Sema: add warning for c++ member variable shadowing

[Sean Silva via cfe-commits]

Nice!

On Tue, Feb 7, 2017 at 7:30 PM, Saleem Abdulrasool via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: compnerd
> Date: Tue Feb  7 21:30:13 2017
> New Revision: 294401
>
> URL: http://llvm.org/viewvc/llvm-project?rev=294401&view=rev
> Log:
> Sema: add warning for c++ member variable shadowing
>
> Add a warning for shadowed variables across records.  Referencing a
> shadow'ed variable may not give the desired variable.  Add an optional
> warning for the shadowing.
>
> Patch by James Sun!
>
> Added:
> cfe/trunk/test/CXX/class.derived/class.member.lookup/p10.cpp
> Modified:
> cfe/trunk/include/clang/Basic/DiagnosticGroups.td
> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> cfe/trunk/include/clang/Sema/Sema.h
> cfe/trunk/lib/Sema/SemaDeclCXX.cpp
> cfe/trunk/test/CXX/class.derived/class.member.lookup/p6.cpp
> cfe/trunk/test/CXX/class.derived/class.member.lookup/p7.cpp
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticGroups.td
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/Basic/DiagnosticGroups.td?rev=294401&r1=294400&r2=294401&view=diff
> 
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticGroups.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticGroups.td Tue Feb  7 21:30:13
> 2017
> @@ -355,6 +355,7 @@ def SemiBeforeMethodBody : DiagGroup<"se
>  def Sentinel : DiagGroup<"sentinel">;
>  def MissingMethodReturnType : DiagGroup<"missing-method-return-type">;
>
> +def ShadowField : DiagGroup<"shadow-field">;
>  def ShadowFieldInConstructorModified : DiagGroup<"shadow-field-in-
> constructor-modified">;
>  def ShadowFieldInConstructor : DiagGroup<"shadow-field-in-constructor",
>   [ShadowFieldInConstructorModifi
> ed]>;
> @@ -366,7 +367,7 @@ def ShadowUncapturedLocal : DiagGroup<"s
>  def Shadow : DiagGroup<"shadow", [ShadowFieldInConstructorModified,
>ShadowIvar]>;
>  def ShadowAll : DiagGroup<"shadow-all", [Shadow, ShadowFieldInConstructor,
> - ShadowUncapturedLocal]>;
> + ShadowUncapturedLocal,
> ShadowField]>;
>
>  def Shorten64To32 : DiagGroup<"shorten-64-to-32">;
>  def : DiagGroup<"sign-promo">;
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/
> DiagnosticSemaKinds.td?rev=294401&r1=294400&r2=294401&view=diff
> 
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Tue Feb  7
> 21:30:13 2017
> @@ -8959,4 +8959,9 @@ def ext_warn_gnu_final : ExtWarn<
>"__final is a GNU extension, consider using C++11 final">,
>InGroup;
>
> +def warn_shadow_field :
> +  Warning<"non-static data member '%0' of '%1' shadows member inherited
> from type '%2'">,
> +  InGroup, DefaultIgnore;
> +def note_shadow_field : Note<"declared here">;
> +
>  } // end of sema component.
>
> Modified: cfe/trunk/include/clang/Sema/Sema.h
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/Sema/Sema.h?rev=294401&r1=294400&r2=294401&view=diff
> 
> ==
> --- cfe/trunk/include/clang/Sema/Sema.h (original)
> +++ cfe/trunk/include/clang/Sema/Sema.h Tue Feb  7 21:30:13 2017
> @@ -10074,6 +10074,11 @@ private:
>void CheckBitFieldInitialization(SourceLocation InitLoc, FieldDecl
> *Field,
> Expr *Init);
>
> +  /// Check if there is a field shadowing.
> +  void CheckShadowInheritedFields(const SourceLocation &Loc,
> +  DeclarationName FieldName,
> +  const CXXRecordDecl *RD);
> +
>/// \brief Check if the given expression contains 'break' or 'continue'
>/// statement that produces control flow different from GCC.
>void CheckBreakContinueBinding(Expr *E);
>
> Modified: cfe/trunk/lib/Sema/SemaDeclCXX.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/
> SemaDeclCXX.cpp?rev=294401&r1=294400&r2=294401&view=diff
> 
> ==
> --- cfe/trunk/lib/Sema/SemaDeclCXX.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaDeclCXX.cpp Tue Feb  7 21:30:13 2017
> @@ -2758,6 +2758,56 @@ static AttributeList *getMSPropertyAttr(
>return nullptr;
>  }
>
> +// Check if there is a field shadowing.
> +void Sema::CheckShadowInheritedFields(const SourceLocation &Loc,
> +  DeclarationName FieldName,
> +  const CXXRecordDecl *RD) {
> +  if (Diags.isIgnored(diag::warn_shadow_field, Loc))
> +return;
> +
> +  // To record a shadowed field in a base
> +  std::m

Re: r296554 - [PS4] Set our default dialect to C++11. NFC for other targets.

[Sean Silva via cfe-commits]

Nice!

-- Sean Silva

On Tue, Feb 28, 2017 at 5:01 PM, Paul Robinson via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: probinson
> Date: Tue Feb 28 19:01:10 2017
> New Revision: 296554
>
> URL: http://llvm.org/viewvc/llvm-project?rev=296554&view=rev
> Log:
> [PS4] Set our default dialect to C++11. NFC for other targets.
> Reapplies r296209 now that r296549 has fixed what really seems to be
> the last problematic test.
>
> Modified:
> cfe/trunk/lib/Frontend/CompilerInvocation.cpp
>
> Modified: cfe/trunk/lib/Frontend/CompilerInvocation.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/
> Frontend/CompilerInvocation.cpp?rev=296554&r1=296553&r2=296554&view=diff
> 
> ==
> --- cfe/trunk/lib/Frontend/CompilerInvocation.cpp (original)
> +++ cfe/trunk/lib/Frontend/CompilerInvocation.cpp Tue Feb 28 19:01:10 2017
> @@ -1582,7 +1582,11 @@ void CompilerInvocation::setLangDefaults
>  case IK_PreprocessedCXX:
>  case IK_ObjCXX:
>  case IK_PreprocessedObjCXX:
> -  LangStd = LangStandard::lang_gnucxx98;
> +  // The PS4 uses C++11 as the default C++ standard.
> +  if (T.isPS4())
> +LangStd = LangStandard::lang_gnucxx11;
> +  else
> +LangStd = LangStandard::lang_gnucxx98;
>break;
>  case IK_RenderScript:
>LangStd = LangStandard::lang_c99;
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r296554 - [PS4] Set our default dialect to C++11. NFC for other targets.

[Sean Silva via cfe-commits]

On Wed, Mar 1, 2017 at 10:35 AM, Mehdi Amini  wrote:

> I’m not sure I find this nice to see this upstream.
>
> I not fond in general of this kind of difference in behavior. I don’t
> think it is good for clang to have different default for this kind of
> settings depending on the platform. It does not provide a very good user
> experience from a cross-platform point of view (i.e. my compiler behaves
> very differently when I target one platform instead of another).
>

What I like about it is that the upstream PS4 bots now test that we don't
depend on the C++98 default language standard in tests, which is net
positive IMO since it facilitates future changes. Should this be a point of
vendor/platform extensibility? That's a question for cfe-dev, but I don't
think it's unreasonable. (see also: PS4 has -fno-rtti and -fno-exceptions
by default, even though users already know to pass the right flags and
expect to have to).

-- Sean Silva


>
> —
> Mehdi
>
>
>
> On Feb 28, 2017, at 11:22 PM, Sean Silva via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
> Nice!
>
> -- Sean Silva
>
> On Tue, Feb 28, 2017 at 5:01 PM, Paul Robinson via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: probinson
>> Date: Tue Feb 28 19:01:10 2017
>> New Revision: 296554
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=296554&view=rev
>> Log:
>> [PS4] Set our default dialect to C++11. NFC for other targets.
>> Reapplies r296209 now that r296549 has fixed what really seems to be
>> the last problematic test.
>>
>> Modified:
>> cfe/trunk/lib/Frontend/CompilerInvocation.cpp
>>
>> Modified: cfe/trunk/lib/Frontend/CompilerInvocation.cpp
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/
>> CompilerInvocation.cpp?rev=296554&r1=296553&r2=296554&view=diff
>> 
>> ==
>> --- cfe/trunk/lib/Frontend/CompilerInvocation.cpp (original)
>> +++ cfe/trunk/lib/Frontend/CompilerInvocation.cpp Tue Feb 28 19:01:10
>> 2017
>> @@ -1582,7 +1582,11 @@ void CompilerInvocation::setLangDefaults
>>  case IK_PreprocessedCXX:
>>  case IK_ObjCXX:
>>  case IK_PreprocessedObjCXX:
>> -  LangStd = LangStandard::lang_gnucxx98;
>> +  // The PS4 uses C++11 as the default C++ standard.
>> +  if (T.isPS4())
>> +LangStd = LangStandard::lang_gnucxx11;
>> +  else
>> +LangStd = LangStandard::lang_gnucxx98;
>>break;
>>  case IK_RenderScript:
>>LangStd = LangStandard::lang_c99;
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r288093 - Use ${:uid} to generate unique MS asm labels, not {:uid}

[Sean Silva via cfe-commits]

what is this ${:uid} thing? Could the comment
in Sema::GetOrCreateMSAsmLabel explain it?

-- Sean Silva

On Mon, Nov 28, 2016 at 4:39 PM, Reid Kleckner via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rnk
> Date: Mon Nov 28 18:39:37 2016
> New Revision: 288093
>
> URL: http://llvm.org/viewvc/llvm-project?rev=288093&view=rev
> Log:
> Use ${:uid} to generate unique MS asm labels, not {:uid}
>
> Modified:
> cfe/trunk/lib/Sema/SemaStmtAsm.cpp
> cfe/trunk/test/CodeGen/mozilla-ms-inline-asm.c
> cfe/trunk/test/CodeGen/ms-inline-asm.c
> cfe/trunk/test/CodeGen/ms-inline-asm.cpp
>
> Modified: cfe/trunk/lib/Sema/SemaStmtAsm.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/
> SemaStmtAsm.cpp?rev=288093&r1=288092&r2=288093&view=diff
> 
> ==
> --- cfe/trunk/lib/Sema/SemaStmtAsm.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaStmtAsm.cpp Mon Nov 28 18:39:37 2016
> @@ -753,7 +753,7 @@ LabelDecl *Sema::GetOrCreateMSAsmLabel(S
>  // Create an internal name for the label.  The name should not be a
> valid mangled
>  // name, and should be unique.  We use a dot to make the name an
> invalid mangled
>  // name.
> -OS << "__MSASMLABEL_.{:uid}__";
> +OS << "__MSASMLABEL_.${:uid}__";
>  for (char C : ExternalLabelName) {
>OS << C;
>// We escape '$' in asm strings by replacing it with "$$"
>
> Modified: cfe/trunk/test/CodeGen/mozilla-ms-inline-asm.c
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/
> CodeGen/mozilla-ms-inline-asm.c?rev=288093&r1=288092&r2=288093&view=diff
> 
> ==
> --- cfe/trunk/test/CodeGen/mozilla-ms-inline-asm.c (original)
> +++ cfe/trunk/test/CodeGen/mozilla-ms-inline-asm.c Mon Nov 28 18:39:37
> 2016
> @@ -20,7 +20,7 @@ void invoke(void* that, unsigned methodI
>  // CHECK: call void asm sideeffect inteldialect
>  // CHECK: mov edx,dword ptr $1
>  // CHECK: test edx,edx
> -// CHECK: jz {{[^_]*}}__MSASMLABEL_.{:uid}__noparams
> +// CHECK: jz {{[^_]*}}__MSASMLABEL_.${:uid}__noparams
>  // ^ Can't use {{.*}} here because the matching is greedy.
>  // CHECK: mov eax,edx
>  // CHECK: shl eax,$$3
> @@ -28,7 +28,7 @@ void invoke(void* that, unsigned methodI
>  // CHECK: mov ecx,esp
>  // CHECK: push dword ptr $0
>  // CHECK: call dword ptr $2
> -// CHECK: {{.*}}__MSASMLABEL_.{:uid}__noparams:
> +// CHECK: {{.*}}__MSASMLABEL_.${:uid}__noparams:
>  // CHECK: mov ecx,dword ptr $3
>  // CHECK: push ecx
>  // CHECK: mov edx,[ecx]
>
> Modified: cfe/trunk/test/CodeGen/ms-inline-asm.c
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/
> CodeGen/ms-inline-asm.c?rev=288093&r1=288092&r2=288093&view=diff
> 
> ==
> --- cfe/trunk/test/CodeGen/ms-inline-asm.c (original)
> +++ cfe/trunk/test/CodeGen/ms-inline-asm.c Mon Nov 28 18:39:37 2016
> @@ -249,7 +249,7 @@ void t23() {
>the_label:
>}
>  // CHECK: t23
> -// CHECK: call void asm sideeffect inteldialect
> "{{.*}}__MSASMLABEL_.{:uid}__the_label:", "~{dirflag},~{fpsr},~{flags}"()
> +// CHECK: call void asm sideeffect inteldialect
> "{{.*}}__MSASMLABEL_.${:uid}__the_label:", "~{dirflag},~{fpsr},~{flags}"()
>  }
>
>  void t24_helper(void) {}
> @@ -595,7 +595,7 @@ void label1() {
>  jmp label
>}
>// CHECK-LABEL: define void @label1()
> -  // CHECK: call void asm sideeffect inteldialect
> "{{.*}}__MSASMLABEL_.{:uid}__label:\0A\09jmp 
> {{.*}}__MSASMLABEL_.{:uid}__label",
> "~{dirflag},~{fpsr},~{flags}"() [[ATTR1:#[0-9]+]]
> +  // CHECK: call void asm sideeffect inteldialect
> "{{.*}}__MSASMLABEL_.${:uid}__label:\0A\09jmp
> {{.*}}__MSASMLABEL_.${:uid}__label", "~{dirflag},~{fpsr},~{flags}"()
> [[ATTR1:#[0-9]+]]
>  }
>
>  void label2() {
> @@ -604,7 +604,7 @@ void label2() {
>  label:
>}
>// CHECK-LABEL: define void @label2
> -  // CHECK: call void asm sideeffect inteldialect "jmp
> {{.*}}__MSASMLABEL_.{:uid}__label\0A\09{{.*}}__MSASMLABEL_.{:uid}__label:",
> "~{dirflag},~{fpsr},~{flags}"()
> +  // CHECK: call void asm sideeffect inteldialect "jmp
> {{.*}}__MSASMLABEL_.${:uid}__label\0A\09{{.*}}__MSASMLABEL_.${:uid}__label:",
> "~{dirflag},~{fpsr},~{flags}"()
>  }
>
>  void label3() {
> @@ -613,7 +613,7 @@ void label3() {
>  mov eax, label
>}
>// CHECK-LABEL: define void @label3
> -  // CHECK: call void asm sideeffect inteldialect
> "{{.*}}__MSASMLABEL_.{:uid}__label:\0A\09mov eax,
> {{.*}}__MSASMLABEL_.{:uid}__label", "~{eax},~{dirflag},~{fpsr},~{flags}"()
> +  // CHECK: call void asm sideeffect inteldialect
> "{{.*}}__MSASMLABEL_.${:uid}__label:\0A\09mov eax,
> {{.*}}__MSASMLABEL_.${:uid}__label", "~{eax},~{dirflag},~{fpsr},~{
> flags}"()
>  }
>
>  void label4() {
> @@ -622,7 +622,7 @@ void label4() {
>  mov eax, [label]
>}
>// CHECK-LABEL: define void @label4
> -  // CHECK: call void asm sideeffec

Re: r288093 - Use ${:uid} to generate unique MS asm labels, not {:uid}

[Sean Silva via cfe-commits]

Thanks.

2016-12-06 16:28 GMT-08:00 Reid Kleckner :

> Comments in r288868. It implements GCC's %= inline asm feature, and we're
> just using it from MS-style inline asm to avoid duplicate labels clashing.
>
> 2016-12-01 0:37 GMT-08:00 Sean Silva :
>
>> what is this ${:uid} thing? Could the comment
>> in Sema::GetOrCreateMSAsmLabel explain it?
>>
>> -- Sean Silva
>>
>> On Mon, Nov 28, 2016 at 4:39 PM, Reid Kleckner via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: rnk
>>> Date: Mon Nov 28 18:39:37 2016
>>> New Revision: 288093
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=288093&view=rev
>>> Log:
>>> Use ${:uid} to generate unique MS asm labels, not {:uid}
>>>
>>> Modified:
>>> cfe/trunk/lib/Sema/SemaStmtAsm.cpp
>>> cfe/trunk/test/CodeGen/mozilla-ms-inline-asm.c
>>> cfe/trunk/test/CodeGen/ms-inline-asm.c
>>> cfe/trunk/test/CodeGen/ms-inline-asm.cpp
>>>
>>> Modified: cfe/trunk/lib/Sema/SemaStmtAsm.cpp
>>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaS
>>> tmtAsm.cpp?rev=288093&r1=288092&r2=288093&view=diff
>>> 
>>> ==
>>> --- cfe/trunk/lib/Sema/SemaStmtAsm.cpp (original)
>>> +++ cfe/trunk/lib/Sema/SemaStmtAsm.cpp Mon Nov 28 18:39:37 2016
>>> @@ -753,7 +753,7 @@ LabelDecl *Sema::GetOrCreateMSAsmLabel(S
>>>  // Create an internal name for the label.  The name should not be a
>>> valid mangled
>>>  // name, and should be unique.  We use a dot to make the name an
>>> invalid mangled
>>>  // name.
>>> -OS << "__MSASMLABEL_.{:uid}__";
>>> +OS << "__MSASMLABEL_.${:uid}__";
>>>  for (char C : ExternalLabelName) {
>>>OS << C;
>>>// We escape '$' in asm strings by replacing it with "$$"
>>>
>>> Modified: cfe/trunk/test/CodeGen/mozilla-ms-inline-asm.c
>>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/m
>>> ozilla-ms-inline-asm.c?rev=288093&r1=288092&r2=288093&view=diff
>>> 
>>> ==
>>> --- cfe/trunk/test/CodeGen/mozilla-ms-inline-asm.c (original)
>>> +++ cfe/trunk/test/CodeGen/mozilla-ms-inline-asm.c Mon Nov 28 18:39:37
>>> 2016
>>> @@ -20,7 +20,7 @@ void invoke(void* that, unsigned methodI
>>>  // CHECK: call void asm sideeffect inteldialect
>>>  // CHECK: mov edx,dword ptr $1
>>>  // CHECK: test edx,edx
>>> -// CHECK: jz {{[^_]*}}__MSASMLABEL_.{:uid}__noparams
>>> +// CHECK: jz {{[^_]*}}__MSASMLABEL_.${:uid}__noparams
>>>  // ^ Can't use {{.*}} here because the matching is greedy.
>>>  // CHECK: mov eax,edx
>>>  // CHECK: shl eax,$$3
>>> @@ -28,7 +28,7 @@ void invoke(void* that, unsigned methodI
>>>  // CHECK: mov ecx,esp
>>>  // CHECK: push dword ptr $0
>>>  // CHECK: call dword ptr $2
>>> -// CHECK: {{.*}}__MSASMLABEL_.{:uid}__noparams:
>>> +// CHECK: {{.*}}__MSASMLABEL_.${:uid}__noparams:
>>>  // CHECK: mov ecx,dword ptr $3
>>>  // CHECK: push ecx
>>>  // CHECK: mov edx,[ecx]
>>>
>>> Modified: cfe/trunk/test/CodeGen/ms-inline-asm.c
>>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/m
>>> s-inline-asm.c?rev=288093&r1=288092&r2=288093&view=diff
>>> 
>>> ==
>>> --- cfe/trunk/test/CodeGen/ms-inline-asm.c (original)
>>> +++ cfe/trunk/test/CodeGen/ms-inline-asm.c Mon Nov 28 18:39:37 2016
>>> @@ -249,7 +249,7 @@ void t23() {
>>>the_label:
>>>}
>>>  // CHECK: t23
>>> -// CHECK: call void asm sideeffect inteldialect
>>> "{{.*}}__MSASMLABEL_.{:uid}__the_label:", "~{dirflag},~{fpsr},~{flags}"(
>>> )
>>> +// CHECK: call void asm sideeffect inteldialect
>>> "{{.*}}__MSASMLABEL_.${:uid}__the_label:",
>>> "~{dirflag},~{fpsr},~{flags}"()
>>>  }
>>>
>>>  void t24_helper(void) {}
>>> @@ -595,7 +595,7 @@ void label1() {
>>>  jmp label
>>>}
>>>// CHECK-LABEL: define void @label1()
>>> -  // CHECK: call void asm sideeffect inteldialect
>>> "{{.*}}__MSASMLABEL_.{:uid}__label:\0A\09jmp
>>> {{.*}}__MSASMLABEL_.{:uid}__label", "~{dirflag},~{fpsr},~{flags}"()
>>> [[ATTR1:#[0-9]+]]
>>> +  // CHECK: call void asm sideeffect inteldialect
>>> "{{.*}}__MSASMLABEL_.${:uid}__label:\0A\09jmp
>>> {{.*}}__MSASMLABEL_.${:uid}__label", "~{dirflag},~{fpsr},~{flags}"()
>>> [[ATTR1:#[0-9]+]]
>>>  }
>>>
>>>  void label2() {
>>> @@ -604,7 +604,7 @@ void label2() {
>>>  label:
>>>}
>>>// CHECK-LABEL: define void @label2
>>> -  // CHECK: call void asm sideeffect inteldialect "jmp
>>> {{.*}}__MSASMLABEL_.{:uid}__label\0A\09{{.*}}__MSASMLABEL_.{:uid}__label:",
>>> "~{dirflag},~{fpsr},~{flags}"()
>>> +  // CHECK: call void asm sideeffect inteldialect "jmp
>>> {{.*}}__MSASMLABEL_.${:uid}__label\0A\09{{.*}}__MSASMLABEL_.${:uid}__label:",
>>> "~{dirflag},~{fpsr},~{flags}"()
>>>  }
>>>
>>>  void label3() {
>>> @@ -613,7 +613,7 @@ void label3() {
>>>  mov eax, label
>>>}
>>>// CHECK-LABEL: define void @label3
>>> -  // CHECK: call void asm sideeffect i

Re: r285341 - Add documentation describing the components of a complete toolchain including Clang.

[Sean Silva via cfe-commits]

This is awesome Richard. Thanks!

-- Sean Silva

On Thu, Oct 27, 2016 at 1:55 PM, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rsmith
> Date: Thu Oct 27 15:55:56 2016
> New Revision: 285341
>
> URL: http://llvm.org/viewvc/llvm-project?rev=285341&view=rev
> Log:
> Add documentation describing the components of a complete toolchain
> including Clang.
>
> Added:
> cfe/trunk/docs/Toolchain.rst
> Modified:
> cfe/trunk/docs/UsersManual.rst
> cfe/trunk/docs/index.rst
>
> Added: cfe/trunk/docs/Toolchain.rst
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/
> Toolchain.rst?rev=285341&view=auto
> 
> ==
> --- cfe/trunk/docs/Toolchain.rst (added)
> +++ cfe/trunk/docs/Toolchain.rst Thu Oct 27 15:55:56 2016
> @@ -0,0 +1,354 @@
> +===
> +Assembling a Complete Toolchain
> +===
> +
> +.. contents::
> +   :local:
> +   :depth: 2
> +
> +Introduction
> +
> +
> +Clang is only one component in a complete tool chain for C family
> +programming languages. In order to assemble a complete toolchain,
> +additional tools and runtime libraries are required. Clang is designed
> +to interoperate with existing tools and libraries for its target
> +platforms, and the LLVM project provides alternatives for a number
> +of these components.
> +
> +This document describes the required and optional components in a
> +complete toolchain, where to find them, and the supported versions
> +and limitations of each option.
> +
> +.. warning::
> +
> +  This document currently describes Clang configurations on POSIX-like
> +  operating systems with the GCC-compatible ``clang`` driver. When
> +  targeting Windows with the MSVC-compatible ``clang-cl`` driver, some
> +  of the details are different.
> +
> +Tools
> +=
> +
> +.. FIXME: Describe DWARF-related tools
> +
> +A complete compilation of C family programming languages typically
> +involves the following pipeline of tools, some of which are omitted
> +in some compilations:
> +
> +* **Preprocessor**: This performs the actions of the C preprocessor:
> +  expanding #includes and #defines.
> +  The ``-E`` flag instructs Clang to stop after this step.
> +
> +* **Parsing**: This parses and semantically analyzes the source language
> and
> +  builds a source-level intermediate representation ("AST"), producing a
> +  :ref:`precompiled header (PCH) `,
> +  preamble, or
> +  :doc:`precompiled module file (PCM) `,
> +  depending on the input.
> +  The ``-precompile`` flag instructs Clang to stop after this step. This
> is
> +  the default when the input is a header file.
> +
> +* **IR generation**: This converts the source-level intermediate
> representation
> +  into an optimizer-specific intermediate representation (IR); for Clang,
> this
> +  is LLVM IR.
> +  The ``-emit-llvm`` flag instructs Clang to stop after this step. If
> combined
> +  with ``-S``, Clang will produce textual LLVM IR; otherwise, it will
> produce
> +  LLVM IR bitcode.
> +
> +* **Compiler backend**: This converts the intermediate representation
> +  into target-specific assembly code.
> +  The ``-S`` flag instructs Clang to stop after this step.
> +
> +* **Assembler**: This converts target-specific assembly code into
> +  target-specific machine code object files.
> +  The ``-c`` flag instructs Clang to stop after this step.
> +
> +* **Linker**: This combines multiple object files into a single image
> +  (either a shared object or an executable).
> +
> +Clang provides all of these pieces other than the linker. When multiple
> +steps are performed by the same tool, it is common for the steps to be
> +fused together to avoid creating intermediate files.
> +
> +When given an output of one of the above steps as an input, earlier steps
> +are skipped (for instance, a ``.s`` file input will be assembled and
> linked).
> +
> +The Clang driver can be invoked with the ``-###`` flag (this argument
> will need
> +to be escaped under most shells) to see which commands it would run for
> the
> +above steps, without running them. The ``-v`` (verbose) flag will print
> the
> +commands in addition to running them.
> +
> +Clang frontend
> +--
> +
> +The Clang frontend (``clang -cc1``) is used to compile C family
> languages. The
> +command-line interface of the frontend is considered to be an
> implementation
> +detail, intentionally has no external documentation, and is subject to
> change
> +without notice.
> +
> +Language frontends for other languages
> +--
> +
> +Clang can be provided with inputs written in non-C-family languages. In
> such
> +cases, an external tool will be used to compile the input. The
> +currently-supported languages are:
> +
> +* Ada (``-x ada``, ``.ad[bs]``)
> +* Fortran (``-x f95``, ``.f``, ``.f9[05]``, ``.for``, ``.fpp``,
> case-insensitive)
> +* Java (``-x java``)
> +
> +In e

r247498 - Clean up trailing whitespace in the builtin headers

[Sean Silva via cfe-commits]

Author: silvas
Date: Fri Sep 11 21:55:19 2015
New Revision: 247498

URL: http://llvm.org/viewvc/llvm-project?rev=247498&view=rev
Log:
Clean up trailing whitespace in the builtin headers

Modified:
cfe/trunk/lib/Headers/altivec.h
cfe/trunk/lib/Headers/ammintrin.h
cfe/trunk/lib/Headers/avx512vlbwintrin.h
cfe/trunk/lib/Headers/avx512vldqintrin.h
cfe/trunk/lib/Headers/avxintrin.h
cfe/trunk/lib/Headers/htmxlintrin.h
cfe/trunk/lib/Headers/mmintrin.h
cfe/trunk/lib/Headers/pmmintrin.h
cfe/trunk/lib/Headers/smmintrin.h
cfe/trunk/lib/Headers/stdint.h
cfe/trunk/lib/Headers/tgmath.h
cfe/trunk/lib/Headers/tmmintrin.h
cfe/trunk/lib/Headers/xmmintrin.h

Modified: cfe/trunk/lib/Headers/altivec.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/altivec.h?rev=247498&r1=247497&r2=247498&view=diff
==
--- cfe/trunk/lib/Headers/altivec.h (original)
+++ cfe/trunk/lib/Headers/altivec.h Fri Sep 11 21:55:19 2015
@@ -137,7 +137,7 @@ static vector double __ATTRS_o_ai vec_ab
 }
 #endif
 
-/* vec_abss */ 
+/* vec_abss */
 #define __builtin_altivec_abss_v16qi vec_abss
 #define __builtin_altivec_abss_v8hi vec_abss
 #define __builtin_altivec_abss_v4si vec_abss
@@ -3651,21 +3651,21 @@ static vector float __ATTRS_o_ai vec_vmr
 static vector bool int __ATTRS_o_ai
 vec_mergee(vector bool int __a, vector bool int __b) {
   return vec_perm(__a, __b, (vector unsigned char)
-  (0x00, 0x01, 0x02, 0x03, 0x10, 0x11, 0x12, 0x13, 
+  (0x00, 0x01, 0x02, 0x03, 0x10, 0x11, 0x12, 0x13,
0x08, 0x09, 0x0A, 0x0B, 0x18, 0x19, 0x1A, 0x1B));
 }
 
 static vector signed int __ATTRS_o_ai
 vec_mergee(vector signed int __a, vector signed int __b) {
   return vec_perm(__a, __b, (vector unsigned char)
-  (0x00, 0x01, 0x02, 0x03, 0x10, 0x11, 0x12, 0x13, 
+  (0x00, 0x01, 0x02, 0x03, 0x10, 0x11, 0x12, 0x13,
0x08, 0x09, 0x0A, 0x0B, 0x18, 0x19, 0x1A, 0x1B));
 }
 
 static vector unsigned int __ATTRS_o_ai
 vec_mergee(vector unsigned int __a, vector unsigned int __b) {
   return vec_perm(__a, __b, (vector unsigned char)
-  (0x00, 0x01, 0x02, 0x03, 0x10, 0x11, 0x12, 0x13, 
+  (0x00, 0x01, 0x02, 0x03, 0x10, 0x11, 0x12, 0x13,
0x08, 0x09, 0x0A, 0x0B, 0x18, 0x19, 0x1A, 0x1B));
 }
 

Modified: cfe/trunk/lib/Headers/ammintrin.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/ammintrin.h?rev=247498&r1=247497&r2=247498&view=diff
==
--- cfe/trunk/lib/Headers/ammintrin.h (original)
+++ cfe/trunk/lib/Headers/ammintrin.h Fri Sep 11 21:55:19 2015
@@ -34,13 +34,13 @@
 ///
 /// \headerfile 
 ///
-/// \code 
+/// \code
 /// __m128i _mm_extracti_si64(__m128i x, const int len, const int idx);
-/// \endcode 
+/// \endcode
 ///
-/// \code
+/// \code
 /// This intrinsic corresponds to the \c EXTRQ instruction.
-/// \endcode 
+/// \endcode
 ///
 /// \param x
 ///The value from which bits are extracted.
@@ -48,10 +48,10 @@
 ///Bits [5:0] specify the length; the other bits are ignored. If bits [5:0]
 ///are zero, the length is interpreted as 64.
 /// \param idx
-///Bits [5:0] specify the index of the least significant bit; the other 
-///bits are ignored. If the sum of the index and length is greater than 
-///64, the result is undefined. If the length and index are both zero, 
-///bits [63:0] of parameter x are extracted. If the length is zero 
+///Bits [5:0] specify the index of the least significant bit; the other
+///bits are ignored. If the sum of the index and length is greater than
+///64, the result is undefined. If the length and index are both zero,
+///bits [63:0] of parameter x are extracted. If the length is zero
 ///but the index is non-zero, the result is undefined.
 /// \returns A 128-bit integer vector whose lower 64 bits contain the bits
 ///extracted from the source operand.
@@ -64,21 +64,21 @@
 ///
 /// \headerfile 
 ///
-/// \code 
+/// \code
 /// This intrinsic corresponds to the \c EXTRQ instruction.
-/// \endcode 
+/// \endcode
 ///
 /// \param __x
 ///The value from which bits are extracted.
 /// \param __y
-///Specifies the index of the least significant bit at [13:8] 
-///and the length at [5:0]; all other bits are ignored. 
+///Specifies the index of the least significant bit at [13:8]
+///and the length at [5:0]; all other bits are ignored.
 ///If bits [5:0] are zero, the length is interpreted as 64.
-///If the sum of the index and length is greater than 64, the result is 
-///undefined. If the length and index are both zero, bits [63:0] of 
-///parameter __x are extracted. If the length is zero but the index is 
-///non-zero, the result is undefin

Re: r247765 - [modules] Fix a corner case in the macro override rules: properly handle overridden leaf module macros.

[Sean Silva via cfe-commits]

On Tue, Sep 15, 2015 at 5:55 PM, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rsmith
> Date: Tue Sep 15 19:55:50 2015
> New Revision: 247765
>
> URL: http://llvm.org/viewvc/llvm-project?rev=247765&view=rev
> Log:
> [modules] Fix a corner case in the macro override rules: properly handle
> overridden leaf module macros.
>

What exactly is a "leaf module macro"?

-- Sean Silva


>
> Modified:
> cfe/trunk/lib/Lex/PPMacroExpansion.cpp
> cfe/trunk/test/Modules/macros.c
>
> Modified: cfe/trunk/lib/Lex/PPMacroExpansion.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/PPMacroExpansion.cpp?rev=247765&r1=247764&r2=247765&view=diff
>
> ==
> --- cfe/trunk/lib/Lex/PPMacroExpansion.cpp (original)
> +++ cfe/trunk/lib/Lex/PPMacroExpansion.cpp Tue Sep 15 19:55:50 2015
> @@ -145,8 +145,12 @@ void Preprocessor::updateModuleMacroInfo
>  NumHiddenOverrides[O] = -1;
>
>// Collect all macros that are not overridden by a visible macro.
> -  llvm::SmallVector Worklist(Leaf->second.begin(),
> -Leaf->second.end());
> +  llvm::SmallVector Worklist;
> +  for (auto *LeafMM : Leaf->second) {
> +assert(LeafMM->getNumOverridingMacros() == 0 && "leaf macro
> overridden");
> +if (NumHiddenOverrides.lookup(LeafMM) == 0)
> +  Worklist.push_back(LeafMM);
> +  }
>while (!Worklist.empty()) {
>  auto *MM = Worklist.pop_back_val();
>  if
> (CurSubmoduleState->VisibleModules.isVisible(MM->getOwningModule())) {
>
> Modified: cfe/trunk/test/Modules/macros.c
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/macros.c?rev=247765&r1=247764&r2=247765&view=diff
>
> ==
> --- cfe/trunk/test/Modules/macros.c (original)
> +++ cfe/trunk/test/Modules/macros.c Tue Sep 15 19:55:50 2015
> @@ -18,7 +18,6 @@
>  // expected-note@Inputs/macros_right.h:12{{expanding this definition of
> 'LEFT_RIGHT_DIFFERENT'}}
>  // expected-note@Inputs/macros_right.h:13{{expanding this definition of
> 'LEFT_RIGHT_DIFFERENT2'}}
>  // expected-note@Inputs/macros_left.h:14{{other definition of
> 'LEFT_RIGHT_DIFFERENT'}}
> -// expected-note@Inputs/macros_left.h:11{{other definition of
> 'LEFT_RIGHT_DIFFERENT2'}}
>
>  @import macros;
>
> @@ -72,9 +71,14 @@ void f() {
>  #  error TOP should not be visible
>  #endif
>
> +#undef INTEGER
> +#define INTEGER int
> +
>  // Import left module (which also imports top)
>  @import macros_left;
>
> +INTEGER my_integer = 0;
> +
>  #ifndef LEFT
>  #  error LEFT should be visible
>  #endif
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D11844: [Modules] More descriptive diagnostics for misplaced import directive

[Sean Silva via cfe-commits]

silvas requested changes to this revision.
silvas added a reviewer: silvas.
This revision now requires changes to proceed.


Comment at: include/clang/Basic/DiagnosticSemaKinds.td:7774
@@ -7771,1 +7773,3 @@
   "@import of module '%0' in implementation of '%1'; use #import">;
+def note_module_need_top_level : Note<"consider moving the import to top 
level">;
+def note_module_need_textual : Note<"consider marking the header as textual">;

rsmith wrote:
> We'll already have said something like:
> 
>   error: import of module 'foo' appears within class X
>   note: class X begins here
> 
> There are two likely situations here: either the header was intended to be 
> included textually, or the user forgot a `}` or similar and didn't expect for 
> the import to be inside the class. Either way, this note is not useful 
> (either they thought it *was* at the top level, or the note is not 
> applicable).
> 
> How about dropping this note? The "begins here" note seems to have already 
> covered the interesting case.
I think this makes sense. `error: ... import ... appears within ...` seems like 
sufficient information about the nature of the error.


Comment at: lib/Sema/SemaDecl.cpp:14372
@@ +14371,3 @@
+ diag::note_module_import_not_at_top_level) << DC;
+  S.Diag(ImportLoc, diag::note_module_need_textual);
+}

rsmith wrote:
> I think we should only suggest changing the module map if our current module 
> and the module of the included file are within the same top-level module. It 
> would be unfortunate for us to suggest modifying, say, the libc module map if 
> we see some end user's code including a C library header in the wrong context.
> 
> You can check `M->getTopLevelModuleName()` against 
> `S.getLangOpts().CurrentModule` and `S.getLangOpts().ImplementationOfModule` 
> to see whether it's a submodule of the current module.
From my experience, your suggested heuristic is insufficient; we definitely 
need to cover the case that crosses top-level modules (or is from a .cpp file 
to a module it imports); actually, that is the only case that I have run into 
in practice.

In this patch, I think the right thing is to just not emit 
`note_module_need_top_level` nor `note_module_need_textual`. A separate patch 
can use a flag `-Wintial-modules-migration` (or whatever) to emit these notes a 
bit more aggressively (the flag would be off by default).


Comment at: test/Modules/misplaced.cpp:1-12
@@ +1,12 @@
+// RUN: rm -rf %t
+// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -fmodules-cache-path=%t -I 
%S/Inputs %s -verify
+
+namespace N1 {  // expected-note{{namespace 'N1' begins here}}
+#include "dummy.h"  // expected-error{{import of module 'dummy' appears within 
namespace 'N1'}} \
+// expected-note{{consider moving the import to top level}}
+}
+
+void func1() {  // expected-note{{function 'func1' begins here}}
+#include "dummy.h"  // expected-error{{import of module 'dummy' appears within 
function 'func1'}} \
+// expected-note{{consider marking the header as textual}}
+}

This test does not cover the `appears within class` case.


http://reviews.llvm.org/D11844



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D11279: Initial patch for PS4 toolchain

[Sean Silva via cfe-commits]

silvas added a subscriber: silvas.
silvas added a comment.

Once this lands, I think we can revert r247977


http://reviews.llvm.org/D11279



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [clang-tools-extra] r248080 - clang-tools-extra: Appease PR24881. [-Wdocumentation]

[Sean Silva via cfe-commits]

Thanks!

-- Sean Silva

On Fri, Sep 18, 2015 at 7:21 PM, NAKAMURA Takumi via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: chapuni
> Date: Fri Sep 18 21:21:28 2015
> New Revision: 248080
>
> URL: http://llvm.org/viewvc/llvm-project?rev=248080&view=rev
> Log:
> clang-tools-extra: Appease PR24881. [-Wdocumentation]
>
> \returns doesn't accept \li, but \parblock \li.
>
> Modified:
>
> clang-tools-extra/trunk/clang-apply-replacements/include/clang-apply-replacements/Tooling/ApplyReplacements.h
>
> clang-tools-extra/trunk/clang-apply-replacements/lib/Tooling/ApplyReplacements.cpp
>
> clang-tools-extra/trunk/clang-apply-replacements/tool/ClangApplyReplacementsMain.cpp
> clang-tools-extra/trunk/clang-modernize/Core/IncludeDirectives.h
> clang-tools-extra/trunk/clang-modernize/Core/ReplacementHandling.h
> clang-tools-extra/trunk/clang-modernize/Core/Transform.h
>
> Modified:
> clang-tools-extra/trunk/clang-apply-replacements/include/clang-apply-replacements/Tooling/ApplyReplacements.h
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-apply-replacements/include/clang-apply-replacements/Tooling/ApplyReplacements.h?rev=248080&r1=248079&r2=248080&view=diff
>
> ==
> ---
> clang-tools-extra/trunk/clang-apply-replacements/include/clang-apply-replacements/Tooling/ApplyReplacements.h
> (original)
> +++
> clang-tools-extra/trunk/clang-apply-replacements/include/clang-apply-replacements/Tooling/ApplyReplacements.h
> Fri Sep 18 21:21:28 2015
> @@ -84,7 +84,8 @@ collectReplacementsFromDirectory(const l
>  /// file they target.
>  /// \param[in] SM SourceManager required for conflict reporting.
>  ///
> -/// \returns \li true If all changes were applied successfully.
> +/// \returns \parblock
> +///  \li true If all changes were applied successfully.
>  ///  \li false If there were conflicts.
>  bool mergeAndDeduplicate(const TUReplacements &TUs,
>   FileToReplacementsMap &GroupedReplacements,
> @@ -97,7 +98,8 @@ bool mergeAndDeduplicate(const TUReplace
>  /// \param[out] Rewrites The results of applying replacements will be
> applied
>  /// to this Rewriter.
>  ///
> -/// \returns \li true If all changes were applied successfully.
> +/// \returns \parblock
> +///  \li true If all changes were applied successfully.
>  ///  \li false If a replacement failed to apply.
>  bool applyReplacements(const FileToReplacementsMap &GroupedReplacements,
> clang::Rewriter &Rewrites);
> @@ -125,7 +127,8 @@ bool writeFiles(const clang::Rewriter &R
>  /// \param[in] Files Replacement files to delete.
>  /// \param[in] Diagnostics DiagnosticsEngine used for error output.
>  ///
> -/// \returns \li true If all files have been deleted successfully.
> +/// \returns \parblock
> +///  \li true If all files have been deleted successfully.
>  ///  \li false If at least one or more failures occur when
> deleting
>  /// files.
>  bool deleteReplacementFiles(const TUReplacementFiles &Files,
>
> Modified:
> clang-tools-extra/trunk/clang-apply-replacements/lib/Tooling/ApplyReplacements.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-apply-replacements/lib/Tooling/ApplyReplacements.cpp?rev=248080&r1=248079&r2=248080&view=diff
>
> ==
> ---
> clang-tools-extra/trunk/clang-apply-replacements/lib/Tooling/ApplyReplacements.cpp
> (original)
> +++
> clang-tools-extra/trunk/clang-apply-replacements/lib/Tooling/ApplyReplacements.cpp
> Fri Sep 18 21:21:28 2015
> @@ -131,7 +131,8 @@ static void reportConflict(
>  /// to be deduplicated and checked for conflicts.
>  /// \param[in] SM SourceManager required for conflict reporting.
>  ///
> -/// \returns \li true if conflicts were detected
> +/// \returns \parblock
> +///  \li true if conflicts were detected
>  ///  \li false if no conflicts were detected
>  static bool deduplicateAndDetectConflicts(FileToReplacementsMap
> &Replacements,
>SourceManager &SM) {
>
> Modified:
> clang-tools-extra/trunk/clang-apply-replacements/tool/ClangApplyReplacementsMain.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-apply-replacements/tool/ClangApplyReplacementsMain.cpp?rev=248080&r1=248079&r2=248080&view=diff
>
> ==
> ---
> clang-tools-extra/trunk/clang-apply-replacements/tool/ClangApplyReplacementsMain.cpp
> (original)
> +++
> clang-tools-extra/trunk/clang-apply-replacements/tool/ClangApplyReplacementsMain.cpp
> Fri Sep 18 21:21:28 2015
> @@ -100,7 +100,8 @@ static void printVersion() {
>  /// \param[out] Result Contents of the file after applying replacements if
>  /// replacements were provided.
>  ///
> -/// \returns \li true if all replacement

Re: r248953 - [Sema] Don't crash when friending an unqualified templated constructor

[Sean Silva via cfe-commits]

On Wed, Sep 30, 2015 at 3:07 PM, David Majnemer via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: majnemer
> Date: Wed Sep 30 17:07:43 2015
> New Revision: 248953
>
> URL: http://llvm.org/viewvc/llvm-project?rev=248953&view=rev
> Log:
> [Sema] Don't crash when friending an unqualified templated constructor
>
> Unqualified templated constructors cannot be friended and our lack of a
> diagnostic led to violated invariants.  Instead, raise a diagnostic when
> processing the friend declaration.
>
> This fixes PR20251.
>
> Modified:
> cfe/trunk/lib/Sema/SemaDeclCXX.cpp
> cfe/trunk/test/CXX/class/class.friend/p1.cpp
>
> Modified: cfe/trunk/lib/Sema/SemaDeclCXX.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclCXX.cpp?rev=248953&r1=248952&r2=248953&view=diff
>
> ==
> --- cfe/trunk/lib/Sema/SemaDeclCXX.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaDeclCXX.cpp Wed Sep 30 17:07:43 2015
> @@ -12689,15 +12689,31 @@ NamedDecl *Sema::ActOnFriendFunctionDecl
>  DC = CurContext;
>  assert(isa(DC) && "friend declaration not in class?");
>}
> -
> +
>if (!DC->isRecord()) {
> +int DiagArg = -1;
> +switch (D.getName().getKind()) {
> +case UnqualifiedId::IK_ConstructorTemplateId:
> +case UnqualifiedId::IK_ConstructorName:
> +  DiagArg = 0;
> +  break;
> +case UnqualifiedId::IK_DestructorName:
> +  DiagArg = 1;
> +  break;
> +case UnqualifiedId::IK_ConversionFunctionId:
> +  DiagArg = 2;
> +  break;
> +case UnqualifiedId::IK_Identifier:
> +case UnqualifiedId::IK_ImplicitSelfParam:
> +case UnqualifiedId::IK_LiteralOperatorId:
> +case UnqualifiedId::IK_OperatorFunctionId:
> +case UnqualifiedId::IK_TemplateId:
> +  break;
> +  llvm_unreachable("Didn't expect this kind of unqualified-id!");
>

Is the break followed by unreachable intentional?

-- Sean Silva


> +}
>  // This implies that it has to be an operator or function.
> -if (D.getName().getKind() == UnqualifiedId::IK_ConstructorName ||
> -D.getName().getKind() == UnqualifiedId::IK_DestructorName ||
> -D.getName().getKind() == UnqualifiedId::IK_ConversionFunctionId) {
> -  Diag(Loc, diag::err_introducing_special_friend) <<
> -(D.getName().getKind() == UnqualifiedId::IK_ConstructorName ? 0 :
> - D.getName().getKind() == UnqualifiedId::IK_DestructorName ? 1 :
> 2);
> +if (DiagArg >= 0) {
> +  Diag(Loc, diag::err_introducing_special_friend) << DiagArg;
>return nullptr;
>  }
>}
>
> Modified: cfe/trunk/test/CXX/class/class.friend/p1.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CXX/class/class.friend/p1.cpp?rev=248953&r1=248952&r2=248953&view=diff
>
> ==
> --- cfe/trunk/test/CXX/class/class.friend/p1.cpp (original)
> +++ cfe/trunk/test/CXX/class/class.friend/p1.cpp Wed Sep 30 17:07:43 2015
> @@ -79,3 +79,9 @@ class PreDeclared;
>  int myoperation(float f) {
>return (int) f;
>  }
> +
> +template 
> +class B {
> +  template 
> +  friend B() {} // expected-error {{must use a qualified name when
> declaring a constructor as a friend}}
> +};
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D12747: Implement [depr.c.headers]

[Sean Silva via cfe-commits]

+extern "C++" {
+#include <__nullptr>
+using std::nullptr_t;
+}

Does this even compile with modules?


-- Sean Silva

On Tue, Oct 6, 2015 at 3:57 PM, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> . This one is tricky:
>
> 1) There's an (undocumented) interface between the C standard library and
> this header, where the macros __need_ptrdiff_t, __need_size_t,
> __need_wchar_t, __need_NULL, __need_wint_t request just a piece of this
> header rather than the whole thing. If we see any of those, just go
> straight to the underlying header.
>
> 2) We probably don't want  to include  (for consistency
> with other headers), but  must provide a ::nullptr_t (which we
> don't want  to provide). So neither header includes the other.
> Instead, both include <__nullptr> for std::nullptr_t, and we duplicate the
> definition of max_align_t between them, in the case where the compiler's
>  doesn't provide it.
>
> If you prefer, I could make  include  to avoid the
> duplication of the max_align_t logic.
>
> This patch depends on patch 02.
>
> On Tue, Oct 6, 2015 at 3:42 PM, Richard Smith 
> wrote:
>
>> , an easy one. We guarantee a setjmp macro exists even if this
>> header is somehow included from C (the C standard allows that, so it's not
>> worth checking for __cplusplus).
>>
>> On Tue, Oct 6, 2015 at 3:36 PM, Richard Smith 
>> wrote:
>>
>>> Split  out of . This is a big change, but the same
>>> pattern as the prior ones.
>>>
>>> On Tue, Oct 6, 2015 at 3:28 PM, Richard Smith 
>>> wrote:
>>>
 Likewise for , , 

 On Tue, Oct 6, 2015 at 3:20 PM, Richard Smith 
 wrote:

> Split  header out of 
>
> On Tue, Oct 6, 2015 at 3:07 PM, Richard Smith 
> wrote:
>
>> Next: factoring the definition of std::nullptr_t out into a separate
>> file, so that  and  can both use it, without 
>> 
>> including  and without  providing a ::nullptr_t like
>>  does.
>>
>> On Tue, Oct 6, 2015 at 3:02 PM, Eric Fiselier  wrote:
>>
>>> LGTM.
>>>
>>> On Tue, Oct 6, 2015 at 3:58 PM, Richard Smith 
>>> wrote:
>>> > On Mon, Oct 5, 2015 at 7:10 PM, Eric Fiselier 
>>> wrote:
>>> >>
>>> >> EricWF added a comment.
>>> >>
>>> >> I think thing change will help us close a number out outstanding
>>> bugs. I
>>> >> don't have any fundamental objections to this approach.  However
>>> the size of
>>> >> this patch scares me.  I understand the changes are mostly
>>> mechanical but
>>> >> their size can hide things. For example has anybody noticed that
>>> your
>>> >> internal changes to `` are in this patch? It would be nice
>>> to break
>>> >> this down into more digestible pieces that could be quickly spot
>>> checked.
>>> >
>>> >
>>> > OK. First such patch is attached. It just removes the
>>> macro-capturing
>>> > wrapper functions.
>>>
>>
>>
>

>>>
>>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D12747: Implement [depr.c.headers]

[Sean Silva via cfe-commits]

On Tue, Oct 6, 2015 at 4:13 PM, Richard Smith  wrote:

> On Tue, Oct 6, 2015 at 4:11 PM, Sean Silva  wrote:
>
>> +extern "C++" {
>> +#include <__nullptr>
>> +using std::nullptr_t;
>> +}
>>
>> Does this even compile with modules?
>>
>
> Yes. You're allowed to import a C++ module within an 'extern "C++"' block.
>

Why do we even need `extern "C++"` if we are already under `#ifdef
__cplusplus`?

-- Sean Silva


>
>
>> On Tue, Oct 6, 2015 at 3:57 PM, Richard Smith via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> . This one is tricky:
>>>
>>> 1) There's an (undocumented) interface between the C standard library
>>> and this header, where the macros __need_ptrdiff_t, __need_size_t,
>>> __need_wchar_t, __need_NULL, __need_wint_t request just a piece of this
>>> header rather than the whole thing. If we see any of those, just go
>>> straight to the underlying header.
>>>
>>> 2) We probably don't want  to include  (for
>>> consistency with other headers), but  must provide a ::nullptr_t
>>> (which we don't want  to provide). So neither header includes the
>>> other. Instead, both include <__nullptr> for std::nullptr_t, and we
>>> duplicate the definition of max_align_t between them, in the case where the
>>> compiler's  doesn't provide it.
>>>
>>> If you prefer, I could make  include  to avoid the
>>> duplication of the max_align_t logic.
>>>
>>> This patch depends on patch 02.
>>>
>>> On Tue, Oct 6, 2015 at 3:42 PM, Richard Smith 
>>> wrote:
>>>
 , an easy one. We guarantee a setjmp macro exists even if
 this header is somehow included from C (the C standard allows that, so it's
 not worth checking for __cplusplus).

 On Tue, Oct 6, 2015 at 3:36 PM, Richard Smith 
 wrote:

> Split  out of . This is a big change, but the same
> pattern as the prior ones.
>
> On Tue, Oct 6, 2015 at 3:28 PM, Richard Smith 
> wrote:
>
>> Likewise for , , 
>>
>> On Tue, Oct 6, 2015 at 3:20 PM, Richard Smith 
>> wrote:
>>
>>> Split  header out of 
>>>
>>> On Tue, Oct 6, 2015 at 3:07 PM, Richard Smith >> > wrote:
>>>
 Next: factoring the definition of std::nullptr_t out into a
 separate file, so that  and  can both use it, 
 without
  including  and without  providing a
 ::nullptr_t like  does.

 On Tue, Oct 6, 2015 at 3:02 PM, Eric Fiselier  wrote:

> LGTM.
>
> On Tue, Oct 6, 2015 at 3:58 PM, Richard Smith <
> rich...@metafoo.co.uk> wrote:
> > On Mon, Oct 5, 2015 at 7:10 PM, Eric Fiselier 
> wrote:
> >>
> >> EricWF added a comment.
> >>
> >> I think thing change will help us close a number out
> outstanding bugs. I
> >> don't have any fundamental objections to this approach.
> However the size of
> >> this patch scares me.  I understand the changes are mostly
> mechanical but
> >> their size can hide things. For example has anybody noticed
> that your
> >> internal changes to `` are in this patch? It would be
> nice to break
> >> this down into more digestible pieces that could be quickly
> spot checked.
> >
> >
> > OK. First such patch is attached. It just removes the
> macro-capturing
> > wrapper functions.
>


>>>
>>
>

>>>
>>> ___
>>> cfe-commits mailing list
>>> cfe-commits@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>>
>>>
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D11844: [Modules] More descriptive diagnostics for misplaced import directive

[Sean Silva via cfe-commits]

silvas added a subscriber: silvas.


Comment at: lib/Parse/Parser.cpp:2003
@@ +2002,3 @@
+Diag(Tok, diag::err_unexpected_module_start);
+// Recover by skipping content of the included submodule.
+unsigned ModuleNesting = 1;

rsmith wrote:
> This is liable to produce bad follow-on diagnostics; I don't think this is a 
> reasonable way to recover. I can see a few feasible options here:
> 
> 1) Emit a fatal error when this happens (suppressing further diagnostics)
> 2) Break out to the top level of parsing and resume from there (that is, 
> assume that a modular header expects to be included at the top level and that 
> the user didn't screw up their module map)
> 3) Enter the module and carry on parsing from here
> 
> My preference would be either (1) or (2). But either way, we should diagnose 
> the still-open bracketing constructs, because the problem is likely to be a 
> missing close brace at the end of an unrelated header file.
I strongly prefer (1). In all cases I have recorded in my notes when 
modularizing, the `error: expected '}'` diagnostic indicated one of two things:
- that a header needed to be marked textual in the module map.
- that a #include had to be moved to the top of the file (this case was likely 
behaving unexpectedly in the non-modules case and "happened to work").
For the sake of our users, it is probably best to immediately fatal error and 
suggest an alternative (the suggestions can be a separate patch; my 
recommendations are below).

I believe a user is most likely to run into this diagnostic when developing an 
initial set of module maps, so our diagnostic should be tailored to that 
audience. These users may have little experience with modules when they 
encounter this diagnostic, so a notes suggesting a likely remedy helps them 
develop confidence by providing authoritative advice (and avoiding a round trip 
to the documentation).

My fine-grained recommendations from experience are:
- #include inside extern "C": always meant to be modular, always the fix is to 
move it out of the braced block.
- #include inside namespace: always meant to be modular, always the fix is to 
move it out of the braced block.
- #include inside class: always textual (e.g. bringing in methods like TableGen 
.inc files; sometimes similar ".inc" files are manually written and not 
autogenerated. I have observed e.g. "classfoo_methods.h" files; another 
instance of this is stamping out ".def" files)
- #include inside array initializer: always textual. Typically ".def" files
- #include inside function: always textual. Typically ".def" files (e.g. 
generate a switch)

".inl" files are theoretically a problem inside namespaces, but I have not 
observed this issue in practice. In my experience code taking the effort to 
have ".inl" files is quite clean and avoids such textual dependencies. The 
issues I have seen in practice with ".inl" files usually end up coming out 
through a different part of clang. Improving that is for a separate patch 
though.


http://reviews.llvm.org/D11844



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D11844: [Modules] More descriptive diagnostics for misplaced import directive

[Sean Silva via cfe-commits]

On Wed, Aug 12, 2015 at 2:43 PM, Richard Smith 
wrote:

> On Wed, Aug 12, 2015 at 12:08 AM, Sean Silva 
> wrote:
>
>> silvas added a subscriber: silvas.
>>
>> 
>> Comment at: lib/Parse/Parser.cpp:2003
>> @@ +2002,3 @@
>> +Diag(Tok, diag::err_unexpected_module_start);
>> +// Recover by skipping content of the included submodule.
>> +unsigned ModuleNesting = 1;
>> 
>> rsmith wrote:
>> > This is liable to produce bad follow-on diagnostics; I don't think this
>> is a reasonable way to recover. I can see a few feasible options here:
>> >
>> > 1) Emit a fatal error when this happens (suppressing further
>> diagnostics)
>> > 2) Break out to the top level of parsing and resume from there (that
>> is, assume that a modular header expects to be included at the top level
>> and that the user didn't screw up their module map)
>> > 3) Enter the module and carry on parsing from here
>> >
>> > My preference would be either (1) or (2). But either way, we should
>> diagnose the still-open bracketing constructs, because the problem is
>> likely to be a missing close brace at the end of an unrelated header file.
>> I strongly prefer (1). In all cases I have recorded in my notes when
>> modularizing, the `error: expected '}'` diagnostic indicated one of two
>> things:
>> - that a header needed to be marked textual in the module map.
>> - that a #include had to be moved to the top of the file (this case was
>> likely behaving unexpectedly in the non-modules case and "happened to
>> work").
>> For the sake of our users, it is probably best to immediately fatal error
>> and suggest an alternative (the suggestions can be a separate patch; my
>> recommendations are below).
>>
>> I believe a user is most likely to run into this diagnostic when
>> developing an initial set of module maps, so our diagnostic should be
>> tailored to that audience.
>
>
> I think your observations may be biased by your current experiences
> modularizing existing code, and not representative of the complete
> development cycle. Modularization is a one-time effort; maintaining the
> code after modularization is a continuous process. I think it's *far* more
> likely that a header listed in your module map was expected to be modular,
> and that a brace mismatch within that file is unintentional and due to a
> missing brace somewhere.
>

I don't think so. That implies that the inclusion is not at the top of the
file, which is extremely unlikely in a modular codebase.

125993 #include lines.


>
> However, we should aim to provide diagnostics that are helpful for either
> case.
>
> These users may have little experience with modules when they encounter
>> this diagnostic, so a notes suggesting a likely remedy helps them develop
>> confidence by providing authoritative advice (and avoiding a round trip to
>> the documentation).
>>
>> My fine-grained recommendations from experience are:
>> - #include inside extern "C": always meant to be modular, always the fix
>> is to move it out of the braced block.
>> - #include inside namespace: always meant to be modular, always the fix
>> is to move it out of the braced block.
>> - #include inside class: always textual (e.g. bringing in methods like
>> TableGen .inc files; sometimes similar ".inc" files are manually written
>> and not autogenerated. I have observed e.g. "classfoo_methods.h" files;
>> another instance of this is stamping out ".def" files)
>> - #include inside array initializer: always textual. Typically ".def"
>> files
>> - #include inside function: always textual. Typically ".def" files (e.g.
>> generate a switch)
>>
>> ".inl" files are theoretically a problem inside namespaces, but I have
>> not observed this issue in practice. In my experience code taking the
>> effort to have ".inl" files is quite clean and avoids such textual
>> dependencies. The issues I have seen in practice with ".inl" files usually
>> end up coming out through a different part of clang. Improving that is for
>> a separate patch though.
>>
>>
>> http://reviews.llvm.org/D11844
>>
>>
>>
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D11844: [Modules] More descriptive diagnostics for misplaced import directive

[Sean Silva via cfe-commits]

On Wed, Aug 12, 2015 at 6:00 PM, Sean Silva  wrote:

>
>
> On Wed, Aug 12, 2015 at 2:43 PM, Richard Smith 
> wrote:
>
>> On Wed, Aug 12, 2015 at 12:08 AM, Sean Silva 
>> wrote:
>>
>>> silvas added a subscriber: silvas.
>>>
>>> 
>>> Comment at: lib/Parse/Parser.cpp:2003
>>> @@ +2002,3 @@
>>> +Diag(Tok, diag::err_unexpected_module_start);
>>> +// Recover by skipping content of the included submodule.
>>> +unsigned ModuleNesting = 1;
>>> 
>>> rsmith wrote:
>>> > This is liable to produce bad follow-on diagnostics; I don't think
>>> this is a reasonable way to recover. I can see a few feasible options here:
>>> >
>>> > 1) Emit a fatal error when this happens (suppressing further
>>> diagnostics)
>>> > 2) Break out to the top level of parsing and resume from there (that
>>> is, assume that a modular header expects to be included at the top level
>>> and that the user didn't screw up their module map)
>>> > 3) Enter the module and carry on parsing from here
>>> >
>>> > My preference would be either (1) or (2). But either way, we should
>>> diagnose the still-open bracketing constructs, because the problem is
>>> likely to be a missing close brace at the end of an unrelated header file.
>>> I strongly prefer (1). In all cases I have recorded in my notes when
>>> modularizing, the `error: expected '}'` diagnostic indicated one of two
>>> things:
>>> - that a header needed to be marked textual in the module map.
>>> - that a #include had to be moved to the top of the file (this case was
>>> likely behaving unexpectedly in the non-modules case and "happened to
>>> work").
>>> For the sake of our users, it is probably best to immediately fatal
>>> error and suggest an alternative (the suggestions can be a separate patch;
>>> my recommendations are below).
>>>
>>> I believe a user is most likely to run into this diagnostic when
>>> developing an initial set of module maps, so our diagnostic should be
>>> tailored to that audience.
>>
>>
>> I think your observations may be biased by your current experiences
>> modularizing existing code, and not representative of the complete
>> development cycle. Modularization is a one-time effort; maintaining the
>> code after modularization is a continuous process. I think it's *far* more
>> likely that a header listed in your module map was expected to be modular,
>> and that a brace mismatch within that file is unintentional and due to a
>> missing brace somewhere.
>>
>
> I don't think so. That implies that the inclusion is not at the top of the
> file, which is extremely unlikely in a modular codebase.
>
> 125993 #include lines.
>

Oops, apparently I accidentally hit send...
I'm gathering some real statistics on this.

-- Sean Silva


>
>
>>
>> However, we should aim to provide diagnostics that are helpful for either
>> case.
>>
>> These users may have little experience with modules when they encounter
>>> this diagnostic, so a notes suggesting a likely remedy helps them develop
>>> confidence by providing authoritative advice (and avoiding a round trip to
>>> the documentation).
>>>
>>> My fine-grained recommendations from experience are:
>>> - #include inside extern "C": always meant to be modular, always the fix
>>> is to move it out of the braced block.
>>> - #include inside namespace: always meant to be modular, always the fix
>>> is to move it out of the braced block.
>>> - #include inside class: always textual (e.g. bringing in methods like
>>> TableGen .inc files; sometimes similar ".inc" files are manually written
>>> and not autogenerated. I have observed e.g. "classfoo_methods.h" files;
>>> another instance of this is stamping out ".def" files)
>>> - #include inside array initializer: always textual. Typically ".def"
>>> files
>>> - #include inside function: always textual. Typically ".def" files (e.g.
>>> generate a switch)
>>>
>>> ".inl" files are theoretically a problem inside namespaces, but I have
>>> not observed this issue in practice. In my experience code taking the
>>> effort to have ".inl" files is quite clean and avoids such textual
>>> dependencies. The issues I have seen in practice with ".inl" files usually
>>> end up coming out through a different part of clang. Improving that is for
>>> a separate patch though.
>>>
>>>
>>> http://reviews.llvm.org/D11844
>>>
>>>
>>>
>>>
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D11844: [Modules] More descriptive diagnostics for misplaced import directive

[Sean Silva via cfe-commits]

On Wed, Aug 12, 2015 at 6:05 PM, Richard Smith 
wrote:

> On Wed, Aug 12, 2015 at 6:00 PM, Sean Silva  wrote:
>
>>
>>
>> On Wed, Aug 12, 2015 at 2:43 PM, Richard Smith 
>> wrote:
>>
>>> On Wed, Aug 12, 2015 at 12:08 AM, Sean Silva 
>>> wrote:
>>>
 silvas added a subscriber: silvas.

 
 Comment at: lib/Parse/Parser.cpp:2003
 @@ +2002,3 @@
 +Diag(Tok, diag::err_unexpected_module_start);
 +// Recover by skipping content of the included submodule.
 +unsigned ModuleNesting = 1;
 
 rsmith wrote:
 > This is liable to produce bad follow-on diagnostics; I don't think
 this is a reasonable way to recover. I can see a few feasible options here:
 >
 > 1) Emit a fatal error when this happens (suppressing further
 diagnostics)
 > 2) Break out to the top level of parsing and resume from there (that
 is, assume that a modular header expects to be included at the top level
 and that the user didn't screw up their module map)
 > 3) Enter the module and carry on parsing from here
 >
 > My preference would be either (1) or (2). But either way, we should
 diagnose the still-open bracketing constructs, because the problem is
 likely to be a missing close brace at the end of an unrelated header file.
 I strongly prefer (1). In all cases I have recorded in my notes when
 modularizing, the `error: expected '}'` diagnostic indicated one of two
 things:
 - that a header needed to be marked textual in the module map.
 - that a #include had to be moved to the top of the file (this case was
 likely behaving unexpectedly in the non-modules case and "happened to
 work").
 For the sake of our users, it is probably best to immediately fatal
 error and suggest an alternative (the suggestions can be a separate patch;
 my recommendations are below).

 I believe a user is most likely to run into this diagnostic when
 developing an initial set of module maps, so our diagnostic should be
 tailored to that audience.
>>>
>>>
>>> I think your observations may be biased by your current experiences
>>> modularizing existing code, and not representative of the complete
>>> development cycle. Modularization is a one-time effort; maintaining the
>>> code after modularization is a continuous process. I think it's *far* more
>>> likely that a header listed in your module map was expected to be modular,
>>> and that a brace mismatch within that file is unintentional and due to a
>>> missing brace somewhere.
>>>
>>
>> I don't think so. That implies that the inclusion is not at the top of
>> the file, which is extremely unlikely in a modular codebase.
>>
>
> This also happens when there's a missing brace at the end of your modular
> header, which is almost certainly the most common way to hit this problem
> in an already-modularized codebase. And it happens in codebases that use a
> mixture of modular and non-modular headers, where there's no reason to
> expect all the modular includes are before the non-modular ones.
>

:lets-do-both.jpg:

Do we have a way to guard just notes behind warning flags? Maybe
"-Winitial-module-map" or something could enable the "assume this module
map might have errors" heuristics (which in my experience are highly
reliable for that use case). We can document to users to turn this on when
initially modularizing.

-- Sean Silva


>
>
>> 125993 #include lines.
>>
>>
>>>
>>> However, we should aim to provide diagnostics that are helpful for
>>> either case.
>>>
>>> These users may have little experience with modules when they encounter
 this diagnostic, so a notes suggesting a likely remedy helps them develop
 confidence by providing authoritative advice (and avoiding a round trip to
 the documentation).

 My fine-grained recommendations from experience are:
 - #include inside extern "C": always meant to be modular, always the
 fix is to move it out of the braced block.
 - #include inside namespace: always meant to be modular, always the fix
 is to move it out of the braced block.
 - #include inside class: always textual (e.g. bringing in methods like
 TableGen .inc files; sometimes similar ".inc" files are manually written
 and not autogenerated. I have observed e.g. "classfoo_methods.h" files;
 another instance of this is stamping out ".def" files)
 - #include inside array initializer: always textual. Typically ".def"
 files
 - #include inside function: always textual. Typically ".def" files
 (e.g. generate a switch)

 ".inl" files are theoretically a problem inside namespaces, but I have
 not observed this issue in practice. In my experience code taking the
 effort to have ".inl" files is quite clean and avoids such textual
 dependencies. The issues I have seen in practice with ".inl" files usually
 end up coming out through a different part of clang.

Re: r244912 - [Modules] Add Darwin-specific compatibility module map parsing hacks

[Sean Silva via cfe-commits]

This was the last thing blocking http://reviews.llvm.org/D10423, right?

-- Sean Silva

On Thu, Aug 13, 2015 at 10:13 AM, Ben Langmuir via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: benlangmuir
> Date: Thu Aug 13 12:13:33 2015
> New Revision: 244912
>
> URL: http://llvm.org/viewvc/llvm-project?rev=244912&view=rev
> Log:
> [Modules] Add Darwin-specific compatibility module map parsing hacks
>
> This preserves backwards compatibility for two hacks in the Darwin
> system module map files:
>
> 1. The use of 'requires excluded' to make headers non-modular, which
> should really be mapped to 'textual' now that we have this feature.
>
> 2. Silently removes a bogus cplusplus requirement from IOKit.avc.
>
> Once we start diagnosing missing requirements and headers on
> auto-imports these would have broken compatibility with existing Darwin
> SDKs.
>
> Added:
> cfe/trunk/test/Modules/Inputs/System/usr/include/assert.h
> cfe/trunk/test/Modules/Inputs/System/usr/include/tcl-private/
> cfe/trunk/test/Modules/Inputs/System/usr/include/tcl-private/header.h
> cfe/trunk/test/Modules/darwin_specific_modulemap_hacks.m
> Modified:
> cfe/trunk/include/clang/Basic/Module.h
> cfe/trunk/lib/Basic/Module.cpp
> cfe/trunk/lib/Lex/ModuleMap.cpp
> cfe/trunk/test/Modules/Inputs/System/usr/include/module.map
>
> Modified: cfe/trunk/include/clang/Basic/Module.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Module.h?rev=244912&r1=244911&r2=244912&view=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/Module.h (original)
> +++ cfe/trunk/include/clang/Basic/Module.h Thu Aug 13 12:13:33 2015
> @@ -356,6 +356,12 @@ public:
>/// its top-level module.
>std::string getFullModuleName() const;
>
> +  /// \brief Whether the full name of this module is equal to joining
> +  /// \p nameParts with "."s.
> +  ///
> +  /// This is more efficient than getFullModuleName().
> +  bool fullModuleNameIs(ArrayRef nameParts) const;
> +
>/// \brief Retrieve the top-level module for this (sub)module, which may
>/// be this module.
>Module *getTopLevelModule() {
>
> Modified: cfe/trunk/lib/Basic/Module.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Module.cpp?rev=244912&r1=244911&r2=244912&view=diff
>
> ==
> --- cfe/trunk/lib/Basic/Module.cpp (original)
> +++ cfe/trunk/lib/Basic/Module.cpp Thu Aug 13 12:13:33 2015
> @@ -139,6 +139,15 @@ std::string Module::getFullModuleName()
>return Result;
>  }
>
> +bool Module::fullModuleNameIs(ArrayRef nameParts) const {
> +  for (const Module *M = this; M; M = M->Parent) {
> +if (nameParts.empty() || M->Name != nameParts.back())
> +  return false;
> +nameParts = nameParts.drop_back();
> +  }
> +  return nameParts.empty();
> +}
> +
>  Module::DirectoryName Module::getUmbrellaDir() const {
>if (Header U = getUmbrellaHeader())
>  return {"", U.Entry->getDir()};
>
> Modified: cfe/trunk/lib/Lex/ModuleMap.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/ModuleMap.cpp?rev=244912&r1=244911&r2=244912&view=diff
>
> ==
> --- cfe/trunk/lib/Lex/ModuleMap.cpp (original)
> +++ cfe/trunk/lib/Lex/ModuleMap.cpp Thu Aug 13 12:13:33 2015
> @@ -1015,7 +1015,17 @@ namespace clang {
>
>  /// \brief The active module.
>  Module *ActiveModule;
> -
> +
> +/// \brief Whether a module uses the 'requires excluded' hack to mark
> its
> +/// contents as 'textual'.
> +///
> +/// On older Darwin SDK versions, 'requires excluded' is used to mark
> the
> +/// contents of the Darwin.C.excluded (assert.h) and Tcl.Private
> modules as
> +/// non-modular headers.  For backwards compatibility, we continue to
> +/// support this idiom for just these modules, and map the headers to
> +/// 'textual' to match the original intent.
> +llvm::SmallPtrSet UsesRequiresExcludedHack;
> +
>  /// \brief Consume the current token and return its location.
>  SourceLocation consumeToken();
>
> @@ -1570,6 +1580,38 @@ void ModuleMapParser::parseExternModuleD
>  : File->getDir(), ExternLoc);
>  }
>
> +/// Whether to add the requirement \p Feature to the module \p M.
> +///
> +/// This preserves backwards compatibility for two hacks in the Darwin
> system
> +/// module map files:
> +///
> +/// 1. The use of 'requires excluded' to make headers non-modular, which
> +///should really be mapped to 'textual' now that we have this
> feature.  We
> +///drop the 'excluded' requirement, and set \p IsRequiresExcludedHack
> to
> +///true.  Later, this bit will be used to map all the headers inside
> this
> +///module to 'textual'.
> +///
> +///This affects Darwin.C.excluded (for assert.h) and Tcl.Private.
> +///
> +/// 2. Removes a b

Re: r244912 - [Modules] Add Darwin-specific compatibility module map parsing hacks

[Sean Silva via cfe-commits]

This was the last thing blocking http://reviews.llvm.org/D10423 on your
side, right?

-- Sean Silva

On Thu, Aug 13, 2015 at 10:13 AM, Ben Langmuir via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: benlangmuir
> Date: Thu Aug 13 12:13:33 2015
> New Revision: 244912
>
> URL: http://llvm.org/viewvc/llvm-project?rev=244912&view=rev
> Log:
> [Modules] Add Darwin-specific compatibility module map parsing hacks
>
> This preserves backwards compatibility for two hacks in the Darwin
> system module map files:
>
> 1. The use of 'requires excluded' to make headers non-modular, which
> should really be mapped to 'textual' now that we have this feature.
>
> 2. Silently removes a bogus cplusplus requirement from IOKit.avc.
>
> Once we start diagnosing missing requirements and headers on
> auto-imports these would have broken compatibility with existing Darwin
> SDKs.
>
> Added:
> cfe/trunk/test/Modules/Inputs/System/usr/include/assert.h
> cfe/trunk/test/Modules/Inputs/System/usr/include/tcl-private/
> cfe/trunk/test/Modules/Inputs/System/usr/include/tcl-private/header.h
> cfe/trunk/test/Modules/darwin_specific_modulemap_hacks.m
> Modified:
> cfe/trunk/include/clang/Basic/Module.h
> cfe/trunk/lib/Basic/Module.cpp
> cfe/trunk/lib/Lex/ModuleMap.cpp
> cfe/trunk/test/Modules/Inputs/System/usr/include/module.map
>
> Modified: cfe/trunk/include/clang/Basic/Module.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Module.h?rev=244912&r1=244911&r2=244912&view=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/Module.h (original)
> +++ cfe/trunk/include/clang/Basic/Module.h Thu Aug 13 12:13:33 2015
> @@ -356,6 +356,12 @@ public:
>/// its top-level module.
>std::string getFullModuleName() const;
>
> +  /// \brief Whether the full name of this module is equal to joining
> +  /// \p nameParts with "."s.
> +  ///
> +  /// This is more efficient than getFullModuleName().
> +  bool fullModuleNameIs(ArrayRef nameParts) const;
> +
>/// \brief Retrieve the top-level module for this (sub)module, which may
>/// be this module.
>Module *getTopLevelModule() {
>
> Modified: cfe/trunk/lib/Basic/Module.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Module.cpp?rev=244912&r1=244911&r2=244912&view=diff
>
> ==
> --- cfe/trunk/lib/Basic/Module.cpp (original)
> +++ cfe/trunk/lib/Basic/Module.cpp Thu Aug 13 12:13:33 2015
> @@ -139,6 +139,15 @@ std::string Module::getFullModuleName()
>return Result;
>  }
>
> +bool Module::fullModuleNameIs(ArrayRef nameParts) const {
> +  for (const Module *M = this; M; M = M->Parent) {
> +if (nameParts.empty() || M->Name != nameParts.back())
> +  return false;
> +nameParts = nameParts.drop_back();
> +  }
> +  return nameParts.empty();
> +}
> +
>  Module::DirectoryName Module::getUmbrellaDir() const {
>if (Header U = getUmbrellaHeader())
>  return {"", U.Entry->getDir()};
>
> Modified: cfe/trunk/lib/Lex/ModuleMap.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/ModuleMap.cpp?rev=244912&r1=244911&r2=244912&view=diff
>
> ==
> --- cfe/trunk/lib/Lex/ModuleMap.cpp (original)
> +++ cfe/trunk/lib/Lex/ModuleMap.cpp Thu Aug 13 12:13:33 2015
> @@ -1015,7 +1015,17 @@ namespace clang {
>
>  /// \brief The active module.
>  Module *ActiveModule;
> -
> +
> +/// \brief Whether a module uses the 'requires excluded' hack to mark
> its
> +/// contents as 'textual'.
> +///
> +/// On older Darwin SDK versions, 'requires excluded' is used to mark
> the
> +/// contents of the Darwin.C.excluded (assert.h) and Tcl.Private
> modules as
> +/// non-modular headers.  For backwards compatibility, we continue to
> +/// support this idiom for just these modules, and map the headers to
> +/// 'textual' to match the original intent.
> +llvm::SmallPtrSet UsesRequiresExcludedHack;
> +
>  /// \brief Consume the current token and return its location.
>  SourceLocation consumeToken();
>
> @@ -1570,6 +1580,38 @@ void ModuleMapParser::parseExternModuleD
>  : File->getDir(), ExternLoc);
>  }
>
> +/// Whether to add the requirement \p Feature to the module \p M.
> +///
> +/// This preserves backwards compatibility for two hacks in the Darwin
> system
> +/// module map files:
> +///
> +/// 1. The use of 'requires excluded' to make headers non-modular, which
> +///should really be mapped to 'textual' now that we have this
> feature.  We
> +///drop the 'excluded' requirement, and set \p IsRequiresExcludedHack
> to
> +///true.  Later, this bit will be used to map all the headers inside
> this
> +///module to 'textual'.
> +///
> +///This affects Darwin.C.excluded (for assert.h) and Tcl.Private.
> +///
> +/// 2

Re: r244912 - [Modules] Add Darwin-specific compatibility module map parsing hacks

[Sean Silva via cfe-commits]

On Thu, Aug 13, 2015 at 4:47 PM, Ben Langmuir  wrote:

> Yep, that should be it!
>

Great!

-- Sean Silva


>
> On Aug 13, 2015, at 4:45 PM, Sean Silva  wrote:
>
> This was the last thing blocking http://reviews.llvm.org/D10423 on your
> side, right?
>
> -- Sean Silva
>
> On Thu, Aug 13, 2015 at 10:13 AM, Ben Langmuir via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: benlangmuir
>> Date: Thu Aug 13 12:13:33 2015
>> New Revision: 244912
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=244912&view=rev
>> Log:
>> [Modules] Add Darwin-specific compatibility module map parsing hacks
>>
>> This preserves backwards compatibility for two hacks in the Darwin
>> system module map files:
>>
>> 1. The use of 'requires excluded' to make headers non-modular, which
>> should really be mapped to 'textual' now that we have this feature.
>>
>> 2. Silently removes a bogus cplusplus requirement from IOKit.avc.
>>
>> Once we start diagnosing missing requirements and headers on
>> auto-imports these would have broken compatibility with existing Darwin
>> SDKs.
>>
>> Added:
>> cfe/trunk/test/Modules/Inputs/System/usr/include/assert.h
>> cfe/trunk/test/Modules/Inputs/System/usr/include/tcl-private/
>> cfe/trunk/test/Modules/Inputs/System/usr/include/tcl-private/header.h
>> cfe/trunk/test/Modules/darwin_specific_modulemap_hacks.m
>> Modified:
>> cfe/trunk/include/clang/Basic/Module.h
>> cfe/trunk/lib/Basic/Module.cpp
>> cfe/trunk/lib/Lex/ModuleMap.cpp
>> cfe/trunk/test/Modules/Inputs/System/usr/include/module.map
>>
>> Modified: cfe/trunk/include/clang/Basic/Module.h
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Module.h?rev=244912&r1=244911&r2=244912&view=diff
>>
>> ==
>> --- cfe/trunk/include/clang/Basic/Module.h (original)
>> +++ cfe/trunk/include/clang/Basic/Module.h Thu Aug 13 12:13:33 2015
>> @@ -356,6 +356,12 @@ public:
>>/// its top-level module.
>>std::string getFullModuleName() const;
>>
>> +  /// \brief Whether the full name of this module is equal to joining
>> +  /// \p nameParts with "."s.
>> +  ///
>> +  /// This is more efficient than getFullModuleName().
>> +  bool fullModuleNameIs(ArrayRef nameParts) const;
>> +
>>/// \brief Retrieve the top-level module for this (sub)module, which
>> may
>>/// be this module.
>>Module *getTopLevelModule() {
>>
>> Modified: cfe/trunk/lib/Basic/Module.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Module.cpp?rev=244912&r1=244911&r2=244912&view=diff
>>
>> ==
>> --- cfe/trunk/lib/Basic/Module.cpp (original)
>> +++ cfe/trunk/lib/Basic/Module.cpp Thu Aug 13 12:13:33 2015
>> @@ -139,6 +139,15 @@ std::string Module::getFullModuleName()
>>return Result;
>>  }
>>
>> +bool Module::fullModuleNameIs(ArrayRef nameParts) const {
>> +  for (const Module *M = this; M; M = M->Parent) {
>> +if (nameParts.empty() || M->Name != nameParts.back())
>> +  return false;
>> +nameParts = nameParts.drop_back();
>> +  }
>> +  return nameParts.empty();
>> +}
>> +
>>  Module::DirectoryName Module::getUmbrellaDir() const {
>>if (Header U = getUmbrellaHeader())
>>  return {"", U.Entry->getDir()};
>>
>> Modified: cfe/trunk/lib/Lex/ModuleMap.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/ModuleMap.cpp?rev=244912&r1=244911&r2=244912&view=diff
>>
>> ==
>> --- cfe/trunk/lib/Lex/ModuleMap.cpp (original)
>> +++ cfe/trunk/lib/Lex/ModuleMap.cpp Thu Aug 13 12:13:33 2015
>> @@ -1015,7 +1015,17 @@ namespace clang {
>>
>>  /// \brief The active module.
>>  Module *ActiveModule;
>> -
>> +
>> +/// \brief Whether a module uses the 'requires excluded' hack to
>> mark its
>> +/// contents as 'textual'.
>> +///
>> +/// On older Darwin SDK versions, 'requires excluded' is used to
>> mark the
>> +/// contents of the Darwin.C.excluded (assert.h) and Tcl.Private
>> modules as
>> +/// non-modular headers.  For backwards compatibility, we continue to
>> +/// support this idiom for just these modules, and map the headers to
>> +/// 'textual' to match the original intent.
>> +llvm::SmallPtrSet UsesRequiresExcludedHack;
>> +
>>  /// \brief Consume the current token and return its location.
>>  SourceLocation consumeToken();
>>
>> @@ -1570,6 +1580,38 @@ void ModuleMapParser::parseExternModuleD
>>  : File->getDir(), ExternLoc);
>>  }
>>
>> +/// Whether to add the requirement \p Feature to the module \p M.
>> +///
>> +/// This preserves backwards compatibility for two hacks in the Darwin
>> system
>> +/// module map files:
>> +///
>> +/// 1. The use of 'requires excluded' to make headers non-modular, which
>> +///should really be mapped to 'textual' now that we have this
>> feature.

Re: r244923 - [modules] Change the way we deal with .d output for explicitly-specified module

[Sean Silva via cfe-commits]

On Thu, Aug 13, 2015 at 10:57 AM, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rsmith
> Date: Thu Aug 13 12:57:10 2015
> New Revision: 244923
>
> URL: http://llvm.org/viewvc/llvm-project?rev=244923&view=rev
> Log:
> [modules] Change the way we deal with .d output for explicitly-specified
> module
> files: include the .pcm file itself in the .d output, rather than
> including its
> own input files. Other forms of module file continue to be transparent for
> .d
> output.
>
> Arguably, the input files for the .pcm file are still inputs to the
> compilation, but that's unnecessary for make-like build systems (where the
> mtime of the .pcm file is sufficient) and harmful for smarter build systems
> that know about module files and want to track only the local dependencies.
>

Nice!

-- Sean Silva


>
> Modified:
> cfe/trunk/include/clang/Serialization/ASTReader.h
> cfe/trunk/lib/Frontend/DependencyFile.cpp
> cfe/trunk/lib/Frontend/ModuleDependencyCollector.cpp
> cfe/trunk/lib/Serialization/ASTReader.cpp
> cfe/trunk/test/Modules/dependency-gen.modulemap
>
> Modified: cfe/trunk/include/clang/Serialization/ASTReader.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Serialization/ASTReader.h?rev=244923&r1=244922&r2=244923&view=diff
>
> ==
> --- cfe/trunk/include/clang/Serialization/ASTReader.h (original)
> +++ cfe/trunk/include/clang/Serialization/ASTReader.h Thu Aug 13 12:57:10
> 2015
> @@ -179,7 +179,8 @@ public:
> unsigned Value) {}
>
>/// This is called for each AST file loaded.
> -  virtual void visitModuleFile(StringRef Filename) {}
> +  virtual void visitModuleFile(StringRef Filename,
> +   serialization::ModuleKind Kind) {}
>
>/// \brief Returns true if this \c ASTReaderListener wants to receive
> the
>/// input files of the AST file via \c visitInputFile, false otherwise.
> @@ -194,7 +195,7 @@ public:
>///
>/// \returns true to continue receiving the next input file, false to
> stop.
>virtual bool visitInputFile(StringRef Filename, bool isSystem,
> -  bool isOverridden) {
> +  bool isOverridden, bool isExplicitModule) {
>  return true;
>}
>
> @@ -242,9 +243,10 @@ public:
>void ReadCounter(const serialization::ModuleFile &M, unsigned Value)
> override;
>bool needsInputFileVisitation() override;
>bool needsSystemInputFileVisitation() override;
> -  void visitModuleFile(StringRef Filename) override;
> +  void visitModuleFile(StringRef Filename,
> +   serialization::ModuleKind Kind) override;
>bool visitInputFile(StringRef Filename, bool isSystem,
> -  bool isOverridden) override;
> +  bool isOverridden, bool isExplicitModule) override;
>  };
>
>  /// \brief ASTReaderListener implementation to validate the information of
>
> Modified: cfe/trunk/lib/Frontend/DependencyFile.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/DependencyFile.cpp?rev=244923&r1=244922&r2=244923&view=diff
>
> ==
> --- cfe/trunk/lib/Frontend/DependencyFile.cpp (original)
> +++ cfe/trunk/lib/Frontend/DependencyFile.cpp Thu Aug 13 12:57:10 2015
> @@ -104,14 +104,15 @@ struct DepCollectorASTListener : public
>bool needsSystemInputFileVisitation() override {
>  return DepCollector.needSystemDependencies();
>}
> -  void visitModuleFile(StringRef Filename) override {
> +  void visitModuleFile(StringRef Filename,
> +   serialization::ModuleKind Kind) override {
>  DepCollector.maybeAddDependency(Filename, /*FromModule*/true,
> /*IsSystem*/false,
> /*IsModuleFile*/true,
> /*IsMissing*/false);
>}
>bool visitInputFile(StringRef Filename, bool IsSystem,
> -  bool IsOverridden) override {
> -if (IsOverridden)
> +  bool IsOverridden, bool IsExplicitModule) override {
> +if (IsOverridden || IsExplicitModule)
>return true;
>
>  DepCollector.maybeAddDependency(Filename, /*FromModule*/true,
> IsSystem,
> @@ -226,9 +227,10 @@ public:
>bool needsSystemInputFileVisitation() override {
>  return Parent.includeSystemHeaders();
>}
> -  void visitModuleFile(StringRef Filename) override;
> +  void visitModuleFile(StringRef Filename,
> +   serialization::ModuleKind Kind) override;
>bool visitInputFile(StringRef Filename, bool isSystem,
> -  bool isOverridden) override;
> +  bool isOverridden, bool isExplicitModule) override;
>  };
>  }
>
> @@ -472,16 +474,18 @@ void DFGImpl::OutputDependencyFile() {
>  }
>
>  bool DFGASTReaderListener::visitInputFile(llvm:

r245228 - [modules] PR20507: Avoid silent textual inclusion.

[Sean Silva via cfe-commits]

Author: silvas
Date: Mon Aug 17 11:39:30 2015
New Revision: 245228

URL: http://llvm.org/viewvc/llvm-project?rev=245228&view=rev
Log:
[modules] PR20507: Avoid silent textual inclusion.

Summary:
If a module was unavailable (either a missing requirement on the module
being imported, or a missing file anywhere in the top-level module (and
not dominated by an unsatisfied `requires`)), we would silently treat
inclusions as textual. This would cause all manner of crazy and
confusing errors (and would also silently "work" sometimes, making the
problem difficult to track down).

I'm really not a fan of the `M->isAvailable(getLangOpts(), getTargetInfo(),
Requirement, MissingHeader)` function; it seems to do too many things at
once, but for now I've done things in a sort of awkward way.

The changes to test/Modules/Inputs/declare-use/module.map
were necessitated because the thing that was meant to be tested there
(introduced in r197805) was predicated on silently falling back to textual
inclusion, which we no longer do.

The changes to test/Modules/Inputs/macro-reexport/module.modulemap
are just an overlooked missing header that seems to have been missing since
this code was committed (r213922), which is now caught.

Reviewers: rsmith, benlangmuir, djasper

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D10423

Added:
cfe/trunk/test/Modules/Inputs/auto-import-unavailable/
cfe/trunk/test/Modules/Inputs/auto-import-unavailable/missing_header/

cfe/trunk/test/Modules/Inputs/auto-import-unavailable/missing_header/not_missing.h
cfe/trunk/test/Modules/Inputs/auto-import-unavailable/missing_requirement.h
cfe/trunk/test/Modules/Inputs/auto-import-unavailable/module.modulemap

cfe/trunk/test/Modules/Inputs/auto-import-unavailable/nonrequired_missing_header/

cfe/trunk/test/Modules/Inputs/auto-import-unavailable/nonrequired_missing_header/not_missing.h

cfe/trunk/test/Modules/Inputs/auto-import-unavailable/nonrequired_missing_header/requires_feature_you_dont_have.h
cfe/trunk/test/Modules/Inputs/available-is-better/
cfe/trunk/test/Modules/Inputs/available-is-better/available-is-better.h
cfe/trunk/test/Modules/Inputs/available-is-better/module.modulemap
cfe/trunk/test/Modules/auto-import-unavailable.cpp
cfe/trunk/test/Modules/available-is-better.cpp
Modified:
cfe/trunk/include/clang/Basic/DiagnosticCommonKinds.td
cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td
cfe/trunk/lib/Lex/ModuleMap.cpp
cfe/trunk/lib/Lex/PPDirectives.cpp
cfe/trunk/test/Modules/Inputs/declare-use/module.map
cfe/trunk/test/Modules/Inputs/macro-reexport/module.modulemap

Modified: cfe/trunk/include/clang/Basic/DiagnosticCommonKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticCommonKinds.td?rev=245228&r1=245227&r2=245228&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticCommonKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticCommonKinds.td Mon Aug 17 11:39:30 
2015
@@ -84,6 +84,10 @@ def err_module_not_built : Error<"could
 def err_module_build_disabled: Error<
   "module '%0' is needed but has not been provided, and implicit use of module 
"
   "files is disabled">, DefaultFatal;
+def err_module_unavailable : Error<
+  "module '%0' %select{is incompatible with|requires}1 feature '%2'">;
+def err_module_header_missing : Error<
+  "%select{|umbrella }0header '%1' not found">;
 def err_module_lock_failure : Error<
   "could not acquire lock file for module '%0'">, DefaultFatal;
 def err_module_lock_timeout : Error<

Modified: cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td?rev=245228&r1=245227&r2=245228&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td Mon Aug 17 
11:39:30 2015
@@ -183,10 +183,6 @@ def err_no_submodule_suggest : Error<
   "no submodule named %0 in module '%1'; did you mean '%2'?">;
 def warn_missing_submodule : Warning<"missing submodule '%0'">,
   InGroup;
-def err_module_unavailable : Error<
-  "module '%0' %select{is incompatible with|requires}1 feature '%2'">;
-def err_module_header_missing : Error<
-  "%select{|umbrella }0header '%1' not found">;
 def err_module_cannot_create_includes : Error<
   "cannot create includes file for module %0: %1">;
 def warn_module_config_macro_undef : Warning<

Modified: cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td?rev=245228&r1=245227&r2=245228&view=diff
==
--

Re: [PATCH] D10423: [modules] PR20507: Avoid silent textual inclusion.

[Sean Silva via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL245228: [modules] PR20507: Avoid silent textual inclusion. 
(authored by silvas).

Changed prior to commit:
  http://reviews.llvm.org/D10423?vs=30196&id=32317#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D10423

Files:
  cfe/trunk/include/clang/Basic/DiagnosticCommonKinds.td
  cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
  cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td
  cfe/trunk/lib/Lex/ModuleMap.cpp
  cfe/trunk/lib/Lex/PPDirectives.cpp
  
cfe/trunk/test/Modules/Inputs/auto-import-unavailable/missing_header/not_missing.h
  cfe/trunk/test/Modules/Inputs/auto-import-unavailable/missing_requirement.h
  cfe/trunk/test/Modules/Inputs/auto-import-unavailable/module.modulemap
  
cfe/trunk/test/Modules/Inputs/auto-import-unavailable/nonrequired_missing_header/not_missing.h
  
cfe/trunk/test/Modules/Inputs/auto-import-unavailable/nonrequired_missing_header/requires_feature_you_dont_have.h
  cfe/trunk/test/Modules/Inputs/available-is-better/available-is-better.h
  cfe/trunk/test/Modules/Inputs/available-is-better/module.modulemap
  cfe/trunk/test/Modules/Inputs/declare-use/module.map
  cfe/trunk/test/Modules/Inputs/macro-reexport/module.modulemap
  cfe/trunk/test/Modules/auto-import-unavailable.cpp
  cfe/trunk/test/Modules/available-is-better.cpp

Index: cfe/trunk/include/clang/Basic/DiagnosticCommonKinds.td
===
--- cfe/trunk/include/clang/Basic/DiagnosticCommonKinds.td
+++ cfe/trunk/include/clang/Basic/DiagnosticCommonKinds.td
@@ -84,6 +84,10 @@
 def err_module_build_disabled: Error<
   "module '%0' is needed but has not been provided, and implicit use of module "
   "files is disabled">, DefaultFatal;
+def err_module_unavailable : Error<
+  "module '%0' %select{is incompatible with|requires}1 feature '%2'">;
+def err_module_header_missing : Error<
+  "%select{|umbrella }0header '%1' not found">;
 def err_module_lock_failure : Error<
   "could not acquire lock file for module '%0'">, DefaultFatal;
 def err_module_lock_timeout : Error<
Index: cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td
===
--- cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td
+++ cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td
@@ -623,6 +623,8 @@
 def warn_auto_module_import : Warning<
   "treating #%select{include|import|include_next|__include_macros}0 as an "
   "import of module '%1'">, InGroup, DefaultIgnore;
+def note_implicit_top_level_module_import_here : Note<
+  "submodule of top-level module '%0' implicitly imported here">;
 def warn_uncovered_module_header : Warning<
   "umbrella header for module '%0' does not include header '%1'">, 
   InGroup;
Index: cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
===
--- cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
+++ cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
@@ -183,10 +183,6 @@
   "no submodule named %0 in module '%1'; did you mean '%2'?">;
 def warn_missing_submodule : Warning<"missing submodule '%0'">,
   InGroup;
-def err_module_unavailable : Error<
-  "module '%0' %select{is incompatible with|requires}1 feature '%2'">;
-def err_module_header_missing : Error<
-  "%select{|umbrella }0header '%1' not found">;
 def err_module_cannot_create_includes : Error<
   "cannot create includes file for module %0: %1">;
 def warn_module_config_macro_undef : Warning<
Index: cfe/trunk/test/Modules/available-is-better.cpp
===
--- cfe/trunk/test/Modules/available-is-better.cpp
+++ cfe/trunk/test/Modules/available-is-better.cpp
@@ -0,0 +1,5 @@
+// RUN: rm -rf %t
+// RUN: %clang_cc1 -x c++ -Rmodule-build -fmodules -fimplicit-module-maps -fmodules-cache-path=%t -I %S/Inputs/available-is-better %s 2>&1 | FileCheck %s
+
+#include "available-is-better.h"
+// CHECK: remark: building module
Index: cfe/trunk/test/Modules/Inputs/auto-import-unavailable/nonrequired_missing_header/not_missing.h
===
--- cfe/trunk/test/Modules/Inputs/auto-import-unavailable/nonrequired_missing_header/not_missing.h
+++ cfe/trunk/test/Modules/Inputs/auto-import-unavailable/nonrequired_missing_header/not_missing.h
@@ -0,0 +1 @@
+// nonrequired_missing_header/not_missing.h
Index: cfe/trunk/test/Modules/Inputs/auto-import-unavailable/nonrequired_missing_header/requires_feature_you_dont_have.h
===
--- cfe/trunk/test/Modules/Inputs/auto-import-unavailable/nonrequired_missing_header/requires_feature_you_dont_have.h
+++ cfe/trunk/test/Modules/Inputs/auto-import-unavailable/nonrequired_missing_header/requires_feature_you_dont_have.h
@@ -0,0 +1 @@
+// nonrequired_missing_header/requires_feature_you_dont_have.h
I

Re: [PATCH] D11844: [Modules] More descriptive diagnostics for misplaced import directive

[Sean Silva via cfe-commits]

On Wed, Aug 12, 2015 at 6:05 PM, Richard Smith 
wrote:

> On Wed, Aug 12, 2015 at 6:00 PM, Sean Silva  wrote:
>
>>
>>
>> On Wed, Aug 12, 2015 at 2:43 PM, Richard Smith 
>> wrote:
>>
>>> On Wed, Aug 12, 2015 at 12:08 AM, Sean Silva 
>>> wrote:
>>>
 silvas added a subscriber: silvas.

 
 Comment at: lib/Parse/Parser.cpp:2003
 @@ +2002,3 @@
 +Diag(Tok, diag::err_unexpected_module_start);
 +// Recover by skipping content of the included submodule.
 +unsigned ModuleNesting = 1;
 
 rsmith wrote:
 > This is liable to produce bad follow-on diagnostics; I don't think
 this is a reasonable way to recover. I can see a few feasible options here:
 >
 > 1) Emit a fatal error when this happens (suppressing further
 diagnostics)
 > 2) Break out to the top level of parsing and resume from there (that
 is, assume that a modular header expects to be included at the top level
 and that the user didn't screw up their module map)
 > 3) Enter the module and carry on parsing from here
 >
 > My preference would be either (1) or (2). But either way, we should
 diagnose the still-open bracketing constructs, because the problem is
 likely to be a missing close brace at the end of an unrelated header file.
 I strongly prefer (1). In all cases I have recorded in my notes when
 modularizing, the `error: expected '}'` diagnostic indicated one of two
 things:
 - that a header needed to be marked textual in the module map.
 - that a #include had to be moved to the top of the file (this case was
 likely behaving unexpectedly in the non-modules case and "happened to
 work").
 For the sake of our users, it is probably best to immediately fatal
 error and suggest an alternative (the suggestions can be a separate patch;
 my recommendations are below).

 I believe a user is most likely to run into this diagnostic when
 developing an initial set of module maps, so our diagnostic should be
 tailored to that audience.
>>>
>>>
>>> I think your observations may be biased by your current experiences
>>> modularizing existing code, and not representative of the complete
>>> development cycle. Modularization is a one-time effort; maintaining the
>>> code after modularization is a continuous process. I think it's *far* more
>>> likely that a header listed in your module map was expected to be modular,
>>> and that a brace mismatch within that file is unintentional and due to a
>>> missing brace somewhere.
>>>
>>
>> I don't think so. That implies that the inclusion is not at the top of
>> the file, which is extremely unlikely in a modular codebase.
>>
>
> This also happens when there's a missing brace at the end of your modular
> header, which is almost certainly the most common way to hit this problem
> in an already-modularized codebase.
>

I think that handling the missing brace at end of module differently should
be doable without disturbing the notes that Serge already has here.


> And it happens in codebases that use a mixture of modular and non-modular
> headers, where there's no reason to expect all the modular includes are
> before the non-modular ones.
>

We could check that the opening brace was in the file containing the import
to avoid misdiagnosing a missing brace in a textual header.

Richard, are these cases that you want Serge to deal with in the present
patch?

-- Sean Silva


>
>
>> 125993 #include lines.
>>
>>
>>>
>>> However, we should aim to provide diagnostics that are helpful for
>>> either case.
>>>
>>> These users may have little experience with modules when they encounter
 this diagnostic, so a notes suggesting a likely remedy helps them develop
 confidence by providing authoritative advice (and avoiding a round trip to
 the documentation).

 My fine-grained recommendations from experience are:
 - #include inside extern "C": always meant to be modular, always the
 fix is to move it out of the braced block.
 - #include inside namespace: always meant to be modular, always the fix
 is to move it out of the braced block.
 - #include inside class: always textual (e.g. bringing in methods like
 TableGen .inc files; sometimes similar ".inc" files are manually written
 and not autogenerated. I have observed e.g. "classfoo_methods.h" files;
 another instance of this is stamping out ".def" files)
 - #include inside array initializer: always textual. Typically ".def"
 files
 - #include inside function: always textual. Typically ".def" files
 (e.g. generate a switch)

 ".inl" files are theoretically a problem inside namespaces, but I have
 not observed this issue in practice. In my experience code taking the
 effort to have ".inl" files is quite clean and avoids such textual
 dependencies. The issues I have seen in practice with ".inl" files usually
 end up com

Re: [PATCH] D11944: Nativize filename in FileManager::getFile().

[Sean Silva via cfe-commits]

On Thu, Aug 13, 2015 at 10:50 AM, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> rsmith added a comment.
>
> I would think most Windows users would be surprised if we showed them
> paths with /s instead of \s, but I'm fine with us using / internally if it
> doesn't leak out to the user.
>

I think it makes sense to have a "canonical" form internally, similar to
how all our filesystem API's ensure that internally all of clang's buffers
are UTF-8.

-- Sean Silva


>
> klimek: if we want to nativize, I think the right thing to do is to remove
> the wrong "normalization" of non-Windows paths from
> `llvm::sys::path::native`, and add a more efficient overload to
> `llvm::sys::path::native`, such as `StringRef native(StringRef Input,
> SmallVectorImpl &Buffer)`.
>
>
> http://reviews.llvm.org/D11944
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D12129: [libcxx] Add new Sphinx documentation

[Sean Silva via cfe-commits]

silvas added a subscriber: silvas.
silvas added a comment.

From a Sphinx perspective, this looks fine to me. You may want to consider 
using `html_theme = 'haiku'` for consistency with clang, but reusing LLVM's is 
fine. (the reason I had clang use 'haiku' is that it is a bit better put 
together since it ships with sphinx (llvm's theme also has a notorious problem 
distinguishing different header levels); 'haiku' also doesn't require any 
static theme-related assets to be checked in since sphinx has them already as 
part of its own installation)


http://reviews.llvm.org/D12129



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D12129: [libcxx] Add new Sphinx documentation

[Sean Silva via cfe-commits]

silvas added inline comments.


Comment at: docs/BuildingLibcxx.rst:57
@@ +56,3 @@
+  select a safe place to install libc++.
+
+  * ``make install-libcxx install-libcxxabi`` --- Will install the libraries 
and the headers

jroelofs wrote:
> I feel like a warning is not enough... perhaps a hard error, with a message 
> that says something like: "If you're really really sure you know what you're 
> doing, add -DLIBCXX_OVERRIDE_DARWIN_INSTALL=YES to silence this message"?
FYI, Sphinx has some directives designed for prominent warnings like this: 
http://docutils.sourceforge.net/docs/ref/rst/directives.html#danger

Should render similar to the "Warning" box on 
http://clang.llvm.org/docs/ReleaseNotes.html (see clang/docs/ReleaseNotes.rst)


http://reviews.llvm.org/D12129



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D12129: [libcxx] Add new Sphinx documentation

[Sean Silva via cfe-commits]

silvas added inline comments.


Comment at: docs/BuildingLibcxx.rst:57
@@ +56,3 @@
+  select a safe place to install libc++.
+
+  * ``make install-libcxx install-libcxxabi`` --- Will install the libraries 
and the headers

silvas wrote:
> jroelofs wrote:
> > I feel like a warning is not enough... perhaps a hard error, with a message 
> > that says something like: "If you're really really sure you know what 
> > you're doing, add -DLIBCXX_OVERRIDE_DARWIN_INSTALL=YES to silence this 
> > message"?
> FYI, Sphinx has some directives designed for prominent warnings like this: 
> http://docutils.sourceforge.net/docs/ref/rst/directives.html#danger
> 
> Should render similar to the "Warning" box on 
> http://clang.llvm.org/docs/ReleaseNotes.html (see clang/docs/ReleaseNotes.rst)
The general names for these things are "admonitions" and there are e.g. 'note' 
'danger' 'warning' etc. that are hopefully appropriately styled by the theme.


http://reviews.llvm.org/D12129



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D11844: [Modules] More descriptive diagnostics for misplaced import directive

[Sean Silva via cfe-commits]

silvas added inline comments.


Comment at: test/Modules/auto-module-import.m:89
@@ +88,3 @@
+  expected-error {{import of module 'NoUmbrella.A' 
appears within function 'includeNotAtTopLevel'}} \
+  expected-note {{consider marking the module as 
textual}}
+}

I think what this means is marking the *header* as textual. So I would suggest 
the wording "consider marking the header as textual".


http://reviews.llvm.org/D11844



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r245821 - [modules] Stop updating all identifiers when writing a module. This is

[Sean Silva via cfe-commits]

On Sun, Aug 23, 2015 at 8:33 PM, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rsmith
> Date: Sun Aug 23 22:33:22 2015
> New Revision: 245821
>
> URL: http://llvm.org/viewvc/llvm-project?rev=245821&view=rev
> Log:
> [modules] Stop updating all identifiers when writing a module. This is
> unnecessary in C++ modules (where we don't need the identifiers for their
> Decls) and expensive.
>

Why specifically C++ modules?

-- Sean Silva


>
> Modified:
> cfe/trunk/lib/Serialization/ASTReader.cpp
> cfe/trunk/lib/Serialization/ASTReaderInternals.h
> cfe/trunk/lib/Serialization/ASTWriter.cpp
> cfe/trunk/test/Modules/macros.c
>
> Modified: cfe/trunk/lib/Serialization/ASTReader.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Serialization/ASTReader.cpp?rev=245821&r1=245820&r2=245821&view=diff
>
> ==
> --- cfe/trunk/lib/Serialization/ASTReader.cpp (original)
> +++ cfe/trunk/lib/Serialization/ASTReader.cpp Sun Aug 23 22:33:22 2015
> @@ -755,6 +755,12 @@ static bool readBit(unsigned &Bits) {
>return Value;
>  }
>
> +IdentID ASTIdentifierLookupTrait::ReadIdentifierID(const unsigned char
> *d) {
> +  using namespace llvm::support;
> +  unsigned RawID = endian::readNext(d);
> +  return Reader.getGlobalIdentifierID(F, RawID >> 1);
> +}
> +
>  IdentifierInfo *ASTIdentifierLookupTrait::ReadData(const
> internal_key_type& k,
> const unsigned char* d,
> unsigned DataLen) {
> @@ -3455,7 +3461,20 @@ ASTReader::ASTReadResult ASTReader::Read
>ASTIdentifierLookupTrait Trait(*this, F);
>auto KeyDataLen = Trait.ReadKeyDataLength(Data);
>auto Key = Trait.ReadKey(Data, KeyDataLen.first);
> -  PP.getIdentifierTable().getOwn(Key).setOutOfDate(true);
> +  auto &II = PP.getIdentifierTable().getOwn(Key);
> +  II.setOutOfDate(true);
> +
> +  // Mark this identifier as being from an AST file so that we can
> track
> +  // whether we need to serialize it.
> +  if (!II.isFromAST()) {
> +II.setIsFromAST();
> +if (isInterestingIdentifier(*this, II, F.isModule()))
> +  II.setChangedSinceDeserialization();
> +  }
> +
> +  // Associate the ID with the identifier so that the writer can
> reuse it.
> +  auto ID = Trait.ReadIdentifierID(Data + KeyDataLen.first);
> +  SetIdentifierInfo(ID, &II);
>  }
>}
>
>
> Modified: cfe/trunk/lib/Serialization/ASTReaderInternals.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Serialization/ASTReaderInternals.h?rev=245821&r1=245820&r2=245821&view=diff
>
> ==
> --- cfe/trunk/lib/Serialization/ASTReaderInternals.h (original)
> +++ cfe/trunk/lib/Serialization/ASTReaderInternals.h Sun Aug 23 22:33:22
> 2015
> @@ -137,6 +137,8 @@ public:
>   const unsigned char* d,
>   unsigned DataLen);
>
> +  IdentID ReadIdentifierID(const unsigned char *d);
> +
>ASTReader &getReader() const { return Reader; }
>  };
>
>
> Modified: cfe/trunk/lib/Serialization/ASTWriter.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Serialization/ASTWriter.cpp?rev=245821&r1=245820&r2=245821&view=diff
>
> ==
> --- cfe/trunk/lib/Serialization/ASTWriter.cpp (original)
> +++ cfe/trunk/lib/Serialization/ASTWriter.cpp Sun Aug 23 22:33:22 2015
> @@ -4273,22 +4273,24 @@ void ASTWriter::WriteASTCore(Sema &SemaR
>}
>
>// Make sure all decls associated with an identifier are registered for
> -  // serialization.
> -  llvm::SmallVector IIs;
> -  for (IdentifierTable::iterator ID = PP.getIdentifierTable().begin(),
> -  IDEnd = PP.getIdentifierTable().end();
> -   ID != IDEnd; ++ID) {
> -const IdentifierInfo *II = ID->second;
> -if (!Chain || !II->isFromAST() ||
> II->hasChangedSinceDeserialization())
> -  IIs.push_back(II);
> -  }
> -  // Sort the identifiers to visit based on their name.
> -  std::sort(IIs.begin(), IIs.end(), llvm::less_ptr());
> -  for (const IdentifierInfo *II : IIs) {
> -for (IdentifierResolver::iterator D = SemaRef.IdResolver.begin(II),
> -   DEnd = SemaRef.IdResolver.end();
> - D != DEnd; ++D) {
> -  GetDeclRef(*D);
> +  // serialization, if we're storing decls with identifiers.
> +  if (!WritingModule || !getLangOpts().CPlusPlus) {
> +llvm::SmallVector IIs;
> +for (IdentifierTable::iterator ID = PP.getIdentifierTable().begin(),
> +IDEnd = PP.getIdentifierTable().end();
> + ID != IDEnd; ++ID) {
> +  const IdentifierInfo *II = ID->second;
> +  if (!Chain || !II->isFromAST() ||
> II->hasChangedSinceDeserialization())
> +IIs.push_b

Re: [PATCH] D12271: [X86] Expose the various _rot intrinsics on non-MS platforms

[Sean Silva via cfe-commits]

silvas added a subscriber: silvas.
silvas added a comment.

In http://reviews.llvm.org/D12271#231204, @rnk wrote:

> This looks good.
>
> As a larger issue, LLVM fast isel definitely won't pattern match this series 
> of shifts and selects to rotl at -O0. There are some users who want 
> branchless constant time rotates regardless of optimization level 
> (https://llvm.org/bugs/show_bug.cgi?id=24226). My thinking is that the shifts 
> are more analyzable to LLVM than an intrinsic, so we should leave these 
> intrinsics alone and tell such users to use inline asm if they need these 
> kinds of low-level guarantees. It still isn't very satisfactory. =/


I don't remember anything in PR24226 about "regardless of optimization level". 
In particular, code with "constant time" requirements won't tolerate -O0 
codegen anyway because of the large amount of memory accesses into the stack -- 
the timing of such operations will depend on nasty things like cache line 
aliasing and such, which has similar problems to branches.


http://reviews.llvm.org/D12271



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D11844: [Modules] More descriptive diagnostics for misplaced import directive

[Sean Silva via cfe-commits]

silvas added a comment.

ping?


http://reviews.llvm.org/D11844



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r246702 - [modules] Tighten up this test a bit.

[Sean Silva via cfe-commits]

Author: silvas
Date: Wed Sep  2 15:16:09 2015
New Revision: 246702

URL: http://llvm.org/viewvc/llvm-project?rev=246702&view=rev
Log:
[modules] Tighten up this test a bit.

Modified:
cfe/trunk/test/Modules/module-map-path-hash.cpp

Modified: cfe/trunk/test/Modules/module-map-path-hash.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/module-map-path-hash.cpp?rev=246702&r1=246701&r2=246702&view=diff
==
--- cfe/trunk/test/Modules/module-map-path-hash.cpp (original)
+++ cfe/trunk/test/Modules/module-map-path-hash.cpp Wed Sep  2 15:16:09 2015
@@ -1,9 +1,10 @@
 // RUN: rm -rf %t
-// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -x c++ -Rmodule-build 
-I%S/Inputs/module-map-path-hash -fmodules-cache-path=%t -fsyntax-only %s
-// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -x c++ -Rmodule-build 
-I%S/Inputs//module-map-path-hash -fmodules-cache-path=%t -fsyntax-only %s 2>&1 
| FileCheck -allow-empty %s
-// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -x c++ -Rmodule-build 
-I%S/Inputs/./module-map-path-hash -fmodules-cache-path=%t -fsyntax-only %s 
2>&1 | FileCheck -allow-empty %s
-// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -x c++ -Rmodule-build 
-I%S/Inputs/../Inputs/module-map-path-hash -fmodules-cache-path=%t 
-fsyntax-only %s 2>&1 | FileCheck -allow-empty %s
+// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -x c++ -Rmodule-build 
-I%S/Inputs/module-map-path-hash -fmodules-cache-path=%t -fsyntax-only %s 2>&1 
| FileCheck %s --check-prefix=BUILD
+// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -x c++ -Rmodule-build 
-I%S/Inputs//module-map-path-hash -fmodules-cache-path=%t -fsyntax-only %s 2>&1 
| FileCheck -allow-empty %s --check-prefix=NOBUILD
+// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -x c++ -Rmodule-build 
-I%S/Inputs/./module-map-path-hash -fmodules-cache-path=%t -fsyntax-only %s 
2>&1 | FileCheck -allow-empty %s --check-prefix=NOBUILD
+// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -x c++ -Rmodule-build 
-I%S/Inputs/../Inputs/module-map-path-hash -fmodules-cache-path=%t 
-fsyntax-only %s 2>&1 | FileCheck -allow-empty %s --check-prefix=NOBUILD
 
 #include "a.h"
 
-// CHECK-NOT: remark: building module
+// BUILD: remark: building module
+// NOBUILD-NOT: remark: building module


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D12326: [Modules] Emit warning if module cannot instantiate static class member.

[Sean Silva via cfe-commits]

silvas added a subscriber: silvas.
silvas added a comment.

How expensive is this check?


http://reviews.llvm.org/D12326



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r250252 - This patch adds missing pieces to clang, including the PS4 toolchain

[Sean Silva via cfe-commits]

Looks like this doesn't even compile:
http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/32311/steps/compile/logs/stdio

Can you revert?

On Tue, Oct 13, 2015 at 4:40 PM, Ekaterina Romanova via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: kromanova
> Date: Tue Oct 13 18:40:02 2015
> New Revision: 250252
>
> URL: http://llvm.org/viewvc/llvm-project?rev=250252&view=rev
> Log:
> This patch adds missing pieces to clang, including the PS4 toolchain
> definition, added warnings, PS4 defaults, and Driver changes needed for
> our compiler.
>
> A patch by Filipe Cabecinhas, Pierre Gousseau and Katya Romanova!
>
> Differential Revision: http://reviews.llvm.org/D13482
>
>
> Added:
> cfe/trunk/test/Driver/Inputs/scei-ps4_tree/target/include/.keep
> cfe/trunk/test/Driver/Inputs/scei-ps4_tree/target/include_common/.keep
> cfe/trunk/test/Driver/no-integrated-as.s
> cfe/trunk/test/Driver/ps4-header-search.c
> cfe/trunk/test/Driver/ps4-linker-non-win.c
> cfe/trunk/test/Driver/ps4-linker-win.c
> cfe/trunk/test/Driver/ps4-pic.c
> cfe/trunk/test/Driver/ps4-sdk-root.c
> Modified:
> cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
> cfe/trunk/include/clang/Basic/DiagnosticGroups.td
> cfe/trunk/lib/Driver/Driver.cpp
> cfe/trunk/lib/Driver/ToolChains.cpp
> cfe/trunk/lib/Driver/ToolChains.h
> cfe/trunk/lib/Driver/Tools.cpp
> cfe/trunk/lib/Driver/Tools.h
> cfe/trunk/lib/Frontend/InitHeaderSearch.cpp
> cfe/trunk/test/Driver/debug-options.c
> cfe/trunk/test/Driver/stack-protector.c
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td?rev=250252&r1=250251&r2=250252&view=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td Tue Oct 13
> 18:40:02 2015
> @@ -196,4 +196,18 @@ def warn_target_unsupported_nan2008 : Wa
>  def warn_target_unsupported_nanlegacy : Warning<
>"ignoring '-mnan=legacy' option because the '%0' architecture does not
> support it">,
>InGroup;
> +
> +def warn_drv_unable_to_find_directory_expected : Warning<
> +  "unable to find %0 directory, expected to be in '%1'">,
> +  InGroup, DefaultIgnore;
> +
> +def warn_drv_ps4_force_pic : Warning<
> +  "option '%0' was ignored by the PS4 toolchain, using '-fPIC'">,
> +  InGroup;
> +
> +def warn_drv_ps4_sdk_dir : Warning<
> +  "environment variable SCE_PS4_SDK_DIR is set, but points to invalid or
> nonexistent directory '%0'">,
> +  InGroup;
> +
> +def err_drv_unsupported_linker : Error<"unsupported value '%0' for
> -linker option">;
>  }
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticGroups.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticGroups.td?rev=250252&r1=250251&r2=250252&view=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticGroups.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticGroups.td Tue Oct 13 18:40:02
> 2015
> @@ -823,3 +823,7 @@ def CudaCompat : DiagGroup<"cuda-compat"
>
>  // A warning group for things that will change semantics in the future.
>  def FutureCompat : DiagGroup<"future-compat">;
> +
> +def InvalidOrNonExistentDirectory :
> DiagGroup<"invalid-or-nonexistent-directory">;
> +
> +def OptionIgnored : DiagGroup<"option-ignored">;
>
> Modified: cfe/trunk/lib/Driver/Driver.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Driver.cpp?rev=250252&r1=250251&r2=250252&view=diff
>
> ==
> --- cfe/trunk/lib/Driver/Driver.cpp (original)
> +++ cfe/trunk/lib/Driver/Driver.cpp Tue Oct 13 18:40:02 2015
> @@ -2261,6 +2261,9 @@ const ToolChain &Driver::getToolChain(co
>  case llvm::Triple::CUDA:
>TC = new toolchains::CudaToolChain(*this, Target, Args);
>break;
> +case llvm::Triple::PS4:
> +  TC = new toolchains::PS4CPU(*this, Target, Args);
> +  break;
>  default:
>// Of these targets, Hexagon is the only one that might have
>// an OS of Linux, in which case it got handled above already.
>
> Modified: cfe/trunk/lib/Driver/ToolChains.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains.cpp?rev=250252&r1=250251&r2=250252&view=diff
>
> ==
> --- cfe/trunk/lib/Driver/ToolChains.cpp (original)
> +++ cfe/trunk/lib/Driver/ToolChains.cpp Tue Oct 13 18:40:02 2015
> @@ -4066,3 +4066,77 @@ void WebAssembly::addClangTargetOptions(
>   options::OPT_fno_use_init_array, true))
>  CC1Args.push_back("-fuse-init-array");
>  }
> +
> +PS4CPU::PS4CPU(const Driver &D, const llvm::Triple

Re: [libcxx] r249738 - Split out of .

[Sean Silva via cfe-commits]

On Tue, Oct 13, 2015 at 3:17 PM, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On Tue, Oct 13, 2015 at 2:10 PM, Adrian Prantl via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Hi Richard,
>>
>> this commit appears to break the module self-host on Darwin.
>>
>> When compiling the following program generated by clang’s own cmake
>> script:
>>
>> > #undef NDEBUG
>> > #include 
>> > #define NDEBUG
>> > #include 
>> > int main() { assert(this code is not compiled); }
>>
>> with clang++ -std=c++11 -fmodules -fcxx-modules test.cpp
>>
>
> (You don't need -fcxx-modules here.)
>
>
>> I get
>>
>> > While building module 'std' imported from /Users/buildslave/adrian/
>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:
>> > While building module 'Darwin' imported from /Users/buildslave/adrian/
>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39:
>> > In file included from :98:
>> > In file included from
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/wchar.h:92:
>> > In file included from
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/_wctype.h:57:
>
> > /Users/buildslave/adrian/
>> llvm.org/_build.ninja.release/bin/../include/c++/v1/ctype.h:33:10: fatal
>> error: cyclic dependency in module 'std': std -> Darwin -> std
>> > #include <__config>
>> >  ^
>> > While building module 'std' imported from /Users/buildslave/adrian/
>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:
>> > In file included from :1:
>> > In file included from /Users/buildslave/adrian/
>> llvm.org/_build.ninja.release/bin/../include/c++/v1/algorithm:624:
>> > In file included from /Users/buildslave/adrian/
>> llvm.org/_build.ninja.release/bin/../include/c++/v1/initializer_list:47:
>> > /Users/buildslave/adrian/
>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39:10: fatal
>> error: could not build module 'Darwin'
>> > #include 
>> >  ^
>> > In file included from test.cpp:2:
>> > /Users/buildslave/adrian/
>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:10: fatal
>> error: could not build module 'std'
>> > #include <__config>
>> >  ^
>> > 3 errors generated.
>>
>> Let me know how I can help in diagnosing what’s going on here.
>>
>
> OK, I see what's wrong. Is this working any better for you in r250236?
>

We're still seeing:

While building module 'Darwin' imported from /usr/include/assert.h:42:
While building module 'std' imported from
/path/to/build_cmake/stage1/bin/../include/c++/v1/math.h:309:
In file included from :1:
In file included from
/path/to/build_cmake/stage1/bin/../include/c++/v1/algorithm:624:
In file included from
/path/to/build_cmake/stage1/bin/../include/c++/v1/initializer_list:47:
In file included from
/path/to/build_cmake/stage1/bin/../include/c++/v1/cstddef:43:
/path/to/build_cmake/stage1/bin/../include/c++/v1/stddef.h:46:15: fatal
error: cyclic dependency in module 'Darwin': Darwin -> std -> Darwin
#include_next 
  ^
While building module 'Darwin' imported from /usr/include/assert.h:42:
In file included from :80:
In file included from
/path/to/build_cmake/stage1/bin/../lib/clang/3.8.0/include/tgmath.h:29:
/path/to/build_cmake/stage1/bin/../include/c++/v1/math.h:309:10: fatal
error: could not build module 'std'
#include 
 ^
In file included from modules.cpp:2:
In file included from
/path/to/build_cmake/stage1/bin/../include/c++/v1/cassert:21:
/usr/include/assert.h:42:10: fatal error: could not build module 'Darwin'
#include 
 ^
3 errors generated.


Looks like the system headers are being interposed.

-- Sean Silva


>
>
>> Once this works, I’d like to to set up a green dragon bot that builds
>> clang with LLVM_ENABLE_MODULES to catch similar problems earlier.
>>
>> -- adrian
>>
>> > On Oct 8, 2015, at 1:36 PM, Richard Smith via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>> >
>> > Author: rsmith
>> > Date: Thu Oct  8 15:36:30 2015
>> > New Revision: 249738
>> >
>> > URL: http://llvm.org/viewvc/llvm-project?rev=249738&view=rev
>> > Log:
>> > Split  out of .
>> >
>> > Added:
>> >libcxx/trunk/include/ctype.h
>> >  - copied, changed from r249736, libcxx/trunk/include/cctype
>> > Modified:
>> >libcxx/trunk/include/cctype
>> >libcxx/trunk/test/std/strings/c.strings/cctype.pass.cpp
>> >
>> > Modified: libcxx/trunk/include/cctype
>> > URL:
>> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/cctype?rev=249738&r1=249737&r2=249738&view=diff
>> >
>> ==
>> > --- libcxx/trunk/include/cctype (original)
>> > +++ libcxx/trunk/include/cctype Thu Oct  8 15:36:30 2015
>> > @@ -37,10 +37,6 @@ int toupper(int c);
>> >
>> > #include <__config>
>> > #include 
>> > -#if defined(_LIBCPP_MSVCRT)
>> > -#include "support/win32/support.h"
>> > -#include "support

Re: [libcxx] r249738 - Split out of .

[Sean Silva via cfe-commits]

On Tue, Oct 13, 2015 at 6:14 PM, Richard Smith 
wrote:

> On Tue, Oct 13, 2015 at 5:31 PM, Sean Silva  wrote:
>
>> On Tue, Oct 13, 2015 at 3:17 PM, Richard Smith via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> On Tue, Oct 13, 2015 at 2:10 PM, Adrian Prantl via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 Hi Richard,

 this commit appears to break the module self-host on Darwin.

 When compiling the following program generated by clang’s own cmake
 script:

 > #undef NDEBUG
 > #include 
 > #define NDEBUG
 > #include 
 > int main() { assert(this code is not compiled); }

 with clang++ -std=c++11 -fmodules -fcxx-modules test.cpp

>>>
>>> (You don't need -fcxx-modules here.)
>>>
>>>
 I get

 > While building module 'std' imported from /Users/buildslave/adrian/
 llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:
 > While building module 'Darwin' imported from /Users/buildslave/adrian/
 llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39:
 > In file included from :98:
 > In file included from
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/wchar.h:92:
 > In file included from
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/_wctype.h:57:
>>>
>>> > /Users/buildslave/adrian/
 llvm.org/_build.ninja.release/bin/../include/c++/v1/ctype.h:33:10:
 fatal error: cyclic dependency in module 'std': std -> Darwin -> std
 > #include <__config>
 >  ^
 > While building module 'std' imported from /Users/buildslave/adrian/
 llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:
 > In file included from :1:
 > In file included from /Users/buildslave/adrian/
 llvm.org/_build.ninja.release/bin/../include/c++/v1/algorithm:624:
 > In file included from /Users/buildslave/adrian/
 llvm.org/_build.ninja.release/bin/../include/c++/v1/initializer_list:47
 :
 > /Users/buildslave/adrian/
 llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39:10:
 fatal error: could not build module 'Darwin'
 > #include 
 >  ^
 > In file included from test.cpp:2:
 > /Users/buildslave/adrian/
 llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:10:
 fatal error: could not build module 'std'
 > #include <__config>
 >  ^
 > 3 errors generated.

 Let me know how I can help in diagnosing what’s going on here.

>>>
>>> OK, I see what's wrong. Is this working any better for you in r250236?
>>>
>>
>> We're still seeing:
>>
>> While building module 'Darwin' imported from /usr/include/assert.h:42:
>> While building module 'std' imported from
>> /path/to/build_cmake/stage1/bin/../include/c++/v1/math.h:309:
>>
>
> Argh, this is including , which is in the std module. Can you
> try removing the header "type_traits" line from the libc++ module map and
> see if that helps?
>

I've run into this issue in the past, and I don't think that will fix it
(see below). Just to be sure, here is the output with type_traits removed
from the module map::

While building module 'Darwin' imported from /usr/include/assert.h:42:
While building module 'std' imported from
/path/to/build_cmake/stage1/bin/../include/c++/v1/type_traits:211:
In file included from :1:
In file included from
/path/to/build_cmake/stage1/bin/../include/c++/v1/algorithm:624:
In file included from
/path/to/build_cmake/stage1/bin/../include/c++/v1/initializer_list:47:
In file included from
/path/to/build_cmake/stage1/bin/../include/c++/v1/cstddef:43:
/path/to/build_cmake/stage1/bin/../include/c++/v1/stddef.h:46:15: fatal
error: cyclic dependency in module 'Darwin': Darwin -> std -> Darwin
#include_next 
  ^
While building module 'Darwin' imported from /usr/include/assert.h:42:
In file included from :80:
In file included from
/path/to/build_cmake/stage1/bin/../lib/clang/3.8.0/include/tgmath.h:29:
In file included from
/path/to/build_cmake/stage1/bin/../include/c++/v1/math.h:309:
/path/to/build_cmake/stage1/bin/../include/c++/v1/type_traits:211:10: fatal
error: could not build module 'std'
#include 
 ^
In file included from modules.cpp:2:
In file included from
/path/to/build_cmake/stage1/bin/../include/c++/v1/cassert:21:
/usr/include/assert.h:42:10: fatal error: could not build module 'Darwin'
#include 
 ^
3 errors generated.



> What we really need here is a way to get the Darwin blah.h headers to only
> include each other, and not find the libc++ headers. Do you need something
> that works with new libc++ and old Clang, or would a Clang feature to
> prevent the Darwin module from finding the std module's headers work for
> you?
>

I've run into this issue in the wild with the modularized PS4 SDK, so I
think that a clang feature that prevents this is the 

Re: [libcxx] r249738 - Split out of .

[Sean Silva via cfe-commits]

On Tue, Oct 13, 2015 at 6:54 PM, Sean Silva  wrote:

>
>
> On Tue, Oct 13, 2015 at 6:14 PM, Richard Smith 
> wrote:
>
>> On Tue, Oct 13, 2015 at 5:31 PM, Sean Silva 
>> wrote:
>>
>>> On Tue, Oct 13, 2015 at 3:17 PM, Richard Smith via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 On Tue, Oct 13, 2015 at 2:10 PM, Adrian Prantl via cfe-commits <
 cfe-commits@lists.llvm.org> wrote:

> Hi Richard,
>
> this commit appears to break the module self-host on Darwin.
>
> When compiling the following program generated by clang’s own cmake
> script:
>
> > #undef NDEBUG
> > #include 
> > #define NDEBUG
> > #include 
> > int main() { assert(this code is not compiled); }
>
> with clang++ -std=c++11 -fmodules -fcxx-modules test.cpp
>

 (You don't need -fcxx-modules here.)


> I get
>
> > While building module 'std' imported from /Users/buildslave/adrian/
> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:
> > While building module 'Darwin' imported from
> /Users/buildslave/adrian/
> llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39:
> > In file included from :98:
> > In file included from
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/wchar.h:92:
> > In file included from
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/_wctype.h:57:

 > /Users/buildslave/adrian/
> llvm.org/_build.ninja.release/bin/../include/c++/v1/ctype.h:33:10:
> fatal error: cyclic dependency in module 'std': std -> Darwin -> std
> > #include <__config>
> >  ^
> > While building module 'std' imported from /Users/buildslave/adrian/
> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:
> > In file included from :1:
> > In file included from /Users/buildslave/adrian/
> llvm.org/_build.ninja.release/bin/../include/c++/v1/algorithm:624:
> > In file included from /Users/buildslave/adrian/
> llvm.org/_build.ninja.release/bin/../include/c++/v1/initializer_list:47
> :
> > /Users/buildslave/adrian/
> llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39:10:
> fatal error: could not build module 'Darwin'
> > #include 
> >  ^
> > In file included from test.cpp:2:
> > /Users/buildslave/adrian/
> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:10:
> fatal error: could not build module 'std'
> > #include <__config>
> >  ^
> > 3 errors generated.
>
> Let me know how I can help in diagnosing what’s going on here.
>

 OK, I see what's wrong. Is this working any better for you in r250236?

>>>
>>> We're still seeing:
>>>
>>> While building module 'Darwin' imported from /usr/include/assert.h:42:
>>> While building module 'std' imported from
>>> /path/to/build_cmake/stage1/bin/../include/c++/v1/math.h:309:
>>>
>>
>> Argh, this is including , which is in the std module. Can
>> you try removing the header "type_traits" line from the libc++ module map
>> and see if that helps?
>>
>
> I've run into this issue in the past, and I don't think that will fix it
> (see below). Just to be sure, here is the output with type_traits removed
> from the module map::
>
> While building module 'Darwin' imported from /usr/include/assert.h:42:
> While building module 'std' imported from
> /path/to/build_cmake/stage1/bin/../include/c++/v1/type_traits:211:
> In file included from :1:
> In file included from
> /path/to/build_cmake/stage1/bin/../include/c++/v1/algorithm:624:
> In file included from
> /path/to/build_cmake/stage1/bin/../include/c++/v1/initializer_list:47:
> In file included from
> /path/to/build_cmake/stage1/bin/../include/c++/v1/cstddef:43:
> /path/to/build_cmake/stage1/bin/../include/c++/v1/stddef.h:46:15: fatal
> error: cyclic dependency in module 'Darwin': Darwin -> std -> Darwin
> #include_next 
>   ^
> While building module 'Darwin' imported from /usr/include/assert.h:42:
> In file included from :80:
> In file included from
> /path/to/build_cmake/stage1/bin/../lib/clang/3.8.0/include/tgmath.h:29:
> In file included from
> /path/to/build_cmake/stage1/bin/../include/c++/v1/math.h:309:
> /path/to/build_cmake/stage1/bin/../include/c++/v1/type_traits:211:10:
> fatal error: could not build module 'std'
> #include 
>  ^
> In file included from modules.cpp:2:
> In file included from
> /path/to/build_cmake/stage1/bin/../include/c++/v1/cassert:21:
> /usr/include/assert.h:42:10: fatal error: could not build module 'Darwin'
> #include 
>  ^
> 3 errors generated.
>
>
>
>> What we really need here is a way to get the Darwin blah.h headers to
>> only include each other, and not find the libc++ headers. Do you need
>> something that works with new libc++ and old Clang, or would 

Re: [libcxx] r249738 - Split out of .

[Sean Silva via cfe-commits]

(and assert.h probably isn't the best example, since it is textual)

On Tue, Oct 13, 2015 at 7:00 PM, Sean Silva  wrote:

>
>
> On Tue, Oct 13, 2015 at 6:54 PM, Sean Silva  wrote:
>
>>
>>
>> On Tue, Oct 13, 2015 at 6:14 PM, Richard Smith 
>> wrote:
>>
>>> On Tue, Oct 13, 2015 at 5:31 PM, Sean Silva 
>>> wrote:
>>>
 On Tue, Oct 13, 2015 at 3:17 PM, Richard Smith via cfe-commits <
 cfe-commits@lists.llvm.org> wrote:

> On Tue, Oct 13, 2015 at 2:10 PM, Adrian Prantl via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Hi Richard,
>>
>> this commit appears to break the module self-host on Darwin.
>>
>> When compiling the following program generated by clang’s own cmake
>> script:
>>
>> > #undef NDEBUG
>> > #include 
>> > #define NDEBUG
>> > #include 
>> > int main() { assert(this code is not compiled); }
>>
>> with clang++ -std=c++11 -fmodules -fcxx-modules test.cpp
>>
>
> (You don't need -fcxx-modules here.)
>
>
>> I get
>>
>> > While building module 'std' imported from /Users/buildslave/adrian/
>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:
>> > While building module 'Darwin' imported from
>> /Users/buildslave/adrian/
>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39:
>> > In file included from :98:
>> > In file included from
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/wchar.h:92:
>> > In file included from
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/_wctype.h:57:
>
> > /Users/buildslave/adrian/
>> llvm.org/_build.ninja.release/bin/../include/c++/v1/ctype.h:33:10:
>> fatal error: cyclic dependency in module 'std': std -> Darwin -> std
>> > #include <__config>
>> >  ^
>> > While building module 'std' imported from /Users/buildslave/adrian/
>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:
>> > In file included from :1:
>> > In file included from /Users/buildslave/adrian/
>> llvm.org/_build.ninja.release/bin/../include/c++/v1/algorithm:624:
>> > In file included from /Users/buildslave/adrian/
>> llvm.org/_build.ninja.release/bin/../include/c++/v1/initializer_list:47
>> :
>> > /Users/buildslave/adrian/
>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39:10:
>> fatal error: could not build module 'Darwin'
>> > #include 
>> >  ^
>> > In file included from test.cpp:2:
>> > /Users/buildslave/adrian/
>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:10:
>> fatal error: could not build module 'std'
>> > #include <__config>
>> >  ^
>> > 3 errors generated.
>>
>> Let me know how I can help in diagnosing what’s going on here.
>>
>
> OK, I see what's wrong. Is this working any better for you in r250236?
>

 We're still seeing:

 While building module 'Darwin' imported from /usr/include/assert.h:42:
 While building module 'std' imported from
 /path/to/build_cmake/stage1/bin/../include/c++/v1/math.h:309:

>>>
>>> Argh, this is including , which is in the std module. Can
>>> you try removing the header "type_traits" line from the libc++ module map
>>> and see if that helps?
>>>
>>
>> I've run into this issue in the past, and I don't think that will fix it
>> (see below). Just to be sure, here is the output with type_traits removed
>> from the module map::
>>
>> While building module 'Darwin' imported from /usr/include/assert.h:42:
>> While building module 'std' imported from
>> /path/to/build_cmake/stage1/bin/../include/c++/v1/type_traits:211:
>> In file included from :1:
>> In file included from
>> /path/to/build_cmake/stage1/bin/../include/c++/v1/algorithm:624:
>> In file included from
>> /path/to/build_cmake/stage1/bin/../include/c++/v1/initializer_list:47:
>> In file included from
>> /path/to/build_cmake/stage1/bin/../include/c++/v1/cstddef:43:
>> /path/to/build_cmake/stage1/bin/../include/c++/v1/stddef.h:46:15: fatal
>> error: cyclic dependency in module 'Darwin': Darwin -> std -> Darwin
>> #include_next 
>>   ^
>> While building module 'Darwin' imported from /usr/include/assert.h:42:
>> In file included from :80:
>> In file included from
>> /path/to/build_cmake/stage1/bin/../lib/clang/3.8.0/include/tgmath.h:29:
>> In file included from
>> /path/to/build_cmake/stage1/bin/../include/c++/v1/math.h:309:
>> /path/to/build_cmake/stage1/bin/../include/c++/v1/type_traits:211:10:
>> fatal error: could not build module 'std'
>> #include 
>>  ^
>> In file included from modules.cpp:2:
>> In file included from
>> /path/to/build_cmake/stage1/bin/../include/c++/v1/cassert:21:
>> /usr/include/assert.h:42:10: fatal error: could not build module 'Darwin'
>> #include 

Re: r250262 - I took care of the build problem in the commit 250252.

[Sean Silva via cfe-commits]

This is breaking llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast:
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/1358/steps/test/logs/stdio

On Tue, Oct 13, 2015 at 6:09 PM, Ekaterina Romanova via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: kromanova
> Date: Tue Oct 13 20:09:02 2015
> New Revision: 250262
>
> URL: http://llvm.org/viewvc/llvm-project?rev=250262&view=rev
> Log:
> I took care of the build problem in the commit 250252.
> Resubmitting the patch.
>
> This patch adds missing pieces to clang, including the PS4 toolchain
> definition, added warnings, PS4 defaults, and Driver changes needed for
> our compiler.
>
> A patch by Filipe Cabecinhas, Pierre Gousseau and Katya Romanova!
>
> Differential Revision: http://reviews.llvm.org/D13482
>
>
> Added:
> cfe/trunk/test/Driver/Inputs/scei-ps4_tree/target/include/.keep
>   - copied unchanged from r250256,
> cfe/trunk/test/Driver/Inputs/scei-ps4_tree/target/include/.keep
> cfe/trunk/test/Driver/Inputs/scei-ps4_tree/target/include_common/.keep
>   - copied unchanged from r250256,
> cfe/trunk/test/Driver/Inputs/scei-ps4_tree/target/include_common/.keep
> cfe/trunk/test/Driver/no-integrated-as.s
>   - copied unchanged from r250256,
> cfe/trunk/test/Driver/no-integrated-as.s
> cfe/trunk/test/Driver/ps4-header-search.c
>   - copied unchanged from r250256,
> cfe/trunk/test/Driver/ps4-header-search.c
> cfe/trunk/test/Driver/ps4-linker-non-win.c
>   - copied unchanged from r250256,
> cfe/trunk/test/Driver/ps4-linker-non-win.c
> cfe/trunk/test/Driver/ps4-linker-win.c
>   - copied unchanged from r250256,
> cfe/trunk/test/Driver/ps4-linker-win.c
> cfe/trunk/test/Driver/ps4-pic.c
>   - copied unchanged from r250256, cfe/trunk/test/Driver/ps4-pic.c
> cfe/trunk/test/Driver/ps4-sdk-root.c
>   - copied unchanged from r250256, cfe/trunk/test/Driver/ps4-sdk-root.c
> Modified:
> cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
> cfe/trunk/include/clang/Basic/DiagnosticGroups.td
> cfe/trunk/lib/Driver/Driver.cpp
> cfe/trunk/lib/Driver/ToolChains.cpp
> cfe/trunk/lib/Driver/ToolChains.h
> cfe/trunk/lib/Driver/Tools.cpp
> cfe/trunk/lib/Driver/Tools.h
> cfe/trunk/lib/Frontend/InitHeaderSearch.cpp
> cfe/trunk/test/Driver/debug-options.c
> cfe/trunk/test/Driver/stack-protector.c
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td?rev=250262&r1=250261&r2=250262&view=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td Tue Oct 13
> 20:09:02 2015
> @@ -196,4 +196,18 @@ def warn_target_unsupported_nan2008 : Wa
>  def warn_target_unsupported_nanlegacy : Warning<
>"ignoring '-mnan=legacy' option because the '%0' architecture does not
> support it">,
>InGroup;
> +
> +def warn_drv_unable_to_find_directory_expected : Warning<
> +  "unable to find %0 directory, expected to be in '%1'">,
> +  InGroup, DefaultIgnore;
> +
> +def warn_drv_ps4_force_pic : Warning<
> +  "option '%0' was ignored by the PS4 toolchain, using '-fPIC'">,
> +  InGroup;
> +
> +def warn_drv_ps4_sdk_dir : Warning<
> +  "environment variable SCE_PS4_SDK_DIR is set, but points to invalid or
> nonexistent directory '%0'">,
> +  InGroup;
> +
> +def err_drv_unsupported_linker : Error<"unsupported value '%0' for
> -linker option">;
>  }
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticGroups.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticGroups.td?rev=250262&r1=250261&r2=250262&view=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticGroups.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticGroups.td Tue Oct 13 20:09:02
> 2015
> @@ -823,3 +823,7 @@ def CudaCompat : DiagGroup<"cuda-compat"
>
>  // A warning group for things that will change semantics in the future.
>  def FutureCompat : DiagGroup<"future-compat">;
> +
> +def InvalidOrNonExistentDirectory :
> DiagGroup<"invalid-or-nonexistent-directory">;
> +
> +def OptionIgnored : DiagGroup<"option-ignored">;
>
> Modified: cfe/trunk/lib/Driver/Driver.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Driver.cpp?rev=250262&r1=250261&r2=250262&view=diff
>
> ==
> --- cfe/trunk/lib/Driver/Driver.cpp (original)
> +++ cfe/trunk/lib/Driver/Driver.cpp Tue Oct 13 20:09:02 2015
> @@ -2261,6 +2261,9 @@ const ToolChain &Driver::getToolChain(co
>  case llvm::Triple::CUDA:
>TC = new toolchains::CudaToolChain(*this, Target, Args);
>break;
> +case llvm::Triple::PS4:
> +  TC = new toolchains::PS4CPU

Re: [PATCH] D13482: Revised Initial patch for PS4 toolchain

[Sean Silva via cfe-commits]

On Tue, Oct 13, 2015 at 7:51 PM, Katya Romanova <
katya_roman...@playstation.sony.com> wrote:

> kromanova added a comment.
>
> Hi,
>
> The initial PS4 patch caused a test failure (debug-options.c) on the PS4
> bot. I suspect that I know why the problem happens, but I'm not sure what
> will be the best way to handle it. If someone knows how to fix this test
> more "elegantly", I would appreciate their advice.
>
> FAIL: Clang :: Driver/debug-options.c (3509 of 24708)
>
> - TEST 'Clang :: Driver/debug-options.c' FAILED 
>
> Script:
> ---
>
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/clang
> -### -c -g
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c
> -target x86_64-linux-gnu 2>&1  |
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/FileCheck
> -check-prefix=G /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-
> 
>
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/clang
> -### -g
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c
> 2>&1 |
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/FileCheck
> -check-prefix=CI
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c
>
> 
>
> Exit Code: 1
>
> Command Output (stderr):
> 
>
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c:139:8:
> error: expected string not found in input
> // CI: "-dwarf-column-info"
>
>   ^
>
> :1:1: note: scanning from here
> clang version 3.8.0 (trunk 250262)
> ^
> :5:438: note: possible intended match here
>  
> "/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/bin/clang-3.8"
> "-cc1" "-triple" "x86_64-scei-ps4" "-emit-obj" "-mrelax-all"
> "-disable-free" "-main-file-name" "debug-options.c" "-mrelocation-model"
> "pic" "-pic-level" "2" "-mthread-model" "posix" "-mdisable-fp-elim"
> "-masm-verbose" "-mconstructor-aliases" "-munwind-tables" "-target-cpu"
> "btver2" "-momit-leaf-frame-pointer" "-debug-info-kind=limited"
> "-dwarf-version=4" "-backend-option" "-generate-arange-section"
> "-resource-dir"
> "/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/bin/../lib/clang/3.8.0"
> "-fdebug-compilation-dir"
> "/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/tools/clang/test/Driver"
> "-ferror-limit" "19" "-fmessage-length" "0" "-stack-protector" "2"
> "-fdeclspec" "-fobjc-runtime=gnustep" "-fdiagnostics-show-option" "-o"
> "/tmp/debug-options-1505f5.o" "-x" "c"
> "/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c"
>
>
>
>
>
>  ^
>
> -
>
> The latest driver patch introduced a change, causing the PS4 driver *not*
> to have -gcolumn-info enabled by default.
>
> Consequently, this generic line started to fail on the PS4 bot.
> // RUN: %clang -### -g %s 2>&1 | FileCheck -check-prefix=CI %s
>
> Does someone know what will be the best way to run the test line for all
> the platforms, except PS4?
>
> In the patch, we have added a couple of PS4 specific lines to this test,
> to verify that the behavior on PS4 is correct:
>
> // RUN: %clang -### -c %s -g -target x86_64-scei-ps4 2>&1 \
> // RUN: | FileCheck -check-prefix=NOCI %s
>
> // RUN: %clang -### -c %s -g -gcolumn-info -target x86_64-scei-ps4 2>&1 \
> // RUN: | FileCheck -check-prefix=CI %s
>
> I do not want to make this test XFAIL for PS4 (though I might do it as an
> interim solution). I would also prefer to avoid duplicating most of the
> content of this file into a separate ps4-specific file.
> Any ideas how to handle this issue "more elegantly"?
>
> If nobody objects, I will mark this test as XFAIL for PS4 for a time being.
>

Please revert until you can solve the issue.

-- Sean Silva


>
> Katya.
>
>
> Repository:
>   rL LLVM
>
> http://reviews.llvm.org/D13482
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D13482: Revised Initial patch for PS4 toolchain

[Sean Silva via cfe-commits]

On Tue, Oct 13, 2015 at 11:33 PM, Eric Christopher 
wrote:

> It was already reverted, but I agree, let's get this fixed first.
>

It was reintroduced in r250252. It is breaking
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/1362

-- Sean Silva


>
> Thanks!
>
> -eric
>
> On Tue, Oct 13, 2015 at 11:33 PM Sean Silva  wrote:
>
>> On Tue, Oct 13, 2015 at 7:51 PM, Katya Romanova <
>> katya_roman...@playstation.sony.com> wrote:
>>
>>> kromanova added a comment.
>>>
>>> Hi,
>>>
>>> The initial PS4 patch caused a test failure (debug-options.c) on the PS4
>>> bot. I suspect that I know why the problem happens, but I'm not sure what
>>> will be the best way to handle it. If someone knows how to fix this test
>>> more "elegantly", I would appreciate their advice.
>>>
>>> FAIL: Clang :: Driver/debug-options.c (3509 of 24708)
>>>
>>> - TEST 'Clang :: Driver/debug-options.c' FAILED 
>>>
>>> Script:
>>> ---
>>>
>>> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/clang
>>> -### -c -g
>>> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c
>>> -target x86_64-linux-gnu 2>&1  |
>>> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/FileCheck
>>> -check-prefix=G /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-
>>> 
>>>
>>> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/clang
>>> -### -g
>>> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c
>>> 2>&1 |
>>> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/FileCheck
>>> -check-prefix=CI
>>> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c
>>>
>>> 
>>>
>>> Exit Code: 1
>>>
>>> Command Output (stderr):
>>> 
>>>
>>> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c:139:8:
>>> error: expected string not found in input
>>> // CI: "-dwarf-column-info"
>>>
>>>   ^
>>>
>>> :1:1: note: scanning from here
>>> clang version 3.8.0 (trunk 250262)
>>> ^
>>> :5:438: note: possible intended match here
>>>  
>>> "/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/bin/clang-3.8"
>>> "-cc1" "-triple" "x86_64-scei-ps4" "-emit-obj" "-mrelax-all"
>>> "-disable-free" "-main-file-name" "debug-options.c" "-mrelocation-model"
>>> "pic" "-pic-level" "2" "-mthread-model" "posix" "-mdisable-fp-elim"
>>> "-masm-verbose" "-mconstructor-aliases" "-munwind-tables" "-target-cpu"
>>> "btver2" "-momit-leaf-frame-pointer" "-debug-info-kind=limited"
>>> "-dwarf-version=4" "-backend-option" "-generate-arange-section"
>>> "-resource-dir"
>>> "/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/bin/../lib/clang/3.8.0"
>>> "-fdebug-compilation-dir"
>>> "/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/tools/clang/test/Driver"
>>> "-ferror-limit" "19" "-fmessage-length" "0" "-stack-protector" "2"
>>> "-fdeclspec" "-fobjc-runtime=gnustep" "-fdiagnostics-show-option" "-o"
>>> "/tmp/debug-options-1505f5.o" "-x" "c"
>>> "/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c"
>>>
>>>
>>>
>>>
>>>
>>>^
>>>
>>> -
>>>
>>> The latest driver patch introduced a change, causing the PS4 driver
>>> *not* to have -gcolumn-info enabled by default.
>>>
>>> Consequently, this generic line started to fail on the PS4 bot.
>>> // RUN: %clang -### -g %s 2>&1 | FileCheck -check-prefix=CI %s
>>>
>>> Does someone know what will be the best way to run the test line for all
>>> the platforms, except PS4?
>>>
>>> In the patch, we have added a couple of PS4 specific lines to this test,
>>> to verify that the behavior on PS4 is correct:
>>>
>>> // RUN: %clang -### -c %s -g -target x86_64-scei-ps4 2>&1 \
>>> // RUN: | FileCheck -check-prefix=NOCI %s
>>>
>>> // RUN: %clang -### -c %s -g -gcolumn-info -target x86_64-scei-ps4 2>&1 \
>>> // RUN: | FileCheck -check-prefix=CI %s
>>>
>>> I do not want to make this test XFAIL for PS4 (though I might do it as
>>> an interim solution). I would also prefer to avoid dupl

r250273 - Revert-to-green r250262 (PS4 toolchain patch)

[Sean Silva via cfe-commits]

Author: silvas
Date: Wed Oct 14 01:45:07 2015
New Revision: 250273

URL: http://llvm.org/viewvc/llvm-project?rev=250273&view=rev
Log:
Revert-to-green r250262 (PS4 toolchain patch)

It is breaking llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast
e.g. 
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/1362

Removed:
cfe/trunk/test/Driver/Inputs/scei-ps4_tree/target/include/.keep
cfe/trunk/test/Driver/Inputs/scei-ps4_tree/target/include_common/.keep
cfe/trunk/test/Driver/no-integrated-as.s
cfe/trunk/test/Driver/ps4-header-search.c
cfe/trunk/test/Driver/ps4-linker-non-win.c
cfe/trunk/test/Driver/ps4-linker-win.c
cfe/trunk/test/Driver/ps4-pic.c
cfe/trunk/test/Driver/ps4-sdk-root.c
Modified:
cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
cfe/trunk/include/clang/Basic/DiagnosticGroups.td
cfe/trunk/lib/Driver/Driver.cpp
cfe/trunk/lib/Driver/ToolChains.cpp
cfe/trunk/lib/Driver/ToolChains.h
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/lib/Driver/Tools.h
cfe/trunk/lib/Frontend/InitHeaderSearch.cpp
cfe/trunk/test/Driver/debug-options.c
cfe/trunk/test/Driver/stack-protector.c

Modified: cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td?rev=250273&r1=250272&r2=250273&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td Wed Oct 14 01:45:07 
2015
@@ -196,18 +196,4 @@ def warn_target_unsupported_nan2008 : Wa
 def warn_target_unsupported_nanlegacy : Warning<
   "ignoring '-mnan=legacy' option because the '%0' architecture does not 
support it">,
   InGroup;
-
-def warn_drv_unable_to_find_directory_expected : Warning<
-  "unable to find %0 directory, expected to be in '%1'">,
-  InGroup, DefaultIgnore;
-
-def warn_drv_ps4_force_pic : Warning<
-  "option '%0' was ignored by the PS4 toolchain, using '-fPIC'">,
-  InGroup;
-
-def warn_drv_ps4_sdk_dir : Warning<
-  "environment variable SCE_PS4_SDK_DIR is set, but points to invalid or 
nonexistent directory '%0'">,
-  InGroup;
-
-def err_drv_unsupported_linker : Error<"unsupported value '%0' for -linker 
option">;
 }

Modified: cfe/trunk/include/clang/Basic/DiagnosticGroups.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticGroups.td?rev=250273&r1=250272&r2=250273&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticGroups.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticGroups.td Wed Oct 14 01:45:07 2015
@@ -823,7 +823,3 @@ def CudaCompat : DiagGroup<"cuda-compat"
 
 // A warning group for things that will change semantics in the future.
 def FutureCompat : DiagGroup<"future-compat">;
-
-def InvalidOrNonExistentDirectory : 
DiagGroup<"invalid-or-nonexistent-directory">;
-
-def OptionIgnored : DiagGroup<"option-ignored">;

Modified: cfe/trunk/lib/Driver/Driver.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Driver.cpp?rev=250273&r1=250272&r2=250273&view=diff
==
--- cfe/trunk/lib/Driver/Driver.cpp (original)
+++ cfe/trunk/lib/Driver/Driver.cpp Wed Oct 14 01:45:07 2015
@@ -2261,9 +2261,6 @@ const ToolChain &Driver::getToolChain(co
 case llvm::Triple::CUDA:
   TC = new toolchains::CudaToolChain(*this, Target, Args);
   break;
-case llvm::Triple::PS4:
-  TC = new toolchains::PS4CPU(*this, Target, Args);
-  break;
 default:
   // Of these targets, Hexagon is the only one that might have
   // an OS of Linux, in which case it got handled above already.

Modified: cfe/trunk/lib/Driver/ToolChains.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains.cpp?rev=250273&r1=250272&r2=250273&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains.cpp Wed Oct 14 01:45:07 2015
@@ -4066,77 +4066,3 @@ void WebAssembly::addClangTargetOptions(
  options::OPT_fno_use_init_array, true))
 CC1Args.push_back("-fuse-init-array");
 }
-
-PS4CPU::PS4CPU(const Driver &D, const llvm::Triple &Triple, const ArgList 
&Args)
-: Generic_ELF(D, Triple, Args) {
-  if (Args.hasArg(options::OPT_static))
-D.Diag(diag::err_drv_unsupported_opt_for_target) << "-static" << "PS4";
-
-  // Determine where to find the PS4 libraries. We use SCE_PS4_SDK_DIR
-  // if it exists; otherwise use the driver's installation path, which
-  // should be /host_tools/bin.
-
-  SmallString<512> PS4SDKDir;
-  if (const char *EnvValue = getenv("SCE_PS4_SDK_DIR")) {
-if (!llvm::sys::fs::exists(EnvValue))
-  getDriver().Diag(clang::diag::warn_drv_ps

Re: [PATCH] D13482: Revised Initial patch for PS4 toolchain

[Sean Silva via cfe-commits]

On Tue, Oct 13, 2015 at 11:40 PM, Eric Christopher 
wrote:

>
>
> On Tue, Oct 13, 2015 at 11:38 PM Sean Silva  wrote:
>
>> On Tue, Oct 13, 2015 at 11:33 PM, Eric Christopher 
>> wrote:
>>
>>> It was already reverted, but I agree, let's get this fixed first.
>>>
>>
>> It was reintroduced in r250252. It is breaking
>> http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/1362
>>
>>
> Ah, I missed that. Yeah, please go ahead and revert for now.
>

reverted in r250273
(bot is back to green:
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/1363
)

Katya - remember to run the tests
with LLVM_DEFAULT_TARGET_TRIPLE=x86_64-scei-ps4 (and also remember to keep
an eye on the bots after committing)

-- Sean Silva


>
> Thanks!
>
> -eric
>
>
>> -- Sean Silva
>>
>>
>>>
>>> Thanks!
>>>
>>> -eric
>>>
>>> On Tue, Oct 13, 2015 at 11:33 PM Sean Silva 
>>> wrote:
>>>
 On Tue, Oct 13, 2015 at 7:51 PM, Katya Romanova <
 katya_roman...@playstation.sony.com> wrote:

> kromanova added a comment.
>
> Hi,
>
> The initial PS4 patch caused a test failure (debug-options.c) on the
> PS4 bot. I suspect that I know why the problem happens, but I'm not sure
> what will be the best way to handle it. If someone knows how to fix this
> test more "elegantly", I would appreciate their advice.
>
> FAIL: Clang :: Driver/debug-options.c (3509 of 24708)
>
> - TEST 'Clang :: Driver/debug-options.c' FAILED 
>
> Script:
> ---
>
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/clang
> -### -c -g
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c
> -target x86_64-linux-gnu 2>&1  |
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/FileCheck
> -check-prefix=G /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-
> 
>
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/clang
> -### -g
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c
> 2>&1 |
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/FileCheck
> -check-prefix=CI
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c
>
> 
>
> Exit Code: 1
>
> Command Output (stderr):
> 
>
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c:139:8:
> error: expected string not found in input
> // CI: "-dwarf-column-info"
>
>   ^
>
> :1:1: note: scanning from here
> clang version 3.8.0 (trunk 250262)
> ^
> :5:438: note: possible intended match here
>  
> "/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/bin/clang-3.8"
> "-cc1" "-triple" "x86_64-scei-ps4" "-emit-obj" "-mrelax-all"
> "-disable-free" "-main-file-name" "debug-options.c" "-mrelocation-model"
> "pic" "-pic-level" "2" "-mthread-model" "posix" "-mdisable-fp-elim"
> "-masm-verbose" "-mconstructor-aliases" "-munwind-tables" "-target-cpu"
> "btver2" "-momit-leaf-frame-pointer" "-debug-info-kind=limited"
> "-dwarf-version=4" "-backend-option" "-generate-arange-section"
> "-resource-dir"
> "/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/bin/../lib/clang/3.8.0"
> "-fdebug-compilation-dir"
> "/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/tools/clang/test/Driver"
> "-ferror-limit" "19" "-fmessage-length" "0" "-stack-protector" "2"
> "-fdeclspec" "-fobjc-runtime=gnustep" "-fdiagnostics-show-option" "-o"
> "/tmp/debug-options-1505f5.o" "-x" "c"
> "/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c"
>
>
>
>
>
>  ^
>
> -
>
> The latest driver patch introduced a change, causing the PS4 driver
> *not* to have -gcolumn-info enabled by default.
>
> Consequently, this generic line started to fail on th

Re: [libcxx] r249738 - Split out of .

[Sean Silva via cfe-commits]

On Wed, Oct 14, 2015 at 3:32 PM, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On Wed, Oct 14, 2015 at 2:03 PM, Adrian Prantl via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> On Oct 14, 2015, at 11:37 AM, Adrian Prantl via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>> On Oct 13, 2015, at 7:43 PM, Richard Smith  wrote:
>>
>> On Tue, Oct 13, 2015 at 6:54 PM, Sean Silva 
>> wrote:
>>
>>> On Tue, Oct 13, 2015 at 6:14 PM, Richard Smith 
>>> wrote:
>>>
 On Tue, Oct 13, 2015 at 5:31 PM, Sean Silva 
 wrote:

> On Tue, Oct 13, 2015 at 3:17 PM, Richard Smith via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> On Tue, Oct 13, 2015 at 2:10 PM, Adrian Prantl via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Hi Richard,
>>>
>>> this commit appears to break the module self-host on Darwin.
>>>
>>> When compiling the following program generated by clang’s own cmake
>>> script:
>>>
>>> > #undef NDEBUG
>>> > #include 
>>> > #define NDEBUG
>>> > #include 
>>> > int main() { assert(this code is not compiled); }
>>>
>>> with clang++ -std=c++11 -fmodules -fcxx-modules test.cpp
>>>
>>
>> (You don't need -fcxx-modules here.)
>>
>>
>>> I get
>>>
>>> > While building module 'std' imported from /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20
>>> :
>>> > While building module 'Darwin' imported from
>>> /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39
>>> :
>>> > In file included from :98:
>>> > In file included from
>>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/wchar.h:92:
>>> > In file included from
>>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/_wctype.h:57:
>>
>> > /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/ctype.h:33:10
>>> :
>>> fatal error: cyclic dependency in module 'std': std -> Darwin -> std
>>> > #include <__config>
>>> >  ^
>>> > While building module 'std' imported from /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20
>>> :
>>> > In file included from :1:
>>> > In file included from /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/algorithm:624
>>> :
>>> > In file included from /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/initializer_list:47
>>> 
>>> :
>>> > /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39:10
>>> :
>>> fatal error: could not build module 'Darwin'
>>> > #include 
>>> >  ^
>>> > In file included from test.cpp:2:
>>> > /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:10
>>> :
>>> fatal error: could not build module 'std'
>>> > #include <__config>
>>> >  ^
>>> > 3 errors generated.
>>>
>>> Let me know how I can help in diagnosing what’s going on here.
>>>
>>
>> OK, I see what's wrong. Is this working any better for you in r250236?
>>
>
> We're still seeing:
>
> While building module 'Darwin' imported from /usr/include/assert.h:42:
> While building module 'std' imported from
> /path/to/build_cmake/stage1/bin/../include/c++/v1/math.h:309:
>

 Argh, this is including , which is in the std module. Can
 you try removing the header "type_traits" line from the libc++ module map
 and see if that helps?

>>>
>>> I've run into this issue in the past, and I don't think that will fix it
>>> (see below). Just to be sure, here is the output with type_traits removed
>>> from the module map::
>>>
>>> While building module 'Darwin' imported from /usr/include/assert.h:42:
>>> While building module 'std' imported from
>>> /path/to/build_cmake/stage1/bin/../include/c++/v1/type_traits:211:
>>>
>>
>> That's an include of . We'd need to apply this workaround to
>> that header too (but I think the buck stops there).
>>
>>
>> After commenting out the cstddef module as well, the test case compiles
>> 

Re: [libcxx] r249738 - Split out of .

[Sean Silva via cfe-commits]

On Tue, Oct 13, 2015 at 7:43 PM, Richard Smith 
wrote:

> On Tue, Oct 13, 2015 at 6:54 PM, Sean Silva  wrote:
>
>> On Tue, Oct 13, 2015 at 6:14 PM, Richard Smith 
>> wrote:
>>
>>> On Tue, Oct 13, 2015 at 5:31 PM, Sean Silva 
>>> wrote:
>>>
 On Tue, Oct 13, 2015 at 3:17 PM, Richard Smith via cfe-commits <
 cfe-commits@lists.llvm.org> wrote:

> On Tue, Oct 13, 2015 at 2:10 PM, Adrian Prantl via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Hi Richard,
>>
>> this commit appears to break the module self-host on Darwin.
>>
>> When compiling the following program generated by clang’s own cmake
>> script:
>>
>> > #undef NDEBUG
>> > #include 
>> > #define NDEBUG
>> > #include 
>> > int main() { assert(this code is not compiled); }
>>
>> with clang++ -std=c++11 -fmodules -fcxx-modules test.cpp
>>
>
> (You don't need -fcxx-modules here.)
>
>
>> I get
>>
>> > While building module 'std' imported from /Users/buildslave/adrian/
>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:
>> > While building module 'Darwin' imported from
>> /Users/buildslave/adrian/
>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39:
>> > In file included from :98:
>> > In file included from
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/wchar.h:92:
>> > In file included from
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/_wctype.h:57:
>
> > /Users/buildslave/adrian/
>> llvm.org/_build.ninja.release/bin/../include/c++/v1/ctype.h:33:10:
>> fatal error: cyclic dependency in module 'std': std -> Darwin -> std
>> > #include <__config>
>> >  ^
>> > While building module 'std' imported from /Users/buildslave/adrian/
>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:
>> > In file included from :1:
>> > In file included from /Users/buildslave/adrian/
>> llvm.org/_build.ninja.release/bin/../include/c++/v1/algorithm:624:
>> > In file included from /Users/buildslave/adrian/
>> llvm.org/_build.ninja.release/bin/../include/c++/v1/initializer_list:47
>> :
>> > /Users/buildslave/adrian/
>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39:10:
>> fatal error: could not build module 'Darwin'
>> > #include 
>> >  ^
>> > In file included from test.cpp:2:
>> > /Users/buildslave/adrian/
>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:10:
>> fatal error: could not build module 'std'
>> > #include <__config>
>> >  ^
>> > 3 errors generated.
>>
>> Let me know how I can help in diagnosing what’s going on here.
>>
>
> OK, I see what's wrong. Is this working any better for you in r250236?
>

 We're still seeing:

 While building module 'Darwin' imported from /usr/include/assert.h:42:
 While building module 'std' imported from
 /path/to/build_cmake/stage1/bin/../include/c++/v1/math.h:309:

>>>
>>> Argh, this is including , which is in the std module. Can
>>> you try removing the header "type_traits" line from the libc++ module map
>>> and see if that helps?
>>>
>>
>> I've run into this issue in the past, and I don't think that will fix it
>> (see below). Just to be sure, here is the output with type_traits removed
>> from the module map::
>>
>> While building module 'Darwin' imported from /usr/include/assert.h:42:
>> While building module 'std' imported from
>> /path/to/build_cmake/stage1/bin/../include/c++/v1/type_traits:211:
>>
>
> That's an include of . We'd need to apply this workaround to that
> header too (but I think the buck stops there).
>

> In file included from :1:
>> In file included from
>> /path/to/build_cmake/stage1/bin/../include/c++/v1/algorithm:624:
>> In file included from
>> /path/to/build_cmake/stage1/bin/../include/c++/v1/initializer_list:47:
>> In file included from
>> /path/to/build_cmake/stage1/bin/../include/c++/v1/cstddef:43:
>> /path/to/build_cmake/stage1/bin/../include/c++/v1/stddef.h:46:15: fatal
>> error: cyclic dependency in module 'Darwin': Darwin -> std -> Darwin
>> #include_next 
>>   ^
>> While building module 'Darwin' imported from /usr/include/assert.h:42:
>> In file included from :80:
>> In file included from
>> /path/to/build_cmake/stage1/bin/../lib/clang/3.8.0/include/tgmath.h:29:
>> In file included from
>> /path/to/build_cmake/stage1/bin/../include/c++/v1/math.h:309:
>> /path/to/build_cmake/stage1/bin/../include/c++/v1/type_traits:211:10:
>> fatal error: could not build module 'std'
>> #include 
>>  ^
>> In file included from modules.cpp:2:
>> In file included from
>> /path/to/build_cmake/stage1/bin/../include/c++/v1/cassert:21:
>> /usr/include/assert.h:42:10: fatal err

Re: [PATCH] D13482: Revised Initial patch for PS4 toolchain

[Sean Silva via cfe-commits]

On Wed, Oct 14, 2015 at 12:54 AM, Romanova, Katya <
katya_roman...@playstation.sony.com> wrote:

> Hi Sean,
>
>
>
> I don’t think that the whole patch should have been reverted. There were
> much easier way to make the PS4 bot green. A single test could have been
> marked as “XFAIL: ps4” for a few hours until a better solution is
> implemented. Reverting this huge patch is more drastic measure that might
> cause more problems later.
>
>
>
> As you saw in my previous email, I kept an eye on the bots, noticed the
> failure on PS4 buildbot, explained why it happened in the email and ask
> community for an opinion if it could be temporarily marked as “XFAIL” for
> ps4 only. I had to leave work at certain point. When I got home, I saw that
> you reverted the whole fix. Now I will have to go through all the pain with
> maintaining a huge commit, instead of making one line change affecting one
> of the tests on PS4 platform only… But, I guess, if it’s a general
> practice,  then it’s a different story. I was not aware of this practice
> and I thought that the other solution was much more reasonable.
>

Yes, it is general practice. Reverting is easier and sends a clear signal
that broken code is not allowed. XFAIL gives the impression that it is
failing for some reason that is not preventable (for example, the operating
system doesn't support some system call that is needed); that is not true
in this case: there was just an oversight and broken code was committed.

Also, the bot had been red for a *very* long time and there was no
indication that you were doing anything about it (I reverted at almost
midnight). In the future, be sure to keep an eye on the bots and either
commit a fix or revert to green. "commit and go home" is very inconsiderate
to all fellow community members.

-- Sean Silva


>
>
> Thank you for letting me know about 
> LLVM_DEFAULT_TARGET_TRIPLE=x86_64-scei-ps4.
> I will definitely run it before the next commit.
>
>
>
> Katya.
>
>
>
>
>
> *From:* Sean Silva [mailto:chisophu...@gmail.com]
> *Sent:* Tuesday, October 13, 2015 11:56 PM
> *To:* Eric Christopher
> *Cc:* reviews+d13482+public+a1a9627af638c...@reviews.llvm.org; Romanova,
> Katya; Alex Rosenberg; Robinson, Paul; filcab+llvm.phabrica...@gmail.com;
> Jonathan Roelofs; Bedwell, Greg; pierregoussea...@gmail.com; Anton
> Korobeynikov; Takumi NAKAMURA; cfe-commits
> *Subject:* Re: [PATCH] D13482: Revised Initial patch for PS4 toolchain
>
>
>
>
>
>
>
> On Tue, Oct 13, 2015 at 11:40 PM, Eric Christopher 
> wrote:
>
>
>
> On Tue, Oct 13, 2015 at 11:38 PM Sean Silva  wrote:
>
> On Tue, Oct 13, 2015 at 11:33 PM, Eric Christopher 
> wrote:
>
> It was already reverted, but I agree, let's get this fixed first.
>
>
>
> It was reintroduced in r250252. It is breaking
> http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/1362
>
>
>
>
>
> Ah, I missed that. Yeah, please go ahead and revert for now.
>
>
>
> reverted in r250273
>
> (bot is back to green:
> http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/1363
> )
>
>
>
> Katya - remember to run the tests
> with LLVM_DEFAULT_TARGET_TRIPLE=x86_64-scei-ps4 (and also remember to keep
> an eye on the bots after committing)
>
>
>
> -- Sean Silva
>
>
>
>
>
> Thanks!
>
>
>
> -eric
>
>
>
> -- Sean Silva
>
>
>
>
>
> Thanks!
>
>
>
> -eric
>
>
>
> On Tue, Oct 13, 2015 at 11:33 PM Sean Silva  wrote:
>
> On Tue, Oct 13, 2015 at 7:51 PM, Katya Romanova <
> katya_roman...@playstation.sony.com> wrote:
>
> kromanova added a comment.
>
> Hi,
>
> The initial PS4 patch caused a test failure (debug-options.c) on the PS4
> bot. I suspect that I know why the problem happens, but I'm not sure what
> will be the best way to handle it. If someone knows how to fix this test
> more "elegantly", I would appreciate their advice.
>
> FAIL: Clang :: Driver/debug-options.c (3509 of 24708)
>
> - TEST 'Clang :: Driver/debug-options.c' FAILED 
>
> Script:
> ---
>
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/clang
> -### -c -g
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c
> -target x86_64-linux-gnu 2>&1  |
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/FileCheck
> -check-prefix=G /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-
> 
>
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/clang
> -### -g
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c
> 2>&1 |
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/FileCheck
> -check-prefix=CI
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c
>
> ---

Re: r250577 - [modules] Allow the error when explicitly loading an incompatible module file

[Sean Silva via cfe-commits]

On Fri, Oct 16, 2015 at 4:20 PM, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rsmith
> Date: Fri Oct 16 18:20:19 2015
> New Revision: 250577
>
> URL: http://llvm.org/viewvc/llvm-project?rev=250577&view=rev
> Log:
> [modules] Allow the error when explicitly loading an incompatible module
> file
> via -fmodule-file= to be turned off; in that case, just include the
> relevant
> files textually. This allows module files to be unconditionally passed to
> all
> compile actions via CXXFLAGS, and to be ignored for rules that specify
> custom
> incompatible flags.
>

What direction are you trying to go with this? Are you thinking something
like having CMake build a bunch of modules up front?

If that's the case, it would be nice to explain what caused the mismatch,
so that the user can look into rectifying it. Otherwise this warning is not
directly actionable. The existing diagnostics seemed alright. Demoting them
to "error: {{.*}} configuration mismatch" seems like a regression.

-- Sean Silva


>
> Modified:
> cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
> cfe/trunk/lib/Frontend/CompilerInstance.cpp
> cfe/trunk/test/Modules/merge-target-features.cpp
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td?rev=250577&r1=250576&r2=250577&view=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td Fri Oct 16
> 18:20:19 2015
> @@ -172,6 +172,9 @@ def warn_incompatible_analyzer_plugin_ap
>  def note_incompatible_analyzer_plugin_api : Note<
>  "current API version is '%0', but plugin was compiled with version
> '%1'">;
>
> +def warn_module_config_mismatch : Warning<
> +  "module file %0 cannot be loaded due to a configuration mismatch with
> the current "
> +  "compilation">, InGroup>,
> DefaultError;
>  def err_module_map_not_found : Error<"module map file '%0' not found">,
>DefaultFatal;
>  def err_missing_module_name : Error<
>
> Modified: cfe/trunk/lib/Frontend/CompilerInstance.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/CompilerInstance.cpp?rev=250577&r1=250576&r2=250577&view=diff
>
> ==
> --- cfe/trunk/lib/Frontend/CompilerInstance.cpp (original)
> +++ cfe/trunk/lib/Frontend/CompilerInstance.cpp Fri Oct 16 18:20:19 2015
> @@ -1335,15 +1335,24 @@ bool CompilerInstance::loadModuleFile(St
> std::move(Listener));
>
>// Try to load the module file.
> -  if (ModuleManager->ReadAST(FileName, serialization::MK_ExplicitModule,
> - SourceLocation(), ASTReader::ARR_None)
> -  != ASTReader::Success)
> -return false;
> -
> +  switch (ModuleManager->ReadAST(FileName,
> serialization::MK_ExplicitModule,
> + SourceLocation(),
> + ASTReader::ARR_ConfigurationMismatch)) {
> +  case ASTReader::Success:
>// We successfully loaded the module file; remember the set of provided
>// modules so that we don't try to load implicit modules for them.
>ListenerRef.registerAll();
>return true;
> +
> +  case ASTReader::ConfigurationMismatch:
> +// Ignore unusable module files.
> +getDiagnostics().Report(SourceLocation(),
> diag::warn_module_config_mismatch)
> +<< FileName;
> +return true;
> +
> +  default:
> +return false;
> +  }
>  }
>
>  ModuleLoadResult
>
> Modified: cfe/trunk/test/Modules/merge-target-features.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/merge-target-features.cpp?rev=250577&r1=250576&r2=250577&view=diff
>
> ==
> --- cfe/trunk/test/Modules/merge-target-features.cpp (original)
> +++ cfe/trunk/test/Modules/merge-target-features.cpp Fri Oct 16 18:20:19
> 2015
> @@ -20,7 +20,7 @@
>  // RUN:   -target-cpu i386 \
>  // RUN:   -fsyntax-only merge-target-features.cpp 2>&1 \
>  // RUN:   | FileCheck --check-prefix=SUBSET %s
> -// SUBSET: AST file was compiled with the target feature'+sse2' but the
> current translation unit is not
> +// SUBSET: error: {{.*}} configuration mismatch
>  //
>  // RUN: %clang_cc1 -fmodules -x c++ -fmodules-cache-path=%t \
>  // RUN:   -iquote Inputs/merge-target-features \
> @@ -56,8 +56,7 @@
>  // RUN:   -target-cpu i386 -target-feature +cx16 \
>  // RUN:   -fsyntax-only merge-target-features.cpp 2>&1 \
>  // RUN:   | FileCheck --check-prefix=MISMATCH %s
> -// MISMATCH: AST file was compiled with the target feature'+sse2' but the
> current translation unit is not
> -// MISMATCH: current translation unit was compiled with the target
> feature'+cx16' but the AST 

Re: r250577 - [modules] Allow the error when explicitly loading an incompatible module file

[Sean Silva via cfe-commits]

On Fri, Oct 16, 2015 at 6:12 PM, Richard Smith 
wrote:

> On Fri, Oct 16, 2015 at 4:43 PM, Sean Silva  wrote:
>
>> On Fri, Oct 16, 2015 at 4:20 PM, Richard Smith via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: rsmith
>>> Date: Fri Oct 16 18:20:19 2015
>>> New Revision: 250577
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=250577&view=rev
>>> Log:
>>> [modules] Allow the error when explicitly loading an incompatible module
>>> file
>>> via -fmodule-file= to be turned off; in that case, just include the
>>> relevant
>>> files textually. This allows module files to be unconditionally passed
>>> to all
>>> compile actions via CXXFLAGS, and to be ignored for rules that specify
>>> custom
>>> incompatible flags.
>>>
>>
>> What direction are you trying to go with this? Are you thinking something
>> like having CMake build a bunch of modules up front?
>>
>
> That's certainly one thing you can do with this. Another is that you can
> make cmake automatically and explicitly build a module for each library,
> and then provide that for all the dependencies of that library,
>

How does CMake know which headers are part of which library? Strategically
named top-level modules in the module map?

-- Sean Silva


> with an (error-by-default) warning in the case where the downstream
> library specifies incompatible compilation flags. You can use this warning
> flag to turn off the error so you can make progress before you get around
> to fixing all the incompatible flags.
>
>
>> If that's the case, it would be nice to explain what caused the mismatch,
>> so that the user can look into rectifying it. Otherwise this warning is not
>> directly actionable. The existing diagnostics seemed alright. Demoting them
>> to "error: {{.*}} configuration mismatch" seems like a regression.
>>
>
> I agree, it is a regression, and fixing it is high on my list of
> priorities (sorry for not mentioning that in the commit message).
>
> -- Sean Silva
>>
>>
>>>
>>> Modified:
>>> cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
>>> cfe/trunk/lib/Frontend/CompilerInstance.cpp
>>> cfe/trunk/test/Modules/merge-target-features.cpp
>>>
>>> Modified: cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td?rev=250577&r1=250576&r2=250577&view=diff
>>>
>>> ==
>>> --- cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td (original)
>>> +++ cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td Fri Oct 16
>>> 18:20:19 2015
>>> @@ -172,6 +172,9 @@ def warn_incompatible_analyzer_plugin_ap
>>>  def note_incompatible_analyzer_plugin_api : Note<
>>>  "current API version is '%0', but plugin was compiled with version
>>> '%1'">;
>>>
>>> +def warn_module_config_mismatch : Warning<
>>> +  "module file %0 cannot be loaded due to a configuration mismatch with
>>> the current "
>>> +  "compilation">, InGroup>,
>>> DefaultError;
>>>  def err_module_map_not_found : Error<"module map file '%0' not found">,
>>>DefaultFatal;
>>>  def err_missing_module_name : Error<
>>>
>>> Modified: cfe/trunk/lib/Frontend/CompilerInstance.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/CompilerInstance.cpp?rev=250577&r1=250576&r2=250577&view=diff
>>>
>>> ==
>>> --- cfe/trunk/lib/Frontend/CompilerInstance.cpp (original)
>>> +++ cfe/trunk/lib/Frontend/CompilerInstance.cpp Fri Oct 16 18:20:19 2015
>>> @@ -1335,15 +1335,24 @@ bool CompilerInstance::loadModuleFile(St
>>> std::move(Listener));
>>>
>>>// Try to load the module file.
>>> -  if (ModuleManager->ReadAST(FileName, serialization::MK_ExplicitModule,
>>> - SourceLocation(), ASTReader::ARR_None)
>>> -  != ASTReader::Success)
>>> -return false;
>>> -
>>> +  switch (ModuleManager->ReadAST(FileName,
>>> serialization::MK_ExplicitModule,
>>> + SourceLocation(),
>>> + ASTReader::ARR_ConfigurationMismatch))
>>> {
>>> +  case ASTReader::Success:
>>>// We successfully loaded the module file; remember the set of
>>> provided
>>>// modules so that we don't try to load implicit modules for them.
>>>ListenerRef.registerAll();
>>>return true;
>>> +
>>> +  case ASTReader::ConfigurationMismatch:
>>> +// Ignore unusable module files.
>>> +getDiagnostics().Report(SourceLocation(),
>>> diag::warn_module_config_mismatch)
>>> +<< FileName;
>>> +return true;
>>> +
>>> +  default:
>>> +return false;
>>> +  }
>>>  }
>>>
>>>  ModuleLoadResult
>>>
>>> Modified: cfe/trunk/test/Modules/merge-target-features.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/merge-target-features.cpp?rev=250577&r1=25057

Re: r250577 - [modules] Allow the error when explicitly loading an incompatible module file

[Sean Silva via cfe-commits]

On Fri, Oct 16, 2015 at 6:26 PM, Richard Smith 
wrote:

> On Fri, Oct 16, 2015 at 6:25 PM, Sean Silva  wrote:
>
>> On Fri, Oct 16, 2015 at 6:12 PM, Richard Smith 
>> wrote:
>>
>>> On Fri, Oct 16, 2015 at 4:43 PM, Sean Silva 
>>> wrote:
>>>
 On Fri, Oct 16, 2015 at 4:20 PM, Richard Smith via cfe-commits <
 cfe-commits@lists.llvm.org> wrote:

> Author: rsmith
> Date: Fri Oct 16 18:20:19 2015
> New Revision: 250577
>
> URL: http://llvm.org/viewvc/llvm-project?rev=250577&view=rev
> Log:
> [modules] Allow the error when explicitly loading an incompatible
> module file
> via -fmodule-file= to be turned off; in that case, just include the
> relevant
> files textually. This allows module files to be unconditionally passed
> to all
> compile actions via CXXFLAGS, and to be ignored for rules that specify
> custom
> incompatible flags.
>

 What direction are you trying to go with this? Are you thinking
 something like having CMake build a bunch of modules up front?

>>>
>>> That's certainly one thing you can do with this. Another is that you can
>>> make cmake automatically and explicitly build a module for each library,
>>> and then provide that for all the dependencies of that library,
>>>
>>
>> How does CMake know which headers are part of which library?
>> Strategically named top-level modules in the module map?
>>
>
> The idea would be for CMake to generate the module map itself based on the
> build rules.
>

How would it know which headers to include? Do our ADDITIONAL_HEADER_DIRS
things in our CMakeLists.txt have enough information for this?

-- Sean Silva


>
>
>> -- Sean Silva
>>
>>
>>> with an (error-by-default) warning in the case where the downstream
>>> library specifies incompatible compilation flags. You can use this warning
>>> flag to turn off the error so you can make progress before you get around
>>> to fixing all the incompatible flags.
>>>
>>>
 If that's the case, it would be nice to explain what caused the
 mismatch, so that the user can look into rectifying it. Otherwise this
 warning is not directly actionable. The existing diagnostics seemed
 alright. Demoting them to "error: {{.*}} configuration mismatch" seems like
 a regression.

>>>
>>> I agree, it is a regression, and fixing it is high on my list of
>>> priorities (sorry for not mentioning that in the commit message).
>>>
>>> -- Sean Silva


>
> Modified:
> cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
> cfe/trunk/lib/Frontend/CompilerInstance.cpp
> cfe/trunk/test/Modules/merge-target-features.cpp
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td?rev=250577&r1=250576&r2=250577&view=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td Fri Oct
> 16 18:20:19 2015
> @@ -172,6 +172,9 @@ def warn_incompatible_analyzer_plugin_ap
>  def note_incompatible_analyzer_plugin_api : Note<
>  "current API version is '%0', but plugin was compiled with
> version '%1'">;
>
> +def warn_module_config_mismatch : Warning<
> +  "module file %0 cannot be loaded due to a configuration mismatch
> with the current "
> +  "compilation">, InGroup>,
> DefaultError;
>  def err_module_map_not_found : Error<"module map file '%0' not
> found">,
>DefaultFatal;
>  def err_missing_module_name : Error<
>
> Modified: cfe/trunk/lib/Frontend/CompilerInstance.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/CompilerInstance.cpp?rev=250577&r1=250576&r2=250577&view=diff
>
> ==
> --- cfe/trunk/lib/Frontend/CompilerInstance.cpp (original)
> +++ cfe/trunk/lib/Frontend/CompilerInstance.cpp Fri Oct 16 18:20:19
> 2015
> @@ -1335,15 +1335,24 @@ bool CompilerInstance::loadModuleFile(St
>
> std::move(Listener));
>
>// Try to load the module file.
> -  if (ModuleManager->ReadAST(FileName,
> serialization::MK_ExplicitModule,
> - SourceLocation(), ASTReader::ARR_None)
> -  != ASTReader::Success)
> -return false;
> -
> +  switch (ModuleManager->ReadAST(FileName,
> serialization::MK_ExplicitModule,
> + SourceLocation(),
> +
>  ASTReader::ARR_ConfigurationMismatch)) {
> +  case ASTReader::Success:
>// We successfully loaded the module file; remember the set of
> provided
>// modules so that we don't try to load implicit modules for them.
>List

Re: r250577 - [modules] Allow the error when explicitly loading an incompatible module file

[Sean Silva via cfe-commits]

On Fri, Oct 16, 2015 at 6:41 PM, Richard Smith 
wrote:

> On Fri, Oct 16, 2015 at 6:30 PM, Sean Silva  wrote:
>
>> On Fri, Oct 16, 2015 at 6:26 PM, Richard Smith 
>> wrote:
>>
>>> On Fri, Oct 16, 2015 at 6:25 PM, Sean Silva 
>>> wrote:
>>>
 On Fri, Oct 16, 2015 at 6:12 PM, Richard Smith 
 wrote:

> On Fri, Oct 16, 2015 at 4:43 PM, Sean Silva 
> wrote:
>
>> On Fri, Oct 16, 2015 at 4:20 PM, Richard Smith via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: rsmith
>>> Date: Fri Oct 16 18:20:19 2015
>>> New Revision: 250577
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=250577&view=rev
>>> Log:
>>> [modules] Allow the error when explicitly loading an incompatible
>>> module file
>>> via -fmodule-file= to be turned off; in that case, just include the
>>> relevant
>>> files textually. This allows module files to be unconditionally
>>> passed to all
>>> compile actions via CXXFLAGS, and to be ignored for rules that
>>> specify custom
>>> incompatible flags.
>>>
>>
>> What direction are you trying to go with this? Are you thinking
>> something like having CMake build a bunch of modules up front?
>>
>
> That's certainly one thing you can do with this. Another is that you
> can make cmake automatically and explicitly build a module for each
> library, and then provide that for all the dependencies of that library,
>

 How does CMake know which headers are part of which library?
 Strategically named top-level modules in the module map?

>>>
>>> The idea would be for CMake to generate the module map itself based on
>>> the build rules.
>>>
>>
>> How would it know which headers to include? Do our ADDITIONAL_HEADER_DIRS
>> things in our CMakeLists.txt have enough information for this?
>>
>
> Some additional information may need to be added to the CMakeLists to
> enable this. Some build systems already model the headers for a library,
> and so already have the requisite information.
>

Yeah, I was wondering whether you were diving into doing that :) Any way
you could import this info from the bazel rules you guys already have?

-- Sean Silva


>
>
>> -- Sean Silva
>>
>>
>>>
>>>
 -- Sean Silva


> with an (error-by-default) warning in the case where the downstream
> library specifies incompatible compilation flags. You can use this warning
> flag to turn off the error so you can make progress before you get around
> to fixing all the incompatible flags.
>
>
>> If that's the case, it would be nice to explain what caused the
>> mismatch, so that the user can look into rectifying it. Otherwise this
>> warning is not directly actionable. The existing diagnostics seemed
>> alright. Demoting them to "error: {{.*}} configuration mismatch" seems 
>> like
>> a regression.
>>
>
> I agree, it is a regression, and fixing it is high on my list of
> priorities (sorry for not mentioning that in the commit message).
>
> -- Sean Silva
>>
>>
>>>
>>> Modified:
>>> cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
>>> cfe/trunk/lib/Frontend/CompilerInstance.cpp
>>> cfe/trunk/test/Modules/merge-target-features.cpp
>>>
>>> Modified: cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td?rev=250577&r1=250576&r2=250577&view=diff
>>>
>>> ==
>>> --- cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
>>> (original)
>>> +++ cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td Fri Oct
>>> 16 18:20:19 2015
>>> @@ -172,6 +172,9 @@ def warn_incompatible_analyzer_plugin_ap
>>>  def note_incompatible_analyzer_plugin_api : Note<
>>>  "current API version is '%0', but plugin was compiled with
>>> version '%1'">;
>>>
>>> +def warn_module_config_mismatch : Warning<
>>> +  "module file %0 cannot be loaded due to a configuration mismatch
>>> with the current "
>>> +  "compilation">,
>>> InGroup>, DefaultError;
>>>  def err_module_map_not_found : Error<"module map file '%0' not
>>> found">,
>>>DefaultFatal;
>>>  def err_missing_module_name : Error<
>>>
>>> Modified: cfe/trunk/lib/Frontend/CompilerInstance.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/CompilerInstance.cpp?rev=250577&r1=250576&r2=250577&view=diff
>>>
>>> ==
>>> --- cfe/trunk/lib/Frontend/CompilerInstance.cpp (original)
>>> +++ cfe/trunk/lib/Frontend/CompilerInstance.cpp Fri Oct 16 18:20:19
>>> 2015
>>> @@ -1335,15 +1335,24 @@ bool CompilerInstance::loadModuleFi

Re: r250577 - [modules] Allow the error when explicitly loading an incompatible module file

[Sean Silva via cfe-commits]

On Mon, Oct 19, 2015 at 2:10 AM, Manuel Klimek  wrote:

> On Sat, Oct 17, 2015 at 3:41 AM Richard Smith via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> On Fri, Oct 16, 2015 at 6:30 PM, Sean Silva 
>> wrote:
>>
>>> On Fri, Oct 16, 2015 at 6:26 PM, Richard Smith 
>>> wrote:
>>>
 On Fri, Oct 16, 2015 at 6:25 PM, Sean Silva 
 wrote:

> On Fri, Oct 16, 2015 at 6:12 PM, Richard Smith 
> wrote:
>
>> On Fri, Oct 16, 2015 at 4:43 PM, Sean Silva 
>> wrote:
>>
>>> On Fri, Oct 16, 2015 at 4:20 PM, Richard Smith via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 Author: rsmith
 Date: Fri Oct 16 18:20:19 2015
 New Revision: 250577

 URL: http://llvm.org/viewvc/llvm-project?rev=250577&view=rev
 Log:
 [modules] Allow the error when explicitly loading an incompatible
 module file
 via -fmodule-file= to be turned off; in that case, just include the
 relevant
 files textually. This allows module files to be unconditionally
 passed to all
 compile actions via CXXFLAGS, and to be ignored for rules that
 specify custom
 incompatible flags.

>>>
>>> What direction are you trying to go with this? Are you thinking
>>> something like having CMake build a bunch of modules up front?
>>>
>>
>> That's certainly one thing you can do with this. Another is that you
>> can make cmake automatically and explicitly build a module for each
>> library, and then provide that for all the dependencies of that library,
>>
>
> How does CMake know which headers are part of which library?
> Strategically named top-level modules in the module map?
>

 The idea would be for CMake to generate the module map itself based on
 the build rules.

>>>
>>> How would it know which headers to include? Do
>>> our ADDITIONAL_HEADER_DIRS things in our CMakeLists.txt have enough
>>> information for this?
>>>
>>
>> Some additional information may need to be added to the CMakeLists to
>> enable this. Some build systems already model the headers for a library,
>> and so already have the requisite information.
>>
>
> CMake supports specifying headers for libraries (mainly used for MS VS).
> If we need this for modules, we'll probably need to update our build rules
> (which will probably make sense anyway, for a better experience for VS
> users ;)
>

Nice.

Brad, do you have any idea how hard it would be to get cmake to generate
clang module map files and add explicit module build steps? Basically, the
requirements (off the top of my head) are:
- for each library, generate a module map which is essentially just a list
of the headers in that library (it's not just a flat list, but that's the
gist of it).
- for each module map, add a build step that invokes clang on it to say
"build the module corresponding to this module map" (it's basically
`clang++ path/to/foo.modulemap -o foo.pcm` with a little bit of fluff
around it). There is also a dependency from foo.pcm on each of the
libraries that library "foo" depends on.
- for each library $Dep that library $Lib depends on, add $Dep's .pcm file
as a dependency of the .o build steps for $Lib. $Dep's .pcm file also needs
to be passed on the command line of the .o build steps for $Lib.

It seems like similar requirements are going to be common in the
standardized modules feature (except for the module map I think? Richard?).
Basically, in order to avoid redundantly parsing textual headers, you need
to run a build step on headers that turns them into some form that can be
processed more efficiently than just parsing it. E.g. the build step on
slide 36 of this cppcon presentation about the Microsoft experimental
modules implementation https://www.youtube.com/watch?v=RwdQA0pGWa4 (slides:
https://goo.gl/t4Eg89 ).

Let me know if there is anything I can do to help (up to and including
patches, but I'll need pointers and possibly some hand-holding as I'm
unfamiliar with the CMake language and CMake codebase).

There's also some issues of detecting if the host clang is new enough that
we want to use its modules feature and also the issue of detecting
modularized system headers if available, but we can hammer those things out
as we run into them.

Manuel, I heard through the grape vine that you were the one that
implemented the explicit modules stuff for bazel? Did I miss anything in my
list above?

Richard, are there any blockers to exposing a driver flag for explicit
modules?

-- Sean Silva


>
>
>>
>>
>>> -- Sean Silva
>>>
>>>


> -- Sean Silva
>
>
>> with an (error-by-default) warning in the case where the downstream
>> library specifies incompatible compilation flags. You can use this 
>> warning
>> flag to turn off the error so you can make progress before you get around
>> to fixing all the incompatible flags.
>>
>>
>>

Re: r250577 - [modules] Allow the error when explicitly loading an incompatible module file

[Sean Silva via cfe-commits]

On Tue, Oct 20, 2015 at 1:38 AM, Manuel Klimek  wrote:

> On Tue, Oct 20, 2015 at 5:52 AM Sean Silva  wrote:
>
>> On Mon, Oct 19, 2015 at 2:10 AM, Manuel Klimek  wrote:
>>
>>> On Sat, Oct 17, 2015 at 3:41 AM Richard Smith via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 On Fri, Oct 16, 2015 at 6:30 PM, Sean Silva 
 wrote:

> On Fri, Oct 16, 2015 at 6:26 PM, Richard Smith 
> wrote:
>
>> On Fri, Oct 16, 2015 at 6:25 PM, Sean Silva 
>> wrote:
>>
>>> On Fri, Oct 16, 2015 at 6:12 PM, Richard Smith <
>>> rich...@metafoo.co.uk> wrote:
>>>
 On Fri, Oct 16, 2015 at 4:43 PM, Sean Silva 
 wrote:

> On Fri, Oct 16, 2015 at 4:20 PM, Richard Smith via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: rsmith
>> Date: Fri Oct 16 18:20:19 2015
>> New Revision: 250577
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=250577&view=rev
>> Log:
>> [modules] Allow the error when explicitly loading an incompatible
>> module file
>> via -fmodule-file= to be turned off; in that case, just include
>> the relevant
>> files textually. This allows module files to be unconditionally
>> passed to all
>> compile actions via CXXFLAGS, and to be ignored for rules that
>> specify custom
>> incompatible flags.
>>
>
> What direction are you trying to go with this? Are you thinking
> something like having CMake build a bunch of modules up front?
>

 That's certainly one thing you can do with this. Another is that
 you can make cmake automatically and explicitly build a module for each
 library, and then provide that for all the dependencies of that 
 library,

>>>
>>> How does CMake know which headers are part of which library?
>>> Strategically named top-level modules in the module map?
>>>
>>
>> The idea would be for CMake to generate the module map itself based
>> on the build rules.
>>
>
> How would it know which headers to include? Do
> our ADDITIONAL_HEADER_DIRS things in our CMakeLists.txt have enough
> information for this?
>

 Some additional information may need to be added to the CMakeLists to
 enable this. Some build systems already model the headers for a library,
 and so already have the requisite information.

>>>
>>> CMake supports specifying headers for libraries (mainly used for MS VS).
>>> If we need this for modules, we'll probably need to update our build rules
>>> (which will probably make sense anyway, for a better experience for VS
>>> users ;)
>>>
>>
>> Nice.
>>
>> Brad, do you have any idea how hard it would be to get cmake to generate
>> clang module map files and add explicit module build steps? Basically, the
>> requirements (off the top of my head) are:
>> - for each library, generate a module map which is essentially just a
>> list of the headers in that library (it's not just a flat list, but that's
>> the gist of it).
>> - for each module map, add a build step that invokes clang on it to say
>> "build the module corresponding to this module map" (it's basically
>> `clang++ path/to/foo.modulemap -o foo.pcm` with a little bit of fluff
>> around it). There is also a dependency from foo.pcm on each of the
>> libraries that library "foo" depends on.
>> - for each library $Dep that library $Lib depends on, add $Dep's .pcm
>> file as a dependency of the .o build steps for $Lib. $Dep's .pcm file also
>> needs to be passed on the command line of the .o build steps for $Lib.
>>
>> It seems like similar requirements are going to be common in the
>> standardized modules feature (except for the module map I think? Richard?).
>> Basically, in order to avoid redundantly parsing textual headers, you need
>> to run a build step on headers that turns them into some form that can be
>> processed more efficiently than just parsing it. E.g. the build step on
>> slide 36 of this cppcon presentation about the Microsoft experimental
>> modules implementation https://www.youtube.com/watch?v=RwdQA0pGWa4
>> (slides: https://goo.gl/t4Eg89 ).
>>
>> Let me know if there is anything I can do to help (up to and including
>> patches, but I'll need pointers and possibly some hand-holding as I'm
>> unfamiliar with the CMake language and CMake codebase).
>>
>> There's also some issues of detecting if the host clang is new enough
>> that we want to use its modules feature and also the issue of detecting
>> modularized system headers if available, but we can hammer those things out
>> as we run into them.
>>
>> Manuel, I heard through the grape vine that you were the one that
>> implemented the explicit modules stuff for bazel? Did I miss anything in my
>> list above?
>>
>
> I think that's about right. We also embed the module maps into the
> modules, b

Re: r250577 - [modules] Allow the error when explicitly loading an incompatible module file

[Sean Silva via cfe-commits]

On Tue, Oct 20, 2015 at 6:45 AM, Manuel Klimek  wrote:

> On Tue, Oct 20, 2015 at 3:38 PM Brad King  wrote:
>
>> On 10/20/2015 04:38 AM, Manuel Klimek wrote:
>> > On Tue, Oct 20, 2015 at 5:52 AM Sean Silva wrote:
>> >> get cmake to generate clang module map files and add explicit module
>> build steps?
>> >
>> > I have some experience hacking on cmake, and from my experience I think
>> > this shouldn't be too hard to get working (mainly work ;)
>>
>> I agree this shouldn't be too hard on the CMake side.  Manuel, please
>> come over to the cmake dev list to raise the design discussion.  Then
>> we can guide your implementation work.
>
>
> I think Sean volunteered :) (but please keep me cc'ed if you start
> discussing this on cmake-dev)
>
>
>>   The main design challenges
>> I foresee are:
>>
>> 1. Deciding how this behavior should be activated for a project by
>>its code and/or by the user.
>>
>> 2. Selection of the proper set of headers if it is not exactly the set
>>listed in the target for some reason.  Might this ever by more
>>granular than a whole library target?
>>
>
> I don't think so.
> Main concerns are:
> 1. we need to be able to say something is a "textual" header; those are
> still needed; we can do that by calling them .inc, or by putting something
> into cmake to specify textual headers (that's what we do in our build
> system)
> 2. for the "slow rollout" case we use per-header submodules; but that's
> more an implementation detail than anything else, I think
>

What is the "slow rollout" case?

-- Sean Silva


>
>
>>
>> 3. Finding the right place during the CMake generation process to add
>>the rules for this.
>>
>> We already detect the Clang compiler version so deciding if it is
>> new enough to support the feature should not be hard.
>>
>> Thanks,
>> -Brad
>>
>>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r250577 - [modules] Allow the error when explicitly loading an incompatible module file

[Sean Silva via cfe-commits]

On Tue, Oct 20, 2015 at 1:52 AM, Manuel Klimek  wrote:

> On Tue, Oct 20, 2015 at 10:41 AM Sean Silva  wrote:
>
>> On Tue, Oct 20, 2015 at 1:38 AM, Manuel Klimek  wrote:
>>
>>> On Tue, Oct 20, 2015 at 5:52 AM Sean Silva 
>>> wrote:
>>>
 On Mon, Oct 19, 2015 at 2:10 AM, Manuel Klimek 
 wrote:

> On Sat, Oct 17, 2015 at 3:41 AM Richard Smith via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> On Fri, Oct 16, 2015 at 6:30 PM, Sean Silva 
>> wrote:
>>
>>> On Fri, Oct 16, 2015 at 6:26 PM, Richard Smith <
>>> rich...@metafoo.co.uk> wrote:
>>>
 On Fri, Oct 16, 2015 at 6:25 PM, Sean Silva 
 wrote:

> On Fri, Oct 16, 2015 at 6:12 PM, Richard Smith <
> rich...@metafoo.co.uk> wrote:
>
>> On Fri, Oct 16, 2015 at 4:43 PM, Sean Silva <
>> chisophu...@gmail.com> wrote:
>>
>>> On Fri, Oct 16, 2015 at 4:20 PM, Richard Smith via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 Author: rsmith
 Date: Fri Oct 16 18:20:19 2015
 New Revision: 250577

 URL: http://llvm.org/viewvc/llvm-project?rev=250577&view=rev
 Log:
 [modules] Allow the error when explicitly loading an
 incompatible module file
 via -fmodule-file= to be turned off; in that case, just include
 the relevant
 files textually. This allows module files to be unconditionally
 passed to all
 compile actions via CXXFLAGS, and to be ignored for rules that
 specify custom
 incompatible flags.

>>>
>>> What direction are you trying to go with this? Are you thinking
>>> something like having CMake build a bunch of modules up front?
>>>
>>
>> That's certainly one thing you can do with this. Another is that
>> you can make cmake automatically and explicitly build a module for 
>> each
>> library, and then provide that for all the dependencies of that 
>> library,
>>
>
> How does CMake know which headers are part of which library?
> Strategically named top-level modules in the module map?
>

 The idea would be for CMake to generate the module map itself based
 on the build rules.

>>>
>>> How would it know which headers to include? Do
>>> our ADDITIONAL_HEADER_DIRS things in our CMakeLists.txt have enough
>>> information for this?
>>>
>>
>> Some additional information may need to be added to the CMakeLists to
>> enable this. Some build systems already model the headers for a library,
>> and so already have the requisite information.
>>
>
> CMake supports specifying headers for libraries (mainly used for MS
> VS). If we need this for modules, we'll probably need to update our build
> rules (which will probably make sense anyway, for a better experience for
> VS users ;)
>

 Nice.

 Brad, do you have any idea how hard it would be to get cmake to
 generate clang module map files and add explicit module build steps?
 Basically, the requirements (off the top of my head) are:
 - for each library, generate a module map which is essentially just a
 list of the headers in that library (it's not just a flat list, but that's
 the gist of it).
 - for each module map, add a build step that invokes clang on it to say
 "build the module corresponding to this module map" (it's basically
 `clang++ path/to/foo.modulemap -o foo.pcm` with a little bit of fluff
 around it). There is also a dependency from foo.pcm on each of the
 libraries that library "foo" depends on.
 - for each library $Dep that library $Lib depends on, add $Dep's .pcm
 file as a dependency of the .o build steps for $Lib. $Dep's .pcm file also
 needs to be passed on the command line of the .o build steps for $Lib.

 It seems like similar requirements are going to be common in the
 standardized modules feature (except for the module map I think? Richard?).
 Basically, in order to avoid redundantly parsing textual headers, you need
 to run a build step on headers that turns them into some form that can be
 processed more efficiently than just parsing it. E.g. the build step on
 slide 36 of this cppcon presentation about the Microsoft experimental
 modules implementation https://www.youtube.com/watch?v=RwdQA0pGWa4
 (slides: https://goo.gl/t4Eg89 ).

 Let me know if there is anything I can do to help (up to and including
 patches, but I'll need pointers and possibly some hand-holding as I'm
 unfamiliar with the CMake language and CMake codebase).

 There's also some issues of detecting if the host clang is new enough
 that we want to use its m

Re: r250577 - [modules] Allow the error when explicitly loading an incompatible module file

[Sean Silva via cfe-commits]

On Sun, Nov 1, 2015 at 10:20 AM, Manuel Klimek  wrote:

>
>
> On Fri, Oct 23, 2015 at 9:31 PM Sean Silva  wrote:
>
>> On Tue, Oct 20, 2015 at 1:52 AM, Manuel Klimek  wrote:
>>
>>> On Tue, Oct 20, 2015 at 10:41 AM Sean Silva 
>>> wrote:
>>>
 On Tue, Oct 20, 2015 at 1:38 AM, Manuel Klimek 
 wrote:

> On Tue, Oct 20, 2015 at 5:52 AM Sean Silva 
> wrote:
>
>> On Mon, Oct 19, 2015 at 2:10 AM, Manuel Klimek 
>> wrote:
>>
>>> On Sat, Oct 17, 2015 at 3:41 AM Richard Smith via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 On Fri, Oct 16, 2015 at 6:30 PM, Sean Silva 
 wrote:

> On Fri, Oct 16, 2015 at 6:26 PM, Richard Smith <
> rich...@metafoo.co.uk> wrote:
>
>> On Fri, Oct 16, 2015 at 6:25 PM, Sean Silva <
>> chisophu...@gmail.com> wrote:
>>
>>> On Fri, Oct 16, 2015 at 6:12 PM, Richard Smith <
>>> rich...@metafoo.co.uk> wrote:
>>>
 On Fri, Oct 16, 2015 at 4:43 PM, Sean Silva <
 chisophu...@gmail.com> wrote:

> On Fri, Oct 16, 2015 at 4:20 PM, Richard Smith via cfe-commits
>  wrote:
>
>> Author: rsmith
>> Date: Fri Oct 16 18:20:19 2015
>> New Revision: 250577
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=250577&view=rev
>> Log:
>> [modules] Allow the error when explicitly loading an
>> incompatible module file
>> via -fmodule-file= to be turned off; in that case, just
>> include the relevant
>> files textually. This allows module files to be
>> unconditionally passed to all
>> compile actions via CXXFLAGS, and to be ignored for rules
>> that specify custom
>> incompatible flags.
>>
>
> What direction are you trying to go with this? Are you
> thinking something like having CMake build a bunch of modules up 
> front?
>

 That's certainly one thing you can do with this. Another is
 that you can make cmake automatically and explicitly build a 
 module for
 each library, and then provide that for all the dependencies of 
 that
 library,

>>>
>>> How does CMake know which headers are part of which library?
>>> Strategically named top-level modules in the module map?
>>>
>>
>> The idea would be for CMake to generate the module map itself
>> based on the build rules.
>>
>
> How would it know which headers to include? Do
> our ADDITIONAL_HEADER_DIRS things in our CMakeLists.txt have enough
> information for this?
>

 Some additional information may need to be added to the CMakeLists
 to enable this. Some build systems already model the headers for a 
 library,
 and so already have the requisite information.

>>>
>>> CMake supports specifying headers for libraries (mainly used for MS
>>> VS). If we need this for modules, we'll probably need to update our 
>>> build
>>> rules (which will probably make sense anyway, for a better experience 
>>> for
>>> VS users ;)
>>>
>>
>> Nice.
>>
>> Brad, do you have any idea how hard it would be to get cmake to
>> generate clang module map files and add explicit module build steps?
>> Basically, the requirements (off the top of my head) are:
>> - for each library, generate a module map which is essentially just a
>> list of the headers in that library (it's not just a flat list, but 
>> that's
>> the gist of it).
>> - for each module map, add a build step that invokes clang on it to
>> say "build the module corresponding to this module map" (it's basically
>> `clang++ path/to/foo.modulemap -o foo.pcm` with a little bit of fluff
>> around it). There is also a dependency from foo.pcm on each of the
>> libraries that library "foo" depends on.
>> - for each library $Dep that library $Lib depends on, add $Dep's .pcm
>> file as a dependency of the .o build steps for $Lib. $Dep's .pcm file 
>> also
>> needs to be passed on the command line of the .o build steps for $Lib.
>>
>> It seems like similar requirements are going to be common in the
>> standardized modules feature (except for the module map I think? 
>> Richard?).
>> Basically, in order to avoid redundantly parsing textual headers, you 
>> need
>> to run a build step on headers that turns them into some form that can be
>> processed more efficiently than just parsing it. E.g. the build step on
>> slide 36 of this cppcon presentation about the Microsoft experimental
>> modules

Re: r250577 - [modules] Allow the error when explicitly loading an incompatible module file

[Sean Silva via cfe-commits]

On Wed, Nov 4, 2015 at 1:07 PM, Richard Smith  wrote:

> On Sun, Nov 1, 2015 at 10:20 AM, Manuel Klimek  wrote:
>
>> On Fri, Oct 23, 2015 at 9:31 PM Sean Silva  wrote:
>>
>>> On Tue, Oct 20, 2015 at 1:52 AM, Manuel Klimek 
>>> wrote:
>>>
 On Tue, Oct 20, 2015 at 10:41 AM Sean Silva 
 wrote:

> On Tue, Oct 20, 2015 at 1:38 AM, Manuel Klimek 
> wrote:
>
>> On Tue, Oct 20, 2015 at 5:52 AM Sean Silva 
>> wrote:
>>
>>> On Mon, Oct 19, 2015 at 2:10 AM, Manuel Klimek 
>>> wrote:
>>>
 On Sat, Oct 17, 2015 at 3:41 AM Richard Smith via cfe-commits <
 cfe-commits@lists.llvm.org> wrote:

> On Fri, Oct 16, 2015 at 6:30 PM, Sean Silva  > wrote:
>
>> On Fri, Oct 16, 2015 at 6:26 PM, Richard Smith <
>> rich...@metafoo.co.uk> wrote:
>>
>>> On Fri, Oct 16, 2015 at 6:25 PM, Sean Silva <
>>> chisophu...@gmail.com> wrote:
>>>
 On Fri, Oct 16, 2015 at 6:12 PM, Richard Smith <
 rich...@metafoo.co.uk> wrote:

> On Fri, Oct 16, 2015 at 4:43 PM, Sean Silva <
> chisophu...@gmail.com> wrote:
>
>> On Fri, Oct 16, 2015 at 4:20 PM, Richard Smith via
>> cfe-commits  wrote:
>>
>>> Author: rsmith
>>> Date: Fri Oct 16 18:20:19 2015
>>> New Revision: 250577
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=250577&view=rev
>>> Log:
>>> [modules] Allow the error when explicitly loading an
>>> incompatible module file
>>> via -fmodule-file= to be turned off; in that case, just
>>> include the relevant
>>> files textually. This allows module files to be
>>> unconditionally passed to all
>>> compile actions via CXXFLAGS, and to be ignored for rules
>>> that specify custom
>>> incompatible flags.
>>>
>>
>> What direction are you trying to go with this? Are you
>> thinking something like having CMake build a bunch of modules up 
>> front?
>>
>
> That's certainly one thing you can do with this. Another is
> that you can make cmake automatically and explicitly build a 
> module for
> each library, and then provide that for all the dependencies of 
> that
> library,
>

 How does CMake know which headers are part of which library?
 Strategically named top-level modules in the module map?

>>>
>>> The idea would be for CMake to generate the module map itself
>>> based on the build rules.
>>>
>>
>> How would it know which headers to include? Do
>> our ADDITIONAL_HEADER_DIRS things in our CMakeLists.txt have enough
>> information for this?
>>
>
> Some additional information may need to be added to the CMakeLists
> to enable this. Some build systems already model the headers for a 
> library,
> and so already have the requisite information.
>

 CMake supports specifying headers for libraries (mainly used for MS
 VS). If we need this for modules, we'll probably need to update our 
 build
 rules (which will probably make sense anyway, for a better experience 
 for
 VS users ;)

>>>
>>> Nice.
>>>
>>> Brad, do you have any idea how hard it would be to get cmake to
>>> generate clang module map files and add explicit module build steps?
>>> Basically, the requirements (off the top of my head) are:
>>> - for each library, generate a module map which is essentially just
>>> a list of the headers in that library (it's not just a flat list, but
>>> that's the gist of it).
>>> - for each module map, add a build step that invokes clang on it to
>>> say "build the module corresponding to this module map" (it's basically
>>> `clang++ path/to/foo.modulemap -o foo.pcm` with a little bit of fluff
>>> around it). There is also a dependency from foo.pcm on each of the
>>> libraries that library "foo" depends on.
>>> - for each library $Dep that library $Lib depends on, add $Dep's
>>> .pcm file as a dependency of the .o build steps for $Lib. $Dep's .pcm 
>>> file
>>> also needs to be passed on the command line of the .o build steps for 
>>> $Lib.
>>>
>>> It seems like similar requirements are going to be common in the
>>> standardized modules feature (except for the module map I think? 
>>> Richard?).
>>> Basically, in order to avoid redundantly parsing textual headers, you 
>>> need
>>> to run a build step on headers that turns them into some form that 

Re: r250577 - [modules] Allow the error when explicitly loading an incompatible module file

[Sean Silva via cfe-commits]

On Thu, Nov 5, 2015 at 1:12 PM, Richard Smith  wrote:

> On Wed, Nov 4, 2015 at 7:14 PM, Sean Silva via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> On Wed, Nov 4, 2015 at 1:07 PM, Richard Smith 
>> wrote:
>>
>>> On Sun, Nov 1, 2015 at 10:20 AM, Manuel Klimek 
>>> wrote:
>>>
>>>> On Fri, Oct 23, 2015 at 9:31 PM Sean Silva 
>>>> wrote:
>>>>
>>>>> On Tue, Oct 20, 2015 at 1:52 AM, Manuel Klimek 
>>>>> wrote:
>>>>>
>>>>>> On Tue, Oct 20, 2015 at 10:41 AM Sean Silva 
>>>>>> wrote:
>>>>>>
>>>>>>> On Tue, Oct 20, 2015 at 1:38 AM, Manuel Klimek 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On Tue, Oct 20, 2015 at 5:52 AM Sean Silva 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On Mon, Oct 19, 2015 at 2:10 AM, Manuel Klimek 
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> On Sat, Oct 17, 2015 at 3:41 AM Richard Smith via cfe-commits <
>>>>>>>>>> cfe-commits@lists.llvm.org> wrote:
>>>>>>>>>>
>>>>>>>>>>> On Fri, Oct 16, 2015 at 6:30 PM, Sean Silva <
>>>>>>>>>>> chisophu...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Oct 16, 2015 at 6:26 PM, Richard Smith <
>>>>>>>>>>>> rich...@metafoo.co.uk> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, Oct 16, 2015 at 6:25 PM, Sean Silva <
>>>>>>>>>>>>> chisophu...@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, Oct 16, 2015 at 6:12 PM, Richard Smith <
>>>>>>>>>>>>>> rich...@metafoo.co.uk> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Fri, Oct 16, 2015 at 4:43 PM, Sean Silva <
>>>>>>>>>>>>>>> chisophu...@gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Fri, Oct 16, 2015 at 4:20 PM, Richard Smith via
>>>>>>>>>>>>>>>> cfe-commits  wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Author: rsmith
>>>>>>>>>>>>>>>>> Date: Fri Oct 16 18:20:19 2015
>>>>>>>>>>>>>>>>> New Revision: 250577
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> URL:
>>>>>>>>>>>>>>>>> http://llvm.org/viewvc/llvm-project?rev=250577&view=rev
>>>>>>>>>>>>>>>>> Log:
>>>>>>>>>>>>>>>>> [modules] Allow the error when explicitly loading an
>>>>>>>>>>>>>>>>> incompatible module file
>>>>>>>>>>>>>>>>> via -fmodule-file= to be turned off; in that case, just
>>>>>>>>>>>>>>>>> include the relevant
>>>>>>>>>>>>>>>>> files textually. This allows module files to be
>>>>>>>>>>>>>>>>> unconditionally passed to all
>>>>>>>>>>>>>>>>> compile actions via CXXFLAGS, and to be ignored for rules
>>>>>>>>>>>>>>>>> that specify custom
>>>>>>>>>>>>>>>>> incompatible flags.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> What direction are you trying to go with this? Are you
>>>>>>>>>>>>>>>> thinking something like having CMake build a bunch of modules 
>>>>>>>>>>>>>>>> up front?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>

Re: [PATCH] D21954: [PM] Add some internal options for testing out the new PM.

[Sean Silva via cfe-commits]

silvas updated this revision to Diff 64420.
silvas added a comment.

Rebase after r275507.


https://reviews.llvm.org/D21954

Files:
  include/clang/Driver/CC1Options.td
  include/clang/Frontend/CodeGenOptions.h
  lib/CodeGen/BackendUtil.cpp
  lib/CodeGen/CMakeLists.txt
  lib/Frontend/CompilerInvocation.cpp
  test/CodeGen/middle-end-passes.c

Index: test/CodeGen/middle-end-passes.c
===
--- /dev/null
+++ test/CodeGen/middle-end-passes.c
@@ -0,0 +1,26 @@
+// Check that passes get run.
+
+// RUN: %clang_cc1 %s -emit-llvm -o /dev/null -middle-end-passes=mem2reg,aa-eval 2>&1 | FileCheck %s --check-prefix=NO-AA
+
+// NO-AA: = Alias Analysis Evaluator Report =
+// NO-AA: 0 must alias responses
+
+// RUN: %clang_cc1 %s -emit-llvm -o /dev/null -middle-end-passes=mem2reg,aa-eval -middle-end-aa-pipeline=basic-aa 2>&1 | FileCheck %s --check-prefix=WITH-AA
+
+// WITH-AA: = Alias Analysis Evaluator Report =
+// WITH-AA: 1 must alias responses
+
+
+// The actual output with -flto or -emit-llvm is generated by running a
+// pass in the old PM. Verify that that we still get output.
+
+// RUN: %clang -flto -c %s -o - -Xclang -middle-end-passes=mem2reg 2>&1 | opt -S | FileCheck %s --check-prefix=OUTPUT-IS-GENERATED
+// RUN: %clang -emit-llvm -S %s -o - -Xclang -middle-end-passes=mem2reg 2>&1 | FileCheck %s --check-prefix=OUTPUT-IS-GENERATED
+
+// OUTPUT-IS-GENERATED: @foo
+
+int foo(int *x) {
+  int *y = x + 1;
+  int *z = y - 1;
+  return *x + *z;
+}
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -845,6 +845,11 @@
   Opts.EmitCheckPathComponentsToStrip = getLastArgIntValue(
   Args, OPT_fsanitize_undefined_strip_path_components_EQ, 0, Diags);
 
+  if (Arg *A = Args.getLastArg(OPT_middle_end_passes_EQ))
+Opts.MiddleEndPasses = A->getValue();
+  if (Arg *A = Args.getLastArg(OPT_middle_end_aa_pipeline_EQ))
+Opts.MiddleEndAAPipeline = A->getValue();
+
   return Success;
 }
 
Index: lib/CodeGen/CMakeLists.txt
===
--- lib/CodeGen/CMakeLists.txt
+++ lib/CodeGen/CMakeLists.txt
@@ -12,6 +12,7 @@
   MC
   ObjCARCOpts
   Object
+  Passes
   ProfileData
   ScalarOpts
   Support
Index: lib/CodeGen/BackendUtil.cpp
===
--- lib/CodeGen/BackendUtil.cpp
+++ lib/CodeGen/BackendUtil.cpp
@@ -31,6 +31,7 @@
 #include "llvm/IR/Verifier.h"
 #include "llvm/MC/SubtargetFeature.h"
 #include "llvm/Object/ModuleSummaryIndexObjectFile.h"
+#include "llvm/Passes/PassBuilder.h"
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/PrettyStackTrace.h"
 #include "llvm/Support/TargetRegistry.h"
@@ -643,6 +644,43 @@
   return true;
 }
 
+static void runMiddleEndPasses(Module &M, TargetMachine *TM, StringRef Passes,
+   StringRef AAPipeline) {
+  // This is a really low-level internal developer option.
+  // Use report_fatal_error if anything goes wrong.
+
+  PassBuilder PB(TM);
+  AAManager AA;
+  if (!PB.parseAAPipeline(AA, AAPipeline))
+report_fatal_error("Unable to parse AA pipeline description: " +
+   AAPipeline);
+
+  LoopAnalysisManager LAM;
+  FunctionAnalysisManager FAM;
+  CGSCCAnalysisManager CGAM;
+  ModuleAnalysisManager MAM;
+
+  // Register the AA manager first so that our version is the one used.
+  FAM.registerPass([&] { return std::move(AA); });
+
+  // Register all the basic analyses with the managers.
+  PB.registerModuleAnalyses(MAM);
+  PB.registerCGSCCAnalyses(CGAM);
+  PB.registerFunctionAnalyses(FAM);
+  PB.registerLoopAnalyses(LAM);
+  PB.crossRegisterProxies(LAM, FAM, CGAM, MAM);
+
+  ModulePassManager MPM;
+  MPM.addPass(VerifierPass());
+
+  // Now, add all the passes we've been requested to.
+  if (!PB.parsePassPipeline(MPM, Passes))
+report_fatal_error("Unable to parse pass pipeline description: " + Passes);
+
+  MPM.addPass(VerifierPass());
+  MPM.run(M, MAM);
+}
+
 void EmitAssemblyHelper::EmitAssembly(BackendAction Action,
   std::unique_ptr OS) {
   TimeRegion Region(llvm::TimePassesIsEnabled ? &CodeGenerationTime : nullptr);
@@ -687,7 +725,11 @@
   PerFunctionPasses.add(
   createTargetTransformInfoWrapperPass(getTargetIRAnalysis()));
 
-  CreatePasses(PerModulePasses, PerFunctionPasses, ModuleSummary.get());
+  bool UseCustomMiddleEndPasses = !CodeGenOpts.MiddleEndPasses.empty();
+  // If we are going to use a custom middle-end pass pipeline, don't add
+  // any of the usual passes.
+  if (!UseCustomMiddleEndPasses)
+CreatePasses(PerModulePasses, PerFunctionPasses, ModuleSummary.get());
 
   legacy::PassManager CodeGenPasses;
   CodeGenPasses.add(
@@ -716,6 +758,18 @@
   // Before executing passes, print the final values of the LLVM options.
   cl::PrintOpti

Re: [PATCH] D21823: [Driver] Add flags for enabling both types of PGO Instrumentation

[Sean Silva via cfe-commits]

On Tue, Jul 19, 2016 at 5:01 PM, Xinliang David Li 
wrote:

> The new behavior works really well. There is one follow up change I would
> like to discuss.
>
> The EQ form of the option -fprofile-generate= takes a directory name as
> the argument instead of the filename. Currently the compiler will create a
> default 'default.profraw' name for it, but this means, online merging won't
> be available unless environment variable is also used, which is not
> convenient.  I propose we change the default behavior to enable profile
> online merging (i.e., use default_%m.profraw as the default name) for the
> following reasons:
>
> 1) There is almost no downside enabling profiling merging by default --
> new capability is enabled with no lost functionality
> 2) WIth profile merging enabled for instrumented programs with
> instrumented shared libs, each lib will dump its own profile data in the
> same dir, but users of -fprofile-generate= option usually do not care about
> what/how many raw profile names are in the directory (note that GCC's
> behavior is one profile per object module), they just pack up the while
> directory. llvm-profdata also support merging (for indexed profile) with
> input-list-file option.
> 3) GCC's has online merging support, so having online merging by default
> with this option matches up better the claim that it is a GCC compatible
> option.
>
> What do you think?
>
> thanks,
>
> David
>

This SGTM.

May only slight concern is making sure that tests which use globbing (which
`REQUIRES: shell`) to deal with %m expansions are kept separate if possible
-- otherwise windows (or windows-hosted, e.g. PS4) test coverage suffers.
Most of our tests use `env LLVM_PROFILE_FILE=` anyway so this hopefully
doesn't affect too many tests.

-- Sean Silva


>
>
>
> On Sat, Jul 9, 2016 at 4:39 PM, Sean Silva  wrote:
>
>> silvas added a comment.
>>
>> In http://reviews.llvm.org/D21823#479418, @davidxl wrote:
>>
>> > I should have brought it up earlier, but I forgot.I think a better
>> (and simpler) proposal is to make -fprofile-generate and -fprofile-use turn
>> on IR based PGO.
>> >
>> > -fprofile-generate and -fprofile-use options were introduced by Diego
>> (cc'ed) recently for GCC option compatibility. At that time, IR based PGO
>> was not yet ready, so they were made aliases to FE instrumentation options
>> -fprofile-instr-generate and -fprofile-instr-use.Now I think it is time
>> to make it right.   The documentation only says that these two options are
>> gcc compatible options to control profile generation and use, but does not
>> specify the underlying implementation. It is also likely that Google is the
>> only user of this option. If a user using this option really want FE
>> instrumentation, there is always -fprofile-instr-generate to use.  It also
>> more likely that IR instrumentation is what user wants when using GCC
>> compatible options (as they behave more similarly).
>>
>>
>> This SGTM.
>>
>> It may cause some user confusion since there is no obvious distinction
>> between "profile generate" and "profile instr generate" from a user
>> perspective. But we can avoid that with improved documentation.
>>
>> My main concern is that the existing documentation already says that
>> -fprofile-generate behaves identically to -fprofile-instr-generate
>> http://clang.llvm.org/docs/UsersManual.html#cmdoption-fprofile-generate
>> However, I think it is reasonable to change this behavior (and of course
>> the documentation), as users of this option are likely using it for
>> compatibility with GCC and so they likely don't care about the specifics of
>> clang FEPGO.
>> We probably want to at least leave a small note in the documentation
>> regarding this change of behavior.
>>
>>
>> Repository:
>>   rL LLVM
>>
>> http://reviews.llvm.org/D21823
>>
>>
>>
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D22593: [Profile] document %h and %m

[Sean Silva via cfe-commits]

silvas added a comment.

LGTM with some small wording nits.

We may want to extend this to mention number modifier to `%m` (e.g. `%4m`). 
Perhaps it is better to leave that to more advanced documentation -- your 
experiments showed that even just 1 merge pool is quite scalable IIRC.



Comment at: docs/UsersManual.rst:1500
@@ +1499,3 @@
+   name.  When this specifier is used, the profiler runtime will substitute 
``%m``
+   with a unique integer identifier associated with the instrumented binary. 
Multiple
+   profiles dumped from different processes (running on the same or different 
hosts)

I would suggest saying `Additionally, multiple...` instead of just `Multiple` 
to highlight that this is an additional behavior that is caused by using `%m`.


Comment at: docs/UsersManual.rst:1501
@@ +1500,3 @@
+   with a unique integer identifier associated with the instrumented binary. 
Multiple
+   profiles dumped from different processes (running on the same or different 
hosts)
+   will be automatically merged by the profiler runtime during the dumping. If

You probably want to say "raw profiles" instead of just "profile" to clarify 
that this is a different sense of "merge" than `llvm-profdata merge ...` (or 
otherwise clarify).


https://reviews.llvm.org/D22593



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D22593: [Profile] document %h and %m

[Sean Silva via cfe-commits]

silvas accepted this revision.
silvas added a comment.
This revision is now accepted and ready to land.

LGTM (also, another small suggestion).



Comment at: docs/UsersManual.rst:1502
@@ +1501,3 @@
+   multiple raw profiles dumped from different processes (running on the same 
or
+   different hosts) will be automatically merged by the profiler runtime 
during the
+   dumping. If the program links in multiple instrumented shared libraries, 
each library

"running on the same or different hosts" should probably just be "that share a 
file system" to clarify that we depend on the filesystem guarantees and aren't 
doing anything else special.


https://reviews.llvm.org/D22593



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r266719 - Warn if function or variable cannot be implicitly instantiated

[Sean Silva via cfe-commits]

On Tue, Aug 9, 2016 at 9:18 AM, Serge Pavlov  wrote:

> Whether enable this warning or not should be determined by user feedback.
> The warning was implemented to help users in complicated cases that arise
> in module-enabled builds. It seems however that it makes troubles for other
> users. Based on feedback on this list I feel that it is better to make this
> message off by default. It still should be useful for people who use
> explicit instantiation, but this use case is rare, I think.
>
> Should someone approve turning the message off by default, or discussion
> here is enough?
>

I think that the feedback here is enough to turn it off by default (or
ideally to only be on by default for modules).

-- Sean Silva


>
>
> Thanks,
> --Serge
>
> 2016-08-09 20:44 GMT+07:00 Nico Weber :
>
>> With 3.9 coming around, I'd like to suggest that we pull this warning
>> from 3.9 and maybe trunk. It sounds like Sean found it only possible to
>> deploy this warning since they already had a workaround for a different
>> compiler bug (!). In Chromium, we can't enable this warning since one of
>> our (admittedly dubiously designed) template classes in a foundational
>> library requires people to have an explicit instantiation of their
>> downstream classes in a client cc file. Fixing this warning would mean
>> giving the h file in the foundational library forward declarations of all
>> clients of the template.
>>
>> The motivation for this warning was PR24425, which is something that's
>> only relevant with modules enabled. Maybe the warning should only fire with
>> modules. But as-is, the warning warns about something that isn't really a
>> problem in practice, and it's difficult to fix (and as said, fixing it has
>> few benefits). I don't think it's at the bar we have for clang warnings.
>>
>> Is there anyone who has deployed this warning successfully on a larger
>> codebase? Examples of real bugs it found?
>>
>> On Fri, May 20, 2016 at 12:14 AM, Sean Silva 
>> wrote:
>>
>>>
>>>
>>> On Thu, May 19, 2016 at 12:13 PM, Serge Pavlov 
>>> wrote:
>>>
 In this case moving implementation of `Singleton::getInstance()`
 into a .cpp file would prevent compiler from instantiation of the method
 body when it sees `Singleton::getInstance()`. In this case
 `Singleton::getInstance()` must be instantiated in some source
 file either explicitly or implicitly. If inline implementation for
 `Singleton::getInstance()` is provided in the header, where
 `Singleton` is defined, the method body is instantiated implicitly when
 it is required. But the static field `instance` referenced in the method
 still must be instantiated in some source file explicitly or implicitly. So
 from viewpoint of convenience, moving the implementation of template
 `Singleton::getInstance()` into source file does not look as more
 inflexible solution.

 Probably it is more convenient to put the template for the static
 member to header file too:

 template 
 T *Singleton::instance = nullptr;


 In this case both the method and corresponding static member are
 instantiated implicitly by compiler, no warning occurs.
 Can it be an acceptable solution?

>>>
>>> I think that is what makes the most sense in this scenario (and it
>>> simplifies things for clients of the library).
>>> Unfortunately, for the library that was producing this warning they
>>> already required clients to provide explicit instantiations in a .cpp file
>>> (they had a macro like `DEFINE_SINGLETON_INSTANCE(T)` which a user would
>>> place in a .cpp file to instantiate Singleton::instance for their type).
>>>
>>> So fixing this warning like this would have a compatibility concern.
>>>
>>> Thankfully, it seems like some compilers (not clang) have a bug in that
>>> they will emit Singleton::instance any time that Singleton is
>>> instantiated unless they have already seen an explicit instantiation
>>> declaration of Singleton::instance in a header, so this library
>>> already had (under an #if) explicit instantiations for
>>> Singleton::instance for all classes that needed it in order to work
>>> around this compiler bug. So in the end I fixed this by just enabling those
>>> ifdefs so that clang would see the Singleton::instance explicitly
>>> declared in the header.
>>> (This is sort of a strange coincidence, but it worked out nicely)
>>>
>>>
>>>

 If there is intention to limit `Singleton` to some selected types,
 explicit instantiation declaration may help. Adding the declarations like:

 extern template Foo *Singleton::instance;


 prevents from warnings.

 Or you think that the message should propose moving static member
 definition into header file as well?

>>>
>>> I'm not sure, but I think that the current diagnostics are not very
>>> actionable. Hopefully google will lead users to your description in this
>>> thread. I wish we had something like htt

Re: r278710 - Replace an obsolete company name.

[Sean Silva via cfe-commits]

You may also want to just try using the unicode character (not that it
really matters that much though).

On Mon, Aug 15, 2016 at 11:45 AM, Paul Robinson via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: probinson
> Date: Mon Aug 15 13:45:52 2016
> New Revision: 278710
>
> URL: http://llvm.org/viewvc/llvm-project?rev=278710&view=rev
> Log:
> Replace an obsolete company name.
>
> Modified:
> cfe/trunk/docs/UsersManual.rst
>
> Modified: cfe/trunk/docs/UsersManual.rst
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/
> UsersManual.rst?rev=278710&r1=278709&r2=278710&view=diff
> 
> ==
> --- cfe/trunk/docs/UsersManual.rst (original)
> +++ cfe/trunk/docs/UsersManual.rst Mon Aug 15 13:45:52 2016
> @@ -2,6 +2,8 @@
>  Clang Compiler User's Manual
>  
>
> +.. include:: 
> +
>  .. contents::
> :local:
>
> @@ -1650,7 +1652,7 @@ features. You can "tune" the debug info
>
>  .. option:: -ggdb, -glldb, -gsce
>
> -  Tune the debug info for the ``gdb``, ``lldb``, or Sony Computer
> Entertainment
> +  Tune the debug info for the ``gdb``, ``lldb``, or Sony PlayStation\
> |reg|
>debugger, respectively. Each of these options implies **-g**.
> (Therefore, if
>you want both **-gline-tables-only** and debugger tuning, the tuning
> option
>must come first.)
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r259507 - Make the remaining headers self-contained.

[Sean Silva via cfe-commits]

On Tue, Feb 2, 2016 at 11:15 AM, David Blaikie via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

>
>
> On Tue, Feb 2, 2016 at 11:11 AM, Rafael Espíndola <
> cfe-commits@lists.llvm.org> wrote:
>
>> Out of curiosity, what technique were you using to find out if the
>> headers were self-contained? Just "clang -c foo.h"?
>>
>
> Building LLVM & Clang with C++ modules enabled
>

Takumi, is there a reason that your bot was not finding these issues?

-- Sean Silva


>
>
>>
>> Cheers,
>> Rafael
>>
>>
>> On 2 February 2016 at 09:24, Benjamin Kramer via cfe-commits
>>  wrote:
>> > Author: d0k
>> > Date: Tue Feb  2 08:24:21 2016
>> > New Revision: 259507
>> >
>> > URL: http://llvm.org/viewvc/llvm-project?rev=259507&view=rev
>> > Log:
>> > Make the remaining headers self-contained.
>> >
>> > Modified:
>> > cfe/trunk/include/clang/AST/BaseSubobject.h
>> > cfe/trunk/include/clang/AST/DeclOpenMP.h
>> > cfe/trunk/include/clang/AST/Mangle.h
>> > cfe/trunk/include/clang/AST/TemplateName.h
>> > cfe/trunk/include/clang/Sema/CodeCompleteConsumer.h
>> > cfe/trunk/include/clang/Sema/ObjCMethodList.h
>> > cfe/trunk/include/clang/Sema/Ownership.h
>> > cfe/trunk/include/clang/Sema/Scope.h
>> > cfe/trunk/include/clang/Sema/SemaLambda.h
>> > cfe/trunk/lib/CodeGen/CGOpenMPRuntime.h
>> > cfe/trunk/lib/CodeGen/CodeGenTBAA.h
>> >
>> > Modified: cfe/trunk/include/clang/AST/BaseSubobject.h
>> > URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/BaseSubobject.h?rev=259507&r1=259506&r2=259507&view=diff
>> >
>> ==
>> > --- cfe/trunk/include/clang/AST/BaseSubobject.h (original)
>> > +++ cfe/trunk/include/clang/AST/BaseSubobject.h Tue Feb  2 08:24:21 2016
>> > @@ -15,13 +15,12 @@
>> >  #define LLVM_CLANG_AST_BASESUBOBJECT_H
>> >
>> >  #include "clang/AST/CharUnits.h"
>> > +#include "clang/AST/DeclCXX.h"
>> >  #include "llvm/ADT/DenseMap.h"
>> >  #include "llvm/Support/DataTypes.h"
>> >  #include "llvm/Support/type_traits.h"
>> >
>> >  namespace clang {
>> > -  class CXXRecordDecl;
>> > -
>> >  // BaseSubobject - Uniquely identifies a direct or indirect base class.
>> >  // Stores both the base class decl and the offset from the most
>> derived class to
>> >  // the base class. Used for vtable and VTT generation.
>> >
>> > Modified: cfe/trunk/include/clang/AST/DeclOpenMP.h
>> > URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclOpenMP.h?rev=259507&r1=259506&r2=259507&view=diff
>> >
>> ==
>> > --- cfe/trunk/include/clang/AST/DeclOpenMP.h (original)
>> > +++ cfe/trunk/include/clang/AST/DeclOpenMP.h Tue Feb  2 08:24:21 2016
>> > @@ -17,6 +17,7 @@
>> >
>> >  #include "clang/AST/DeclBase.h"
>> >  #include "llvm/ADT/ArrayRef.h"
>> > +#include "llvm/Support/TrailingObjects.h"
>> >
>> >  namespace clang {
>> >  class Expr;
>> >
>> > Modified: cfe/trunk/include/clang/AST/Mangle.h
>> > URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Mangle.h?rev=259507&r1=259506&r2=259507&view=diff
>> >
>> ==
>> > --- cfe/trunk/include/clang/AST/Mangle.h (original)
>> > +++ cfe/trunk/include/clang/AST/Mangle.h Tue Feb  2 08:24:21 2016
>> > @@ -14,6 +14,7 @@
>> >  #ifndef LLVM_CLANG_AST_MANGLE_H
>> >  #define LLVM_CLANG_AST_MANGLE_H
>> >
>> > +#include "clang/AST/Decl.h"
>> >  #include "clang/AST/Type.h"
>> >  #include "clang/Basic/ABI.h"
>> >  #include "llvm/ADT/DenseMap.h"
>> >
>> > Modified: cfe/trunk/include/clang/AST/TemplateName.h
>> > URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/TemplateName.h?rev=259507&r1=259506&r2=259507&view=diff
>> >
>> ==
>> > --- cfe/trunk/include/clang/AST/TemplateName.h (original)
>> > +++ cfe/trunk/include/clang/AST/TemplateName.h Tue Feb  2 08:24:21 2016
>> > @@ -14,6 +14,7 @@
>> >  #ifndef LLVM_CLANG_AST_TEMPLATENAME_H
>> >  #define LLVM_CLANG_AST_TEMPLATENAME_H
>> >
>> > +#include "clang/AST/NestedNameSpecifier.h"
>> >  #include "clang/Basic/LLVM.h"
>> >  #include "llvm/ADT/FoldingSet.h"
>> >  #include "llvm/ADT/PointerUnion.h"
>> >
>> > Modified: cfe/trunk/include/clang/Sema/CodeCompleteConsumer.h
>> > URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/CodeCompleteConsumer.h?rev=259507&r1=259506&r2=259507&view=diff
>> >
>> ==
>> > --- cfe/trunk/include/clang/Sema/CodeCompleteConsumer.h (original)
>> > +++ cfe/trunk/include/clang/Sema/CodeCompleteConsumer.h Tue Feb  2
>> 08:24:21 2016
>> > @@ -15,6 +15,7 @@
>> >
>> >  #include "clang-c/Index.h"
>> >  #include "clang/AST/CanonicalType.h"
>> > +#include "clang/AST/DeclBase.h"
>> >  #include "clang/AST/Type.h"
>> >  #include "clang/Sema/CodeCompleteOptio

Re: r260201 - [CMake] Providing a CMake cache for 3-stage builds

[Sean Silva via cfe-commits]

Neat! Besides the awesomeness of the bootstrap, I didn't know about the -C
option! (well, except that you told me about it at the social last week,
but this is the first time I saw the actual usage).

btw, the README.txt in cmake/caches says "The first two cache files in the
directory" -- but it's not clear what the "first two" are. Could you update
the description there?

-- Sean Silva

On Mon, Feb 8, 2016 at 10:01 PM, Chris Bieneman via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: cbieneman
> Date: Tue Feb  9 00:01:47 2016
> New Revision: 260201
>
> URL: http://llvm.org/viewvc/llvm-project?rev=260201&view=rev
> Log:
> [CMake] Providing a CMake cache for 3-stage builds
>
> This cache file can be used to generate a 3-stage clang build. You can
> configure using the following CMake command:
>
> cmake -C /cmake/caches/3-stage.cmake -G Ninja 
>
> You can then run "ninja stage3-clang" to build stage1, stage2 and stage3
> clangs.
>
> This is useful for finding non-determinism the compiler by verifying that
> stage2 and stage3 are identical.
>
> Added:
> cfe/trunk/cmake/caches/3-stage.cmake
>
> Added: cfe/trunk/cmake/caches/3-stage.cmake
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/caches/3-stage.cmake?rev=260201&view=auto
>
> ==
> --- cfe/trunk/cmake/caches/3-stage.cmake (added)
> +++ cfe/trunk/cmake/caches/3-stage.cmake Tue Feb  9 00:01:47 2016
> @@ -0,0 +1,34 @@
> +set(CMAKE_BUILD_TYPE RELEASE CACHE STRING "")
> +set(CLANG_ENABLE_BOOTSTRAP ON CACHE BOOL "")
> +set(LLVM_BUILD_EXTERNAL_COMPILER_RT ON CACHE BOOL "")
> +set(LLVM_TARGETS_TO_BUILD X86 CACHE STRING "")
> +set(BOOTSTRAP_LLVM_ENABLE_LTO ON CACHE BOOL "")
> +
> +set(CLANG_BOOTSTRAP_PASSTHROUGH
> +  CLANG_ENABLE_BOOTSTRAP
> +  LLVM_BUILD_EXTERNAL_COMPILER_RT
> +  LLVM_TARGETS_TO_BUILD
> +  CLANG_BOOTSTRAP_PASSTHROUGH
> +  BOOTSTRAP_LLVM_ENABLE_LTO
> +  CMAKE_BUILD_TYPE
> +  CACHE STRING "")
> +
> +set(CLANG_BOOTSTRAP_TARGETS
> +  clang
> +  check-all
> +  check-llvm
> +  check-clang
> +  test-suite
> +  stage3
> +  stage3-clang
> +  stage3-check-all
> +  stage3-check-llvm
> +  stage3-check-clang
> +  stage3-test-suite CACHE STRING "")
> +
> +set(BOOTSTRAP_CLANG_BOOTSTRAP_TARGETS
> +  clang
> +  check-all
> +  check-llvm
> +  check-clang
> +  test-suite CACHE STRING "")
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D16851: Update of "GCC extensions not implemented yet" in Clang User's Manual

[Sean Silva via cfe-commits]

silvas added a subscriber: silvas.
silvas added a comment.

Assuming the features are implemented this seems fine. LGTM.



Comment at: docs/UsersManual.rst:1698
@@ -1697,3 @@
--  clang does not support #pragma weak (`bug
-   3679 `_). Due to the uses
-   described in the bug, this is likely to be implemented at some point,

Should we close that bug then?


http://reviews.llvm.org/D16851



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r261053 - [AttrDocs.td] Fix up some reST syntax.

[Sean Silva via cfe-commits]

Author: silvas
Date: Tue Feb 16 20:08:19 2016
New Revision: 261053

URL: http://llvm.org/viewvc/llvm-project?rev=261053&view=rev
Log:
[AttrDocs.td] Fix up some reST syntax.

Modified:
cfe/trunk/include/clang/Basic/AttrDocs.td

Modified: cfe/trunk/include/clang/Basic/AttrDocs.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/AttrDocs.td?rev=261053&r1=261052&r2=261053&view=diff
==
--- cfe/trunk/include/clang/Basic/AttrDocs.td (original)
+++ cfe/trunk/include/clang/Basic/AttrDocs.td Tue Feb 16 20:08:19 2016
@@ -1765,7 +1765,7 @@ The ``not_tail_called`` attribute preven
 
 For example, it prevents tail-call optimization in the following case:
 
-  .. code-block: c
+  .. code-block:: c
 
 int __attribute__((not_tail_called)) foo1(int);
 
@@ -1775,7 +1775,7 @@ For example, it prevents tail-call optim
 
 However, it doesn't prevent tail-call optimization in this case:
 
-  .. code-block: c
+  .. code-block:: c
 
 int __attribute__((not_tail_called)) foo1(int);
 
@@ -1789,7 +1789,7 @@ However, it doesn't prevent tail-call op
 
 Marking virtual functions as ``not_tail_called`` is an error:
 
-  .. code-block: c++
+  .. code-block:: c++
 
 class Base {
 public:
@@ -1839,7 +1839,7 @@ For example:
 
 Marking virtual functions as ``disable_tail_calls`` is legal.
 
-  .. code-block: c++
+  .. code-block:: c++
 
 int callee(int);
 


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r261053 - [AttrDocs.td] Fix up some reST syntax.

[Sean Silva via cfe-commits]

Btw, thanks to nlewycky to pointing this out.

-- Sean Silva

On Tue, Feb 16, 2016 at 6:08 PM, Sean Silva via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: silvas
> Date: Tue Feb 16 20:08:19 2016
> New Revision: 261053
>
> URL: http://llvm.org/viewvc/llvm-project?rev=261053&view=rev
> Log:
> [AttrDocs.td] Fix up some reST syntax.
>
> Modified:
> cfe/trunk/include/clang/Basic/AttrDocs.td
>
> Modified: cfe/trunk/include/clang/Basic/AttrDocs.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/AttrDocs.td?rev=261053&r1=261052&r2=261053&view=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/AttrDocs.td (original)
> +++ cfe/trunk/include/clang/Basic/AttrDocs.td Tue Feb 16 20:08:19 2016
> @@ -1765,7 +1765,7 @@ The ``not_tail_called`` attribute preven
>
>  For example, it prevents tail-call optimization in the following case:
>
> -  .. code-block: c
> +  .. code-block:: c
>
>  int __attribute__((not_tail_called)) foo1(int);
>
> @@ -1775,7 +1775,7 @@ For example, it prevents tail-call optim
>
>  However, it doesn't prevent tail-call optimization in this case:
>
> -  .. code-block: c
> +  .. code-block:: c
>
>  int __attribute__((not_tail_called)) foo1(int);
>
> @@ -1789,7 +1789,7 @@ However, it doesn't prevent tail-call op
>
>  Marking virtual functions as ``not_tail_called`` is an error:
>
> -  .. code-block: c++
> +  .. code-block:: c++
>
>  class Base {
>  public:
> @@ -1839,7 +1839,7 @@ For example:
>
>  Marking virtual functions as ``disable_tail_calls`` is legal.
>
> -  .. code-block: c++
> +  .. code-block:: c++
>
>  int callee(int);
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D15829: [PGO] Clang Option that enables IR level PGO instrumentation

[Sean Silva via cfe-commits]

silvas added a comment.

Apologies for the delay. At this point, I think that this patch has evolved 
enough that it is best to start a new patch. I think the steps forward are:

- Have cc1 accept -fprofile-instrument=llvm (requires no driver changes, but is 
enough for developers to test by being careful and manually passing it)
- Start a discussion on llvm-dev to decide on the driver-level
- implement other driver features as discussed
  - e.g. if we decide that -fprofile-instr-use= should detect FE/IR (i.e. IR is 
not a separate flag), add FE/IR detection for -fprofile-instr-use=



Comment at: test/CodeGen/pgo-instrumentation.c:4
@@ +3,3 @@
+// Ensure Pass PGOInstrumentationGenPass is invoked.
+// RUN: %clang -O2 -c -Xclang -fprofile-instrument=llvm 
-fprofile-instr-generate %s -mllvm -debug-pass=Structure 2>&1 | FileCheck %s 
-check-prefix=CHECK-PGOGENPASS-INVOKED-INSTR-GEN
+// CHECK-PGOGENPASS-INVOKED-INSTR-GEN: PGOInstrumentationGenPass

Use `%clang_cc1` here and elsewhere.


http://reviews.llvm.org/D15829



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r261552 - [VFS] Add 'overlay-relative' field to YAML files

[Sean Silva via cfe-commits]

This or r261551 seem to be causing a build failure:
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/527

-- Sean SIlva

On Mon, Feb 22, 2016 at 10:41 AM, Bruno Cardoso Lopes via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: bruno
> Date: Mon Feb 22 12:41:09 2016
> New Revision: 261552
>
> URL: http://llvm.org/viewvc/llvm-project?rev=261552&view=rev
> Log:
> [VFS] Add 'overlay-relative' field to YAML files
>
> The VFS overlay mapping between virtual paths and real paths is done
> through
> the 'external-contents' entries in YAML files, which contains hardcoded
> paths
> to the real files.
>
> When a module compilation crashes, headers are dumped into .cache/vfs
> directory and are mapped via the .cache/vfs/vfs.yaml. The script
> generated for reproduction uses -ivfsoverlay pointing to file to gather the
> mapping between virtual paths and files inside .cache/vfs.
> Currently, we
> are only capable of reproducing such crashes in the same machine as they
> happen, because of the hardcoded paths in 'external-contents'.
>
> To be able to reproduce a crash in another machine, this patch introduces
> a new
> option in the VFS yaml file called 'overlay-relative'. When it's equal to
> 'true' it means that the provided path to the YAML file through the
> -ivfsoverlay option should also be used to prefix the final path for every
> 'external-contents'.
>
> Example, given the invocation snippet "... -ivfsoverlay
> .cache/vfs/vfs.yaml" and the following entry in the yaml file:
>
> "overlay-relative": "true",
> "roots": [
> ...
>   "type": "directory",
>   "name": "/usr/include",
>   "contents": [
> {
>   "type": "file",
>   "name": "stdio.h",
>   "external-contents": "/usr/include/stdio.h"
> },
> ...
>
> Here, a file manager request for virtual "/usr/include/stdio.h", that will
> map
> into real path "//.cache/vfs/usr/include/stdio.h.
>
> This is a useful feature for debugging module crashes in machines other
> than
> the one where the error happened.
>
> Differential Revision: http://reviews.llvm.org/D17457
>
> rdar://problem/24499339
>
> Added:
> cfe/trunk/test/Modules/crash-vfs-relative-overlay.m
>   - copied, changed from r261551,
> cfe/trunk/test/Modules/crash-vfs-path-traversal.m
> Modified:
> cfe/trunk/include/clang/Basic/VirtualFileSystem.h
> cfe/trunk/lib/Basic/VirtualFileSystem.cpp
> cfe/trunk/lib/Frontend/CompilerInvocation.cpp
> cfe/trunk/lib/Frontend/ModuleDependencyCollector.cpp
> cfe/trunk/test/Modules/crash-vfs-path-symlink-component.m
> cfe/trunk/test/Modules/crash-vfs-path-traversal.m
>
> Modified: cfe/trunk/include/clang/Basic/VirtualFileSystem.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/VirtualFileSystem.h?rev=261552&r1=261551&r2=261552&view=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/VirtualFileSystem.h (original)
> +++ cfe/trunk/include/clang/Basic/VirtualFileSystem.h Mon Feb 22 12:41:09
> 2016
> @@ -310,6 +310,7 @@ llvm::sys::fs::UniqueID getNextVirtualUn
>  IntrusiveRefCntPtr
>  getVFSFromYAML(std::unique_ptr Buffer,
> llvm::SourceMgr::DiagHandlerTy DiagHandler,
> +   StringRef YAMLFilePath,
> void *DiagContext = nullptr,
> IntrusiveRefCntPtr ExternalFS =
> getRealFileSystem());
>
> @@ -323,6 +324,8 @@ struct YAMLVFSEntry {
>  class YAMLVFSWriter {
>std::vector Mappings;
>Optional IsCaseSensitive;
> +  Optional IsOverlayRelative;
> +  std::string OverlayDir;
>
>  public:
>YAMLVFSWriter() {}
> @@ -330,6 +333,11 @@ public:
>void setCaseSensitivity(bool CaseSensitive) {
>  IsCaseSensitive = CaseSensitive;
>}
> +  void setOverlayDir(StringRef OverlayDirectory) {
> +IsOverlayRelative = true;
> +OverlayDir.assign(OverlayDirectory.str());
> +  }
> +
>void write(llvm::raw_ostream &OS);
>  };
>
>
> Modified: cfe/trunk/lib/Basic/VirtualFileSystem.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/VirtualFileSystem.cpp?rev=261552&r1=261551&r2=261552&view=diff
>
> ==
> --- cfe/trunk/lib/Basic/VirtualFileSystem.cpp (original)
> +++ cfe/trunk/lib/Basic/VirtualFileSystem.cpp Mon Feb 22 12:41:09 2016
> @@ -790,6 +790,7 @@ public:
>  /// All configuration options are optional.
>  ///   'case-sensitive': 
>  ///   'use-external-names': 
> +///   'overlay-relative': 
>  ///
>  /// Virtual directories are represented as
>  /// \verbatim
> @@ -832,6 +833,10 @@ class RedirectingFileSystem : public vfs
>std::vector> Roots;
>/// \brief The file system to use for external references.
>IntrusiveRefCntPtr ExternalFS;
> +  /// If IsRelativeOverlay is set, this represents the directory
> +  /// path that should be prefixed to each 'external-contents' entry
> +  /// when reading from YAML files.
> +  std::strin

Re: r261552 - [VFS] Add 'overlay-relative' field to YAML files

[Sean Silva via cfe-commits]

The bot is still red:
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast

On Mon, Feb 22, 2016 at 6:48 PM, Bruno Cardoso Lopes <
bruno.card...@gmail.com> wrote:

> Hi Sean,
>
> This is hopefully fixed in r261556.
>
> On Mon, Feb 22, 2016 at 5:45 PM, Sean Silva  wrote:
> > This or r261551 seem to be causing a build failure:
> >
> http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/527
> >
> > -- Sean SIlva
> >
> > On Mon, Feb 22, 2016 at 10:41 AM, Bruno Cardoso Lopes via cfe-commits
> >  wrote:
> >>
> >> Author: bruno
> >> Date: Mon Feb 22 12:41:09 2016
> >> New Revision: 261552
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=261552&view=rev
> >> Log:
> >> [VFS] Add 'overlay-relative' field to YAML files
> >>
> >> The VFS overlay mapping between virtual paths and real paths is done
> >> through
> >> the 'external-contents' entries in YAML files, which contains hardcoded
> >> paths
> >> to the real files.
> >>
> >> When a module compilation crashes, headers are dumped into
> >> .cache/vfs
> >> directory and are mapped via the .cache/vfs/vfs.yaml. The script
> >> generated for reproduction uses -ivfsoverlay pointing to file to gather
> >> the
> >> mapping between virtual paths and files inside .cache/vfs.
> >> Currently, we
> >> are only capable of reproducing such crashes in the same machine as they
> >> happen, because of the hardcoded paths in 'external-contents'.
> >>
> >> To be able to reproduce a crash in another machine, this patch
> introduces
> >> a new
> >> option in the VFS yaml file called 'overlay-relative'. When it's equal
> to
> >> 'true' it means that the provided path to the YAML file through the
> >> -ivfsoverlay option should also be used to prefix the final path for
> every
> >> 'external-contents'.
> >>
> >> Example, given the invocation snippet "... -ivfsoverlay
> >> .cache/vfs/vfs.yaml" and the following entry in the yaml file:
> >>
> >> "overlay-relative": "true",
> >> "roots": [
> >> ...
> >>   "type": "directory",
> >>   "name": "/usr/include",
> >>   "contents": [
> >> {
> >>   "type": "file",
> >>   "name": "stdio.h",
> >>   "external-contents": "/usr/include/stdio.h"
> >> },
> >> ...
> >>
> >> Here, a file manager request for virtual "/usr/include/stdio.h", that
> will
> >> map
> >> into real path
> "//.cache/vfs/usr/include/stdio.h.
> >>
> >> This is a useful feature for debugging module crashes in machines other
> >> than
> >> the one where the error happened.
> >>
> >> Differential Revision: http://reviews.llvm.org/D17457
> >>
> >> rdar://problem/24499339
> >>
> >> Added:
> >> cfe/trunk/test/Modules/crash-vfs-relative-overlay.m
> >>   - copied, changed from r261551,
> >> cfe/trunk/test/Modules/crash-vfs-path-traversal.m
> >> Modified:
> >> cfe/trunk/include/clang/Basic/VirtualFileSystem.h
> >> cfe/trunk/lib/Basic/VirtualFileSystem.cpp
> >> cfe/trunk/lib/Frontend/CompilerInvocation.cpp
> >> cfe/trunk/lib/Frontend/ModuleDependencyCollector.cpp
> >> cfe/trunk/test/Modules/crash-vfs-path-symlink-component.m
> >> cfe/trunk/test/Modules/crash-vfs-path-traversal.m
> >>
> >> Modified: cfe/trunk/include/clang/Basic/VirtualFileSystem.h
> >> URL:
> >>
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/VirtualFileSystem.h?rev=261552&r1=261551&r2=261552&view=diff
> >>
> >>
> ==
> >> --- cfe/trunk/include/clang/Basic/VirtualFileSystem.h (original)
> >> +++ cfe/trunk/include/clang/Basic/VirtualFileSystem.h Mon Feb 22
> 12:41:09
> >> 2016
> >> @@ -310,6 +310,7 @@ llvm::sys::fs::UniqueID getNextVirtualUn
> >>  IntrusiveRefCntPtr
> >>  getVFSFromYAML(std::unique_ptr Buffer,
> >> llvm::SourceMgr::DiagHandlerTy DiagHandler,
> >> +   StringRef YAMLFilePath,
> >> void *DiagContext = nullptr,
> >> IntrusiveRefCntPtr ExternalFS =
> >> getRealFileSystem());
> >>
> >> @@ -323,6 +324,8 @@ struct YAMLVFSEntry {
> >>  class YAMLVFSWriter {
> >>std::vector Mappings;
> >>Optional IsCaseSensitive;
> >> +  Optional IsOverlayRelative;
> >> +  std::string OverlayDir;
> >>
> >>  public:
> >>YAMLVFSWriter() {}
> >> @@ -330,6 +333,11 @@ public:
> >>void setCaseSensitivity(bool CaseSensitive) {
> >>  IsCaseSensitive = CaseSensitive;
> >>}
> >> +  void setOverlayDir(StringRef OverlayDirectory) {
> >> +IsOverlayRelative = true;
> >> +OverlayDir.assign(OverlayDirectory.str());
> >> +  }
> >> +
> >>void write(llvm::raw_ostream &OS);
> >>  };
> >>
> >>
> >> Modified: cfe/trunk/lib/Basic/VirtualFileSystem.cpp
> >> URL:
> >>
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/VirtualFileSystem.cpp?rev=261552&r1=261551&r2=261552&view=diff
> >>
> >>
> ==
> >> --- cfe/trunk/lib/Basic/VirtualFileSystem.cpp (original)
> >> +++ cfe/trun

Re: [clang-tools-extra] r261737 - [clang-tidy] Added a check for forward declaration in the potentially wrong namespace

[Sean Silva via cfe-commits]

This or r261737 seem to be causing a bot failure:
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/636

-- Sean Silva

On Wed, Feb 24, 2016 at 5:35 AM, Alexander Kornienko via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: alexfh
> Date: Wed Feb 24 07:35:32 2016
> New Revision: 261737
>
> URL: http://llvm.org/viewvc/llvm-project?rev=261737&view=rev
> Log:
> [clang-tidy] Added a check for forward declaration in the potentially
> wrong namespace
>
> Adds a new check "misc-forward-declaration-namespace".
> In check, A forward declaration is considerred in a potentially wrong
> namespace
> if there is any definition/declaration with the same name exists in a
> different
> namespace.
>
> Reviewers: akuegel, hokein, alexfh
>
> Patch by Eric Liu!
>
> Differential Revision: http://reviews.llvm.org/D17195
>
> Added:
>
> clang-tools-extra/trunk/clang-tidy/misc/ForwardDeclarationNamespaceCheck.cpp
>
> clang-tools-extra/trunk/clang-tidy/misc/ForwardDeclarationNamespaceCheck.h
>
> clang-tools-extra/trunk/docs/clang-tidy/checks/misc-forward-declaration-namespace.rst
>
> clang-tools-extra/trunk/test/clang-tidy/misc-forward-declaration-namespace.cpp
> Modified:
> clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt
> clang-tools-extra/trunk/clang-tidy/misc/MiscTidyModule.cpp
> clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst
>
> Modified: clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt?rev=261737&r1=261736&r2=261737&view=diff
>
> ==
> --- clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt (original)
> +++ clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt Wed Feb 24
> 07:35:32 2016
> @@ -6,6 +6,7 @@ add_clang_library(clangTidyMiscModule
>AssignOperatorSignatureCheck.cpp
>BoolPointerImplicitConversionCheck.cpp
>DefinitionsInHeadersCheck.cpp
> +  ForwardDeclarationNamespaceCheck.cpp
>InaccurateEraseCheck.cpp
>IncorrectRoundings.cpp
>InefficientAlgorithmCheck.cpp
>
> Added:
> clang-tools-extra/trunk/clang-tidy/misc/ForwardDeclarationNamespaceCheck.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/misc/ForwardDeclarationNamespaceCheck.cpp?rev=261737&view=auto
>
> ==
> ---
> clang-tools-extra/trunk/clang-tidy/misc/ForwardDeclarationNamespaceCheck.cpp
> (added)
> +++
> clang-tools-extra/trunk/clang-tidy/misc/ForwardDeclarationNamespaceCheck.cpp
> Wed Feb 24 07:35:32 2016
> @@ -0,0 +1,174 @@
> +//===--- ForwardDeclarationNamespaceCheck.cpp - clang-tidy --*- C++
> -*-===//
> +//
> +// The LLVM Compiler Infrastructure
> +//
> +// This file is distributed under the University of Illinois Open Source
> +// License. See LICENSE.TXT for details.
> +//
>
> +//===--===//
> +
> +#include "ForwardDeclarationNamespaceCheck.h"
> +#include 
> +#include 
> +#include "clang/AST/ASTContext.h"
> +#include "clang/AST/Decl.h"
> +#include "clang/ASTMatchers/ASTMatchFinder.h"
> +#include "clang/ASTMatchers/ASTMatchers.h"
> +
> +using namespace clang::ast_matchers;
> +
> +namespace clang {
> +namespace tidy {
> +namespace misc {
> +
> +void ForwardDeclarationNamespaceCheck::registerMatchers(MatchFinder
> *Finder) {
> +  // Match all class declarations/definitions *EXCEPT*
> +  // 1. implicit classes, e.g. `class A {};` has implicit `class A`
> inside `A`.
> +  // 2. nested classes declared/defined inside another class.
> +  // 3. template class declaration, template instantiation or
> +  //specialization (NOTE: extern specialization is filtered out by
> +  //`unless(hasAncestor(cxxRecordDecl()))`).
> +  auto IsInSpecialization = hasAncestor(
> +  decl(anyOf(cxxRecordDecl(isExplicitTemplateSpecialization()),
> + functionDecl(isExplicitTemplateSpecialization();
> +  Finder->addMatcher(
> +  cxxRecordDecl(
> +  hasParent(decl(anyOf(namespaceDecl(), translationUnitDecl(,
> +  unless(isImplicit()), unless(hasAncestor(cxxRecordDecl())),
> +  unless(isInstantiated()), unless(IsInSpecialization),
> +  unless(classTemplateSpecializationDecl()))
> +  .bind("record_decl"),
> +  this);
> +
> +  // Match all friend declarations. Classes used in friend declarations
> are not
> +  // marked as referenced in AST. We need to record all record classes
> used in
> +  // friend declarations.
> +  Finder->addMatcher(friendDecl().bind("friend_decl"), this);
> +}
> +
> +void ForwardDeclarationNamespaceCheck::check(
> +const MatchFinder::MatchResult &Result) {
> +  if (const auto *RecordDecl =
> +  Result.Nodes.getNodeAs("record_decl")) {
> +StringRef DeclName = RecordDecl->getName();
> +i

Re: [PATCH] D15829: [PGO] Clang Option that enables IR level PGO instrumentation

[Sean Silva via cfe-commits]

silvas added a comment.

In http://reviews.llvm.org/D15829#360006, @xur wrote:

> Here is the new patch that removes the auto detection of profile kind.
>
> In this patch, I replace the CC1 option of -fprofile-instr-use=<> with 
> -fprofile-instrument={llvm-use|clang-use}. For the use compilation, the 
> profile reuses the -fprofile-instrument-path= option.
>
> Again, all changes are of CC1 options. Driver options are intact.
>
> Some test are modified due to the -fprofile-instr-use= option change.
>
> A new test is added to test IR profile compilation. 
>  test/CodeGen/pgo-instrumentation.c


I meant in a new phabricator review. This one is has gone on for too long and 
is convoluted and hard to follow. (lots of stray inline comments etc.)


http://reviews.llvm.org/D15829



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D17622: [PGO] clang cc1 option change to enable IR level instrumenation

[Sean Silva via cfe-commits]

silvas added a comment.

Thanks for splitting this out.

I think the `-fprofile-instrument=llvm` is straightforward and uncontroversial. 
Let's focus this review on that and split the others into a separate review.

But a quick preview of my thoughs about `-fprofile-instrument={llvm,clang}-use`:
I think that fully decoupling the cc1 options from the driver options like you 
are doing here is a good cleanup, but we need a more refined approach. For 
example, the current patch has "use" modes as mutually exclusive with the "gen" 
modes, which doesn't make sense. In fact, we have already seen a situation 
where we may want to have "use" and "gen" in the same clang invocation: for 
profile guided MST instr. And I don't see a reason to artificially prohibit FE 
"use" to annotate MD_prof metadata and then use that metadata for profile 
guided MST instr (however, it would be a strange workflow for users...).
Perhaps something like `-fprofile-instrument-use={llvm,clang}` which sets a 
CodeGenOpt `ProfileUse` which is either {None, Clang, LLVM}. We can use a 
common PGOInstrumentor enum for both, since there is a 1:1 mapping between the 
instrumentor and its corresponding "use" logic.
In the long run I imagine we will want two mirror options 
`-fpgo-gen={none,llvm,clang}` and `-fpgo-use={none,llvm,clang}`, but the 
details of renaming to the final state can wait until we clearly see the right 
design (this is cc1 so it is easy to refactor as needed later).


http://reviews.llvm.org/D17622



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r268127 - Add a new warning to notify users of mismatched SDK and deployment target

[Sean Silva via cfe-commits]

This breaks the PS4 bots at least. They've been red for hours now.
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast?numbuilds=100

On Fri, Apr 29, 2016 at 3:28 PM, Chris Bieneman via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: cbieneman
> Date: Fri Apr 29 17:28:34 2016
> New Revision: 268127
>
> URL: http://llvm.org/viewvc/llvm-project?rev=268127&view=rev
> Log:
> Add a new warning to notify users of mismatched SDK and deployment target
>
> Summary:
> This patch adds a new driver warning -Wincompatible-sdk which notifies the
> user when they are mismatching the version min options and the sysroot.
>
> The patch works by checking the sysroot (if present) for an SDK name, then
> matching that against the target platform. In the case of a mismatch it
> logs a warning.
>
> Reviewers: bob.wilson, rsmith
>
> Subscribers: rsmith, edward-san, cfe-commits
>
> Differential Revision: http://reviews.llvm.org/D18088
>
> Added:
> cfe/trunk/test/Driver/incompatible_sysroot.c
> Modified:
> cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
> cfe/trunk/lib/Driver/ToolChains.cpp
> cfe/trunk/lib/Driver/ToolChains.h
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td?rev=268127&r1=268126&r2=268127&view=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td Fri Apr 29
> 17:28:34 2016
> @@ -198,6 +198,8 @@ def warn_drv_pch_not_first_include : War
>"precompiled header '%0' was ignored because '%1' is not first
> '-include'">;
>  def warn_missing_sysroot : Warning<"no such sysroot directory: '%0'">,
>InGroup>;
> +def warn_incompatible_sysroot : Warning<"using sysroot for '%0' but
> targeting '%1'">,
> +  InGroup>;
>  def warn_debug_compression_unavailable : Warning<"cannot compress debug
> sections (zlib not installed)">,
>InGroup>;
>  def warn_drv_enabling_rtti_with_exceptions : Warning<
>
> Modified: cfe/trunk/lib/Driver/ToolChains.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains.cpp?rev=268127&r1=268126&r2=268127&view=diff
>
> ==
> --- cfe/trunk/lib/Driver/ToolChains.cpp (original)
> +++ cfe/trunk/lib/Driver/ToolChains.cpp Fri Apr 29 17:28:34 2016
> @@ -329,6 +329,36 @@ void MachO::AddLinkRuntimeLib(const ArgL
>}
>  }
>
> +StringRef Darwin::getPlatformFamily() const {
> +  switch (TargetPlatform) {
> +case DarwinPlatformKind::MacOS:
> +  return "MacOSX";
> +case DarwinPlatformKind::IPhoneOS:
> +case DarwinPlatformKind::IPhoneOSSimulator:
> +  return "iPhone";
> +case DarwinPlatformKind::TvOS:
> +case DarwinPlatformKind::TvOSSimulator:
> +  return "AppleTV";
> +case DarwinPlatformKind::WatchOS:
> +case DarwinPlatformKind::WatchOSSimulator:
> +  return "Watch";
> +  }
> +  llvm_unreachable("Unsupported platform");
> +}
> +
> +StringRef Darwin::getSDKName(StringRef isysroot) {
> +  // Assume SDK has path: SOME_PATH/SDKs/PlatformXX.YY.sdk
> +  llvm::sys::path::const_iterator SDKDir;
> +  auto BeginSDK = llvm::sys::path::begin(isysroot);
> +  auto EndSDK = llvm::sys::path::end(isysroot);
> +  for (auto IT = BeginSDK; IT != EndSDK; ++IT) {
> +StringRef SDK = *IT;
> +if (SDK.endswith(".sdk"))
> +  return SDK.slice(0, SDK.size() - 4);
> +  }
> +  return "";
> +}
> +
>  StringRef Darwin::getOSLibraryNameSuffix() const {
>switch(TargetPlatform) {
>case DarwinPlatformKind::MacOS:
> @@ -540,11 +570,8 @@ void Darwin::AddDeploymentTarget(Derived
>  TvOSTarget.empty() && Args.hasArg(options::OPT_isysroot)) {
>if (const Arg *A = Args.getLastArg(options::OPT_isysroot)) {
>  StringRef isysroot = A->getValue();
> -// Assume SDK has path: SOME_PATH/SDKs/PlatformXX.YY.sdk
> -size_t BeginSDK = isysroot.rfind("SDKs/");
> -size_t EndSDK = isysroot.rfind(".sdk");
> -if (BeginSDK != StringRef::npos && EndSDK != StringRef::npos) {
> -  StringRef SDK = isysroot.slice(BeginSDK + 5, EndSDK);
> +StringRef SDK = getSDKName(isysroot);
> +if (SDK.size() > 0) {
>// Slice the version number out.
>// Version number is between the first and the last number.
>size_t StartVer = SDK.find_first_of("0123456789");
> @@ -697,6 +724,17 @@ void Darwin::AddDeploymentTarget(Derived
>  Platform = WatchOSSimulator;
>
>setTarget(Platform, Major, Minor, Micro);
> +
> +  if (const Arg *A = Args.getLastArg(options::OPT_isysroot)) {
> +StringRef SDK = getSDKName(A->getValue());
> +if (SDK.size() > 0) {
> +  size_t StartVer = SDK.find_first_of("0123456789");
> +  StringRef SDKName = SDK.slice(0, StartVer);
> +  if (!

Re: [PATCH] D19678: Annotated-source optimization reports (a.k.a. "listing" files)

[Sean Silva via cfe-commits]

On Mon, May 2, 2016 at 4:14 PM, Hal Finkel via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> hfinkel added a comment.
>
> In http://reviews.llvm.org/D19678#416127, @rcox2 wrote:
>
> > Actually, the Intel compiler distinguishes between an optimization
> report (-qopt-report) and an annotated listing (-qopt-report-annotate).
> The optimization report lists the info for optimizations in a hierarchical
> fashion.  To use you example,
> >
> >   icc -c -O3 -qopt-report=1 -qopt-report-file=stderr v.c
> >
> > yields:
>
>
> Robert, John, (et al.), do you think I should change this to have an
> -foptimization-report-file= and -foptimization-report, instead of
> -foptimization-report=? In the future, when we have multiple
> kinds of reports (a detailed inlining report, for example), maybe we want
> to use -foptimization-report=inlining,somethingelse,andmore?
>

If we have `-foptimization-report=foo,bar`, would we want them to share the
same output file? Or maybe `-foptimization-report-file=` would result
in `.foo` and `.bar` for the different reports?

-- Sean Silva


>
>
> http://reviews.llvm.org/D19678
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r268777 - Frontend: support -I=path for sysroot expansion

[Sean Silva via cfe-commits]

Do we also handle ':'? The corresponding behavior in the linker is in:
http://llvm.org/klaus/lld/blob/master/ELF/DriverUtils.cpp#L-232

-- Sean Silva

On Fri, May 6, 2016 at 12:13 PM, Saleem Abdulrasool via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: compnerd
> Date: Fri May  6 14:13:55 2016
> New Revision: 268777
>
> URL: http://llvm.org/viewvc/llvm-project?rev=268777&view=rev
> Log:
> Frontend: support -I=path for sysroot expansion
>
> From the GCC manpage:
>
>   -I dir
> ... If dir begins with =, then the = will be replaced by the sysroot
> prefix;
> see --sysroot and -isysroot.
>
> Add support to expand the `=` as a prefix of the include path with the
> sysroot
> if specified.  `-isysroot` takes precedence over `--sysroot` as the normal
> argument behaviour occurs.  The ordering of the `-isysroot` is relevant to
> the
> path substituted.  If no `--sysroot=` or `-isysroot` option is present,
> the = is
> not expanded.
>
> Resolves PR26965!
>
> Added:
> cfe/trunk/test/Preprocessor/sysroot-prefix.c
> Modified:
> cfe/trunk/lib/Frontend/CompilerInvocation.cpp
>
> Modified: cfe/trunk/lib/Frontend/CompilerInvocation.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/CompilerInvocation.cpp?rev=268777&r1=268776&r2=268777&view=diff
>
> ==
> --- cfe/trunk/lib/Frontend/CompilerInvocation.cpp (original)
> +++ cfe/trunk/lib/Frontend/CompilerInvocation.cpp Fri May  6 14:13:55 2016
> @@ -1278,6 +1278,8 @@ static void ParseHeaderSearchArgs(Header
>
>// Add -I..., -F..., and -index-header-map options in order.
>bool IsIndexHeaderMap = false;
> +  bool IsSysrootSpecified =
> +  Args.hasArg(OPT__sysroot_EQ) || Args.hasArg(OPT_isysroot);
>for (const Arg *A : Args.filtered(OPT_I, OPT_F, OPT_index_header_map)) {
>  if (A->getOption().matches(OPT_index_header_map)) {
>// -index-header-map applies to the next -I or -F.
> @@ -1288,8 +1290,18 @@ static void ParseHeaderSearchArgs(Header
>  frontend::IncludeDirGroup Group =
>  IsIndexHeaderMap ? frontend::IndexHeaderMap : frontend::Angled;
>
> -Opts.AddPath(A->getValue(), Group,
> - /*IsFramework=*/A->getOption().matches(OPT_F), true);
> +bool IsFramework = A->getOption().matches(OPT_F);
> +std::string Path = A->getValue();
> +
> +if (IsSysrootSpecified && !IsFramework && A->getValue()[0] == '=') {
> +  SmallString<32> Buffer;
> +  llvm::sys::path::append(Buffer, Opts.Sysroot,
> +  llvm::StringRef(A->getValue()).substr(1));
> +  Path = Buffer.str();
> +}
> +
> +Opts.AddPath(Path.c_str(), Group, IsFramework,
> + /*IgnoreSysroot*/ true);
>  IsIndexHeaderMap = false;
>}
>
>
> Added: cfe/trunk/test/Preprocessor/sysroot-prefix.c
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Preprocessor/sysroot-prefix.c?rev=268777&view=auto
>
> ==
> --- cfe/trunk/test/Preprocessor/sysroot-prefix.c (added)
> +++ cfe/trunk/test/Preprocessor/sysroot-prefix.c Fri May  6 14:13:55 2016
> @@ -0,0 +1,28 @@
> +// RUN: %clang_cc1 -v -isysroot /var/empty -I /dev/null -E %s -o
> /dev/null 2>&1 | FileCheck -check-prefix CHECK-ISYSROOT_NO_SYSROOT %s
> +// RUN: %clang_cc1 -v -isysroot /var/empty -I =/dev/null -E %s -o
> /dev/null 2>&1 | FileCheck -check-prefix CHECK-ISYSROOT_SYSROOT_DEV_NULL %s
> +// RUN: %clang_cc1 -v -I =/dev/null -E %s -o /dev/null 2>&1 | FileCheck
> -check-prefix CHECK-NO_ISYSROOT_SYSROOT_DEV_NULL %s
> +// RUN: %clang_cc1 -v -isysroot /var/empty -I =null -E %s -o /dev/null
> 2>&1 | FileCheck -check-prefix CHECK-ISYSROOT_SYSROOT_NULL %s
> +// RUN: %clang_cc1 -v -isysroot /var/empty -isysroot /var/empty/root -I
> =null -E %s -o /dev/null 2>&1 | FileCheck -check-prefix
> CHECK-ISYSROOT_ISYSROOT_SYSROOT_NULL %s
> +// RUN: %clang_cc1 -v -isysroot /var/empty/root -isysroot /var/empty -I
> =null -E %s -o /dev/null 2>&1 | FileCheck -check-prefix
> CHECK-ISYSROOT_ISYSROOT_SWAPPED_SYSROOT_NULL %s
> +
> +// CHECK-ISYSROOT_NO_SYSROOT: ignoring nonexistent directory "/dev/null"
> +// CHECK-ISYSROOT_NO_SYSROOT-NOT: ignoring nonexistent directory
> "/var/empty/dev/null"
> +
> +// CHECK-NO_ISYSROOT_SYSROOT_DEV_NULL: ignoring nonexistent directory
> "=/dev/null"
> +// CHECK-NO_ISYSROOT_SYSROOT_DEV_NULL-NOT: ignoring nonexistent directory
> "/dev/null"
> +
> +// CHECK-ISYSROOT_SYSROOT_DEV_NULL: ignoring nonexistent directory
> "/var/empty/dev/null"
> +// CHECK-ISYSROOT_SYSROOT_DEV_NULL-NOT: ignoring nonexistent directory
> "/dev/null"
> +
> +// CHECK-NO_ISYSROOT_SYSROOT: ignoring nonexistent directory "=/dev/null"
> +// CHECK-NO_ISYSROOT_SYSROOT-NOT: ignoring nonexistent directory
> "/var/empty/dev/null"
> +
> +// CHECK-ISYSROOT_SYSROOT_NULL: ignoring nonexistent directory
> "/var/empty/null"
> +// CHECK-ISYSROOT_SYSROOT_NULL-NOT: ignoring nonexistent direct

Re: [PATCH] D19996: New clang option -mpiecopyrelocs to indicate support for linker copy relocations when linking as PIE

[Sean Silva via cfe-commits]

If this is something that GCC doesn't have, it would be nice if we put
something in our own docs about it (something like docs/UsersManual.rst).

On Thu, May 5, 2016 at 2:34 PM, Sriraman Tallam via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On Thu, May 5, 2016 at 2:31 PM, Rafael Espíndola
>  wrote:
> > Is there a gcc option or they just assume they are targeting the
> > linker that was around when gcc was built?
>
> It is done at configure time, the linker is checked for copy
> relocations support.  I recently saw a request to replace this with a
> flag like -mpiecopyrelocs.  I chatted off-line with Reid about this
> and a flag was suggested.
>
> >
> >
> >> +  if (Args.hasFlag(options::OPT_mpiecopyrelocs,
> options::OPT_mno_piecopyrelocs,
> >> +   false)) {
> >> +CmdArgs.push_back("-piecopyrelocs");
> >> +  }
> >
> > you don't need the {}
> >
> >> +def piecopyrelocs : Flag<["-"], "piecopyrelocs">,
> >> +  HelpText<"Linker copy relocations support when linking as PIE">;
> >
> > I think you are missing a verb: Linker copy relocations *are* supported.
> >
> > But how about just "Position independent executables can have copy
> relocations"?
> >
> > Cheers,
> > Rafael
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r269160 - Hopefully bring llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast back to life

[Sean Silva via cfe-commits]

Author: silvas
Date: Tue May 10 23:04:59 2016
New Revision: 269160

URL: http://llvm.org/viewvc/llvm-project?rev=269160&view=rev
Log:
Hopefully bring llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast back to life

Bruno made a couple valiant attempts but the bot is still red.

This reverts r269100 (primary commit), r269108 (fix attempt), r269133
(fix attempt).

Modified:
cfe/trunk/lib/Basic/VirtualFileSystem.cpp
cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp

Modified: cfe/trunk/lib/Basic/VirtualFileSystem.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/VirtualFileSystem.cpp?rev=269160&r1=269159&r2=269160&view=diff
==
--- cfe/trunk/lib/Basic/VirtualFileSystem.cpp (original)
+++ cfe/trunk/lib/Basic/VirtualFileSystem.cpp Tue May 10 23:04:59 2016
@@ -719,13 +719,7 @@ public:
 Status S)
   : Entry(EK_Directory, Name), Contents(std::move(Contents)),
 S(std::move(S)) {}
-  RedirectingDirectoryEntry(StringRef Name, Status S)
-  : Entry(EK_Directory, Name), S(std::move(S)) {}
   Status getStatus() { return S; }
-  void addContent(std::unique_ptr Content) {
-Contents.push_back(std::move(Content));
-  }
-  Entry *getLastContent() const { return Contents.back().get(); }
   typedef decltype(Contents)::iterator iterator;
   iterator contents_begin() { return Contents.begin(); }
   iterator contents_end() { return Contents.end(); }
@@ -753,7 +747,6 @@ public:
 return UseName == NK_NotSet ? GlobalUseExternalName
 : (UseName == NK_External);
   }
-  NameKind getUseName() const { return UseName; }
   static bool classof(const Entry *E) { return E->getKind() == EK_File; }
 };
 
@@ -1030,70 +1023,6 @@ class RedirectingFileSystemParser {
 return true;
   }
 
-  Entry *lookupOrCreateEntry(RedirectingFileSystem *FS, StringRef Name,
- Entry *ParentEntry = nullptr) {
-if (!ParentEntry) { // Look for a existent root
-  for (const std::unique_ptr &Root : FS->Roots) {
-if (Name.equals(Root->getName())) {
-  ParentEntry = Root.get();
-  return ParentEntry;
-}
-  }
-} else { // Advance to the next component
-  auto *DE = dyn_cast(ParentEntry);
-  for (std::unique_ptr &Content :
-   llvm::make_range(DE->contents_begin(), DE->contents_end())) {
-auto *DirContent = dyn_cast(Content.get());
-if (DirContent && Name.equals(Content->getName()))
-  return DirContent;
-  }
-}
-
-// ... or create a new one
-std::unique_ptr E = llvm::make_unique(
-Name, Status("", getNextVirtualUniqueID(), sys::TimeValue::now(), 0, 0,
- 0, file_type::directory_file, sys::fs::all_all));
-
-if (!ParentEntry) { // Add a new root to the overlay
-  FS->Roots.push_back(std::move(E));
-  ParentEntry = FS->Roots.back().get();
-  return ParentEntry;
-}
-
-auto *DE = dyn_cast(ParentEntry);
-DE->addContent(std::move(E));
-return DE->getLastContent();
-  }
-
-  void uniqueOverlayTree(RedirectingFileSystem *FS, Entry *SrcE,
- Entry *NewParentE = nullptr) {
-StringRef Name = SrcE->getName();
-switch (SrcE->getKind()) {
-case EK_Directory: {
-  auto *DE = dyn_cast(SrcE);
-  assert(DE && "Must be a directory");
-  // Empty directories could be present in the YAML as a way to
-  // describe a file for a current directory after some of its subdir
-  // is parsed. This only leads to redundant walks, ignore it.
-  if (!Name.empty())
-NewParentE = lookupOrCreateEntry(FS, Name, NewParentE);
-  for (std::unique_ptr &SubEntry :
-   llvm::make_range(DE->contents_begin(), DE->contents_end()))
-uniqueOverlayTree(FS, SubEntry.get(), NewParentE);
-  break;
-}
-case EK_File: {
-  auto *FE = dyn_cast(SrcE);
-  assert(FE && "Must be a file");
-  assert(NewParentE && "Parent entry must exist");
-  auto *DE = dyn_cast(NewParentE);
-  DE->addContent(llvm::make_unique(
-  Name, FE->getExternalContentsPath(), FE->getUseName()));
-  break;
-}
-}
-  }
-
   std::unique_ptr parseEntry(yaml::Node *N, RedirectingFileSystem *FS) {
 yaml::MappingNode *M = dyn_cast(N);
 if (!M) {
@@ -1296,7 +1225,6 @@ public:
 };
 
 DenseMap Keys(std::begin(Fields), std::end(Fields));
-std::vector> RootEntries;
 
 // Parse configuration and 'roots'
 for (yaml::MappingNode::iterator I = Top->begin(), E = Top->end(); I != E;
@@ -1319,7 +1247,7 @@ public:
 for (yaml::SequenceNode::iterator I = Roots->begin(), E = Roots->end();
  I != E; ++I) {
   if (std::unique_ptr E = parseEntry(&*I, FS))
-RootEntries.push_back(std::move(E));
+FS->Roots.push_back(std::move(E));
   else
 return false;
 }
@@ -1360,13 +128

Re: r269100 - [VFS] Reconstruct the VFS overlay tree for more accurate lookup

[Sean Silva via cfe-commits]

Hi Bruno,

I had to revert this in r269100 because it was looking like the bot was
going to be left red overnight.

Changes to this VFS code seem to have a trend of breaking on windows. Any
idea why that is? I can understand things breaking on windows when writing
low-level parts of an FS abstraction, but this patch seems fairly
high-level. Is there a missing layering or something?

-- Sean Silva

On Tue, May 10, 2016 at 11:43 AM, Bruno Cardoso Lopes via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: bruno
> Date: Tue May 10 13:43:00 2016
> New Revision: 269100
>
> URL: http://llvm.org/viewvc/llvm-project?rev=269100&view=rev
> Log:
> [VFS] Reconstruct the VFS overlay tree for more accurate lookup
>
> The way we currently build the internal VFS overlay representation leads
> to inefficient path search and might yield wrong answers when asked for
> recursive or regular directory iteration.
>
> Currently, when reading an YAML file, each YAML root entry is placed
> inside a new root in the filesystem overlay. In the crash reproducer, a
> simple "@import Foundation" currently maps to 43 roots, and when looking
> up paths, we traverse a directory tree for each of these different
> roots, until we find a match (or don't). This has two consequences:
>
> - It's slow.
> - Directory iteration gives incomplete results since it only return
> results within one root - since contents of the same directory can be
> declared inside different roots, the result isn't accurate.
>
> This is in part fault of the way we currently write out the YAML file
> when emitting the crash reproducer - we could generate only one root and
> that would make it fast and correct again. However, we should not rely
> on how the client writes the YAML, but provide a good internal
> representation regardless.
>
> This patch builds a proper virtual directory tree out of the YAML
> representation, allowing faster search and proper iteration. Besides the
> crash reproducer, this potentially benefits other VFS clients.
>
> Modified:
> cfe/trunk/lib/Basic/VirtualFileSystem.cpp
> cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp
>
> Modified: cfe/trunk/lib/Basic/VirtualFileSystem.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/VirtualFileSystem.cpp?rev=269100&r1=269099&r2=269100&view=diff
>
> ==
> --- cfe/trunk/lib/Basic/VirtualFileSystem.cpp (original)
> +++ cfe/trunk/lib/Basic/VirtualFileSystem.cpp Tue May 10 13:43:00 2016
> @@ -719,7 +719,13 @@ public:
>  Status S)
>: Entry(EK_Directory, Name), Contents(std::move(Contents)),
>  S(std::move(S)) {}
> +  RedirectingDirectoryEntry(StringRef Name, Status S)
> +  : Entry(EK_Directory, Name), S(std::move(S)) {}
>Status getStatus() { return S; }
> +  void addContent(std::unique_ptr Content) {
> +Contents.push_back(std::move(Content));
> +  }
> +  Entry *getLastContent() const { return Contents.back().get(); }
>typedef decltype(Contents)::iterator iterator;
>iterator contents_begin() { return Contents.begin(); }
>iterator contents_end() { return Contents.end(); }
> @@ -747,6 +753,7 @@ public:
>  return UseName == NK_NotSet ? GlobalUseExternalName
>  : (UseName == NK_External);
>}
> +  NameKind getUseName() const { return UseName; }
>static bool classof(const Entry *E) { return E->getKind() == EK_File; }
>  };
>
> @@ -1023,6 +1030,70 @@ class RedirectingFileSystemParser {
>  return true;
>}
>
> +  Entry *lookupOrCreateEntry(RedirectingFileSystem *FS, StringRef Name,
> + Entry *ParentEntry = nullptr) {
> +if (!ParentEntry) { // Look for a existent root
> +  for (const std::unique_ptr &Root : FS->Roots) {
> +if (Name.equals(Root->getName())) {
> +  ParentEntry = Root.get();
> +  return ParentEntry;
> +}
> +  }
> +} else { // Advance to the next component
> +  auto *DE = dyn_cast(ParentEntry);
> +  for (std::unique_ptr &Content :
> +   llvm::make_range(DE->contents_begin(), DE->contents_end())) {
> +auto *DirContent =
> dyn_cast(Content.get());
> +if (DirContent && Name.equals(Content->getName()))
> +  return DirContent;
> +  }
> +}
> +
> +// ... or create a new one
> +std::unique_ptr E =
> llvm::make_unique(
> +Name, Status("", getNextVirtualUniqueID(), sys::TimeValue::now(),
> 0, 0,
> + 0, file_type::directory_file, sys::fs::all_all));
> +
> +if (!ParentEntry) { // Add a new root to the overlay
> +  FS->Roots.push_back(std::move(E));
> +  ParentEntry = FS->Roots.back().get();
> +  return ParentEntry;
> +}
> +
> +auto *DE = dyn_cast(ParentEntry);
> +DE->addContent(std::move(E));
> +return DE->getLastContent();
> +  }
> +
> +  void uniqueOverlayTree(RedirectingFileSystem *FS, Entry *SrcE,

Re: r269100 - [VFS] Reconstruct the VFS overlay tree for more accurate lookup

[Sean Silva via cfe-commits]

On Tue, May 10, 2016 at 9:49 PM, Bruno Cardoso Lopes <
bruno.card...@gmail.com> wrote:

> Thanks Sean,
>
> I was about to ask for help and try a 4th attempt, as you noted after
> 3 attempts I was not yet able to make this work on windows though...
>

So sorry! It had gone quiet for a few hours and I wanted to avoid leaving
it red any longer.


> The new tests I added first failed on windows because looks like a
> missing "/" on the dir name forces "\\" to be generated while
> appending the filename instead of "/". After fixing that, now seems
> like the directory iteration on windows has a different order from
> what we are getting on the other platforms, do you know anything about
> this?


Does any platform define a guaranteed directory iteration order? I feel
like depending on it in the first place is unwise (or maybe I'm
misunderstanding? e.g. I'm thinking that we should sort the results of
directory iteration to guarantee a particular order if needed for a
comparison in a test)


> Or can you help me debug it once I land it again?


Sure, but like I mentioned the nature of this error is very troubling to me
(high-level API use running into low-level system issues). It suggests that
there is an incorrect layering or something. I hate these annoying windows
path issues as much as everyone else, so I'd rather we focus energy on
building an appropriate layering to consolidate all the special handling in
one place than to continually band-aid issues as they creep into all parts
of the codebase. VirtualFileSystem.cpp already has quite a bit of technical
debt that violates our policies in this regard (platform-specific #ifdef's
outside libSupport; I count 3 in VirtualFileSystem.cpp which is a huge
number considering how recent that code is).


> I might
> check-in the new tests separately from the rest to make it easier to
> revert.
>

I don't think there's precedent for doing this in LLVM (or at least it
would be considered as bad practice). We typically check in tests alongside
the code being tested specifically to avoid the temptation to leave
untested/broken code in tree.

-- Sean Silva


>
>
>  TEST 'Clang-Unit ::
> Basic/BasicTests.exe/VFSFromYAMLTest.DirectoryIteration' FAILED
> 
> Note: Google Test filter = VFSFromYAMLTest.DirectoryIteration
> [==] Running 1 test from 1 test case.
> [--] Global test environment set-up.
> [--] 1 test from VFSFromYAMLTest
> [ RUN  ] VFSFromYAMLTest.DirectoryIteration
>
>
> C:\Buildbot\Slave\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\unittests\Basic\VirtualFileSystemTest.cpp(379):
> error: Value of: I->getName()
>
>   Actual: { '/' (47, 0x2F), '/' (47, 0x2F), 'r' (114, 0x72), 'o' (111,
> 0x6F), 'o' (111, 0x6F), 't' (116, 0x74), '/' (47, 0x2F), 'b' (98,
> 0x62), 'a' (97, 0x61), 'z' (122, 0x7A), '/' (47, 0x2F), 'c' (99, 0x63)
> }
>
> Expected: *ExpectedIter
>
> Which is: { '/' (47, 0x2F), '/' (47, 0x2F), 'r' (114, 0x72), 'o' (111,
> 0x6F), 'o' (111, 0x6F), 't' (116, 0x74), '/' (47, 0x2F), 'b' (98,
> 0x62), 'a' (97, 0x61), 'z' (122, 0x7A), '/' (47, 0x2F), 'x' (120,
> 0x78) }
>
>
> C:\Buildbot\Slave\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\unittests\Basic\VirtualFileSystemTest.cpp(381):
> error: Value of: ExpectedIter
>
>   Actual: 00C72A87F7E0
>
> Expected: ExpectedEnd
> Which is: 00C72A87F800
> [  FAILED  ] VFSFromYAMLTest.DirectoryIteration (1 ms)
>
>
>
> On Tue, May 10, 2016 at 9:27 PM, Sean Silva  wrote:
> > Hi Bruno,
> >
> > I had to revert this in r269100 because it was looking like the bot was
> > going to be left red overnight.
> >
> > Changes to this VFS code seem to have a trend of breaking on windows. Any
> > idea why that is? I can understand things breaking on windows when
> writing
> > low-level parts of an FS abstraction, but this patch seems fairly
> > high-level. Is there a missing layering or something?
> >
> > -- Sean Silva
> >
> > On Tue, May 10, 2016 at 11:43 AM, Bruno Cardoso Lopes via cfe-commits
> >  wrote:
> >>
> >> Author: bruno
> >> Date: Tue May 10 13:43:00 2016
> >> New Revision: 269100
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=269100&view=rev
> >> Log:
> >> [VFS] Reconstruct the VFS overlay tree for more accurate lookup
> >>
> >> The way we currently build the internal VFS overlay representation leads
> >> to inefficient path search and might yield wrong answers when asked for
> >> recursive or regular directory iteration.
> >>
> >> Currently, when reading an YAML file, each YAML root entry is placed
> >> inside a new root in the filesystem overlay. In the crash reproducer, a
> >> simple "@import Foundation" currently maps to 43 roots, and when looking
> >> up paths, we traverse a directory tree for each of these different
> >> roots, until we find a match (or don't). This has two consequences:
> >>
> >> - It's slow.
> >> - Directory iteration gives incomplete results since it only return
> >> results

Re: r269100 - [VFS] Reconstruct the VFS overlay tree for more accurate lookup

[Sean Silva via cfe-commits]

On Tue, May 10, 2016 at 11:14 PM, Bruno Cardoso Lopes <
bruno.card...@gmail.com> wrote:

> Hi Sean,
>
> > So sorry! It had gone quiet for a few hours and I wanted to avoid
> leaving it
> > red any longer.
>
> No problem, the priority is to get bot greens!
>
> > Does any platform define a guaranteed directory iteration order? I feel
> like
> > depending on it in the first place is unwise (or maybe I'm
> misunderstanding?
> > e.g. I'm thinking that we should sort the results of directory iteration
> to
> > guarantee a particular order if needed for a comparison in a test)
>
> Yes, I was thinking about that too, however I'm not yet sure this is
> actually happening due to iteration order.
>
> >>
> >> Or can you help me debug it once I land it again?
> >
> >
> > Sure, but like I mentioned the nature of this error is very troubling to
> me
> > (high-level API use running into low-level system issues). It suggests
> that
> > there is an incorrect layering or something. I hate these annoying
> windows
> > path issues as much as everyone else, so I'd rather we focus energy on
> > building an appropriate layering to consolidate all the special handling
> in
> > one place than to continually band-aid issues as they creep into all
> parts
> > of the codebase. VirtualFileSystem.cpp already has quite a bit of
> technical
> > debt that violates our policies in this regard (platform-specific
> #ifdef's
> > outside libSupport; I count 3 in VirtualFileSystem.cpp which is a huge
> > number considering how recent that code is).
>
> Totally agree. Part of that is on me - I'm actually relying on
> http://reviews.llvm.org/D19842 as a base to do a proper clean up by
> using a target independent version of realpath. FileManager is likely
> benefiting from that as well (and has itself some layering violations
> I took precedence from). However, I'm not even sure what are the root
> causes that make stuff fails on windows, given that, it's hard to know
> what proper layering should look like, because aside windows-avoid
> hacks, the rest looks fine to me; I count on you then to help me with
> that, feel free to file PRs about anything specific :)
>

I'm glad to help, but it makes me uneasy to have somebody working on a
filesystem abstraction that does not have ready access to test and debug
their changes across the major host platforms that LLVM supports (linux,
mac, windows). Is there any way you can get access? I don't think that
windows 10 is critical here; win7 or win8 are fine.

-- Sean Silva


>
> >>
> >> I might
> >> check-in the new tests separately from the rest to make it easier to
> >> revert.
> >
> >
> > I don't think there's precedent for doing this in LLVM (or at least it
> would
> > be considered as bad practice). We typically check in tests alongside the
> > code being tested specifically to avoid the temptation to leave
> > untested/broken code in tree.
>
> True. However it's kinda subtle in this case: (1) this patch is not
> really a feature, it just re-arranges the tree to allow faster search,
> so the current tests passing should be enough. OTOH, the side-effect
> is that it fixes directory iteration because different roots pointing
> to the same path now can be seen as the same by directory iteration. I
> had the intention to test that, to make sure we don't regress in the
> future. (2) I have no other way to "debug" on windows10-ps4 platform
> besides reducing-by-commit. Anyway, I'm gonna try a more minimal
> testcase first.
>
> --
> Bruno Cardoso Lopes
> http://www.brunocardoso.cc
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r269100 - [VFS] Reconstruct the VFS overlay tree for more accurate lookup

[Sean Silva via cfe-commits]

On Wed, May 11, 2016 at 10:46 AM, Bruno Cardoso Lopes <
bruno.card...@gmail.com> wrote:

> > I'm glad to help, but it makes me uneasy to have somebody working on a
> > filesystem abstraction that does not have ready access to test and debug
> > their changes across the major host platforms that LLVM supports (linux,
> > mac, windows). Is there any way you can get access? I don't think that
> > windows 10 is critical here; win7 or win8 are fine.
>
> I'm mostly trying to make the crash reproducers to work on Darwin;


What are the platform-specifics for crash reproducing? Shouldn't it
basically be saving some files and storing some data for reconstructing?
We've recently been working on a `--reproduce` for LLD and we haven't
needed any ifdefs for windows (some tests that rely on really long path
names need to be turned off, but the feature still works).

-- Sean Silva


> the
> improvements to VFS are in fact side-effects here, not something I'm
> working full time on. It would be awesome to have it working on other
> platforms out-of-the-box, but I just don't have the bandwidth to do
> it. That said, I'm gonna make sure we don't regress on windows, but
> unless I have help or get time to setup such machine, I can't
> guarantee this improvements are going to be supported on windows.
>
> --
> Bruno Cardoso Lopes
> http://www.brunocardoso.cc
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r269309 - [ubsan] Add -fsanitize-undefined-strip-path-components=N

[Sean Silva via cfe-commits]

On Thu, May 12, 2016 at 9:51 AM, Filipe Cabecinhas via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: filcab
> Date: Thu May 12 11:51:36 2016
> New Revision: 269309
>
> URL: http://llvm.org/viewvc/llvm-project?rev=269309&view=rev
> Log:
> [ubsan] Add -fsanitize-undefined-strip-path-components=N
>
> Summary:
> This option allows the user to control how much of the file name is
> emitted by UBSan. Tuning this option allows one to save space in the
> resulting binary, which is helpful for restricted execution
> environments.
>
> With a positive N, UBSan skips the first N path components.
> With a negative N, UBSan only keeps the last N path components.
>
> Reviewers: rsmith
>
> Subscribers: cfe-commits
>
> Differential Revision: http://reviews.llvm.org/D19666
>
> Added:
> cfe/trunk/test/CodeGen/ubsan-strip-path-components.cpp
> cfe/trunk/test/Driver/fubsan-strip-path-components.cpp
> Modified:
> cfe/trunk/docs/UndefinedBehaviorSanitizer.rst
> cfe/trunk/include/clang/Driver/Options.td
> cfe/trunk/include/clang/Frontend/CodeGenOptions.def
> cfe/trunk/lib/CodeGen/CGExpr.cpp
> cfe/trunk/lib/Driver/Tools.cpp
> cfe/trunk/lib/Frontend/CompilerInvocation.cpp
>
> Modified: cfe/trunk/docs/UndefinedBehaviorSanitizer.rst
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/UndefinedBehaviorSanitizer.rst?rev=269309&r1=269308&r2=269309&view=diff
>
> ==
> --- cfe/trunk/docs/UndefinedBehaviorSanitizer.rst (original)
> +++ cfe/trunk/docs/UndefinedBehaviorSanitizer.rst Thu May 12 11:51:36 2016
> @@ -228,6 +228,26 @@ UndefinedBehaviorSanitizer is available
>  3.3. The test suite is integrated into the CMake build and can be run with
>  ``check-ubsan`` command.
>
> +Additional Configuration
> +
> +
> +UndefinedBehaviorSanitizer adds static check data for each check unless
> it is
> +in trap mode. This check data includes the full file name. The option
> +``-fsanitize-undefined-strip-path-components=N`` can be used to trim this
> +information. If ``N`` is positive, file information emitted by
> +UndefinedBehaviorSanitizer will drop the first ``N`` components from the
> file
> +path. If ``N`` is negative, the last ``N`` components will be kept.
> +
> +Example
> +---
> +
> +For a file called ``/code/library/file.cpp``, here is what would be
> emitted:
> +* Default (No flag, or ``-fsanitize-undefined-strip-path-components=0``):
> ``/code/library/file.cpp``
> +* ``-fsanitize-undefined-strip-path-components=1``:
> ``code/library/file.cpp``
> +* ``-fsanitize-undefined-strip-path-components=2``: ``library/file.cpp``
> +* ``-fsanitize-undefined-strip-path-components=-1``: ``file.cpp``
> +* ``-fsanitize-undefined-strip-path-components=-2``: ``library/file.cpp``
>

How are drive letters handled?

-- Sean Silva


> +
>  More Information
>  
>
>
> Modified: cfe/trunk/include/clang/Driver/Options.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=269309&r1=269308&r2=269309&view=diff
>
> ==
> --- cfe/trunk/include/clang/Driver/Options.td (original)
> +++ cfe/trunk/include/clang/Driver/Options.td Thu May 12 11:51:36 2016
> @@ -677,6 +677,10 @@ def fsanitize_stats : Flag<["-"], "fsani
>  def fno_sanitize_stats : Flag<["-"], "fno-sanitize-stats">,
>   Group, Flags<[CC1Option]>,
>   HelpText<"Disable sanitizer statistics
> gathering.">;
> +def fsanitize_undefined_strip_path_components_EQ : Joined<["-"],
> "fsanitize-undefined-strip-path-components=">,
> +  Group, Flags<[CC1Option]>, MetaVarName<"">,
> +  HelpText<"Strip (or keep only, if negative) a given number of path
> components "
> +   "when emitting check metadata.">;
>  def funsafe_math_optimizations : Flag<["-"],
> "funsafe-math-optimizations">,
>Group;
>  def fno_unsafe_math_optimizations : Flag<["-"],
> "fno-unsafe-math-optimizations">,
>
> Modified: cfe/trunk/include/clang/Frontend/CodeGenOptions.def
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/CodeGenOptions.def?rev=269309&r1=269308&r2=269309&view=diff
>
> ==
> --- cfe/trunk/include/clang/Frontend/CodeGenOptions.def (original)
> +++ cfe/trunk/include/clang/Frontend/CodeGenOptions.def Thu May 12
> 11:51:36 2016
> @@ -225,6 +225,10 @@ ENUM_CODEGENOPT(VecLib, VectorLibrary, 1
>  /// The default TLS model to use.
>  ENUM_CODEGENOPT(DefaultTLSModel, TLSModel, 2, GeneralDynamicTLSModel)
>
> +/// Number of path components to strip when emitting checks. (0 == full
> +/// filename)
> +VALUE_CODEGENOPT(EmitCheckPathComponentsToStrip, 32, 0)
> +
>  #undef CODEGENOPT
>  #undef ENUM_CODEGENOPT
>  #undef VALUE_CODEGENOPT
>
> Modified: cfe/trunk/lib/CodeGen/CGExpr.cpp
> URL:
> http:/

Re: r269309 - [ubsan] Add -fsanitize-undefined-strip-path-components=N

[Sean Silva via cfe-commits]

On Fri, May 13, 2016 at 12:01 AM, Filipe Cabecinhas  wrote:

>
> > On 13 May 2016, at 07:03, Sean Silva  wrote:
> >
> >
> >
> > On Thu, May 12, 2016 at 9:51 AM, Filipe Cabecinhas via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
> > Author: filcab
> > Date: Thu May 12 11:51:36 2016
> > New Revision: 269309
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=269309&view=rev
> > Log:
> > [ubsan] Add -fsanitize-undefined-strip-path-components=N
> >
> > Summary:
> > This option allows the user to control how much of the file name is
> > emitted by UBSan. Tuning this option allows one to save space in the
> > resulting binary, which is helpful for restricted execution
> > environments.
> >
> > With a positive N, UBSan skips the first N path components.
> > With a negative N, UBSan only keeps the last N path components.
> >
> > Reviewers: rsmith
> >
> > Subscribers: cfe-commits
> >
> > Differential Revision: http://reviews.llvm.org/D19666
> >
> > Added:
> > cfe/trunk/test/CodeGen/ubsan-strip-path-components.cpp
> > cfe/trunk/test/Driver/fubsan-strip-path-components.cpp
> > Modified:
> > cfe/trunk/docs/UndefinedBehaviorSanitizer.rst
> > cfe/trunk/include/clang/Driver/Options.td
> > cfe/trunk/include/clang/Frontend/CodeGenOptions.def
> > cfe/trunk/lib/CodeGen/CGExpr.cpp
> > cfe/trunk/lib/Driver/Tools.cpp
> > cfe/trunk/lib/Frontend/CompilerInvocation.cpp
> >
> > Modified: cfe/trunk/docs/UndefinedBehaviorSanitizer.rst
> > URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/UndefinedBehaviorSanitizer.rst?rev=269309&r1=269308&r2=269309&view=diff
> >
> ==
> > --- cfe/trunk/docs/UndefinedBehaviorSanitizer.rst (original)
> > +++ cfe/trunk/docs/UndefinedBehaviorSanitizer.rst Thu May 12 11:51:36
> 2016
> > @@ -228,6 +228,26 @@ UndefinedBehaviorSanitizer is available
> >  3.3. The test suite is integrated into the CMake build and can be run
> with
> >  ``check-ubsan`` command.
> >
> > +Additional Configuration
> > +
> > +
> > +UndefinedBehaviorSanitizer adds static check data for each check unless
> it is
> > +in trap mode. This check data includes the full file name. The option
> > +``-fsanitize-undefined-strip-path-components=N`` can be used to trim
> this
> > +information. If ``N`` is positive, file information emitted by
> > +UndefinedBehaviorSanitizer will drop the first ``N`` components from
> the file
> > +path. If ``N`` is negative, the last ``N`` components will be kept.
> > +
> > +Example
> > +---
> > +
> > +For a file called ``/code/library/file.cpp``, here is what would be
> emitted:
> > +* Default (No flag, or
> ``-fsanitize-undefined-strip-path-components=0``):
> ``/code/library/file.cpp``
> > +* ``-fsanitize-undefined-strip-path-components=1``:
> ``code/library/file.cpp``
> > +* ``-fsanitize-undefined-strip-path-components=2``: ``library/file.cpp``
> > +* ``-fsanitize-undefined-strip-path-components=-1``: ``file.cpp``
> > +* ``-fsanitize-undefined-strip-path-components=-2``:
> ``library/file.cpp``
> >
> > How are drive letters handled?
> >
> > -- Sean Silva
>
> Same way as Path iterator:
> ///   /  => /
> ///   /foo   => /,foo
> ///   foo/   => foo,.
> ///   /foo/bar   => /,foo,bar
> ///   ../=> ..,.
> ///   C:\foo\bar => C:,/,foo,bar
>
>
Please mention this in the user-facing documentation.

-- Sean Silva



>   Filipe
>
> >
> > +
> >  More Information
> >  
> >
> >
> > Modified: cfe/trunk/include/clang/Driver/Options.td
> > URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=269309&r1=269308&r2=269309&view=diff
> >
> ==
> > --- cfe/trunk/include/clang/Driver/Options.td (original)
> > +++ cfe/trunk/include/clang/Driver/Options.td Thu May 12 11:51:36 2016
> > @@ -677,6 +677,10 @@ def fsanitize_stats : Flag<["-"], "fsani
> >  def fno_sanitize_stats : Flag<["-"], "fno-sanitize-stats">,
> >   Group,
> Flags<[CC1Option]>,
> >   HelpText<"Disable sanitizer statistics
> gathering.">;
> > +def fsanitize_undefined_strip_path_components_EQ : Joined<["-"],
> "fsanitize-undefined-strip-path-components=">,
> > +  Group, Flags<[CC1Option]>, MetaVarName<"">,
> > +  HelpText<"Strip (or keep only, if negative) a given number of path
> components "
> > +   "when emitting check metadata.">;
> >  def funsafe_math_optimizations : Flag<["-"],
> "funsafe-math-optimizations">,
> >Group;
> >  def fno_unsafe_math_optimizations : Flag<["-"],
> "fno-unsafe-math-optimizations">,
> >
> > Modified: cfe/trunk/include/clang/Frontend/CodeGenOptions.def
> > URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/CodeGenOptions.def?rev=269309&r1=269308&r2=269309&view=diff
> >
> =

Re: r269765 - Revert "[X86] Add immediate range checks for many of the builtins."

[Sean Silva via cfe-commits]

On Tue, May 17, 2016 at 7:07 AM, Filipe Cabecinhas via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: filcab
> Date: Tue May 17 09:07:43 2016
> New Revision: 269765
>
> URL: http://llvm.org/viewvc/llvm-project?rev=269765&view=rev
> Log:
> Revert "[X86] Add immediate range checks for many of the builtins."
>
> This reverts commit r269619.
>

In the future could you include the reason too?

-- Sean Silva


>
> Modified:
> cfe/trunk/lib/Sema/SemaChecking.cpp
> cfe/trunk/test/CodeGen/avx512vl-builtins.c
>
> Modified: cfe/trunk/lib/Sema/SemaChecking.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaChecking.cpp?rev=269765&r1=269764&r2=269765&view=diff
>
> ==
> --- cfe/trunk/lib/Sema/SemaChecking.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaChecking.cpp Tue May 17 09:07:43 2016
> @@ -1323,52 +1323,23 @@ bool Sema::CheckX86BuiltinFunctionCall(u
>  return SemaBuiltinCpuSupports(*this, TheCall);
>case X86::BI__builtin_ms_va_start:
>  return SemaBuiltinMSVAStart(TheCall);
> -  case X86::BI__builtin_ia32_extractf64x4_mask:
> -  case X86::BI__builtin_ia32_extracti64x4_mask:
> -  case X86::BI__builtin_ia32_extractf32x8_mask:
> -  case X86::BI__builtin_ia32_extracti32x8_mask:
> -  case X86::BI__builtin_ia32_extractf64x2_256_mask:
> -  case X86::BI__builtin_ia32_extracti64x2_256_mask:
> -  case X86::BI__builtin_ia32_extractf32x4_256_mask:
> -  case X86::BI__builtin_ia32_extracti32x4_256_mask:
> -i = 1; l = 0; u = 1;
> -break;
>case X86::BI_mm_prefetch:
> -  case X86::BI__builtin_ia32_extractf32x4_mask:
> -  case X86::BI__builtin_ia32_extracti32x4_mask:
> -  case X86::BI__builtin_ia32_vpermilpd_mask:
> -  case X86::BI__builtin_ia32_vpermilps_mask:
> -  case X86::BI__builtin_ia32_extractf64x2_512_mask:
> -  case X86::BI__builtin_ia32_extracti64x2_512_mask:
> -i = 1; l = 0; u = 3;
> -break;
> -  case X86::BI__builtin_ia32_insertf32x8_mask:
> -  case X86::BI__builtin_ia32_inserti32x8_mask:
> -  case X86::BI__builtin_ia32_insertf64x4_mask:
> -  case X86::BI__builtin_ia32_inserti64x4_mask:
> -  case X86::BI__builtin_ia32_insertf64x2_256_mask:
> -  case X86::BI__builtin_ia32_inserti64x2_256_mask:
> -  case X86::BI__builtin_ia32_insertf32x4_256_mask:
> -  case X86::BI__builtin_ia32_inserti32x4_256_mask:
> -i = 2; l = 0; u = 1;
> +i = 1;
> +l = 0;
> +u = 3;
>  break;
>case X86::BI__builtin_ia32_sha1rnds4:
> -  case X86::BI__builtin_ia32_shuf_f32x4_256_mask:
> -  case X86::BI__builtin_ia32_shuf_f64x2_256_mask:
> -  case X86::BI__builtin_ia32_shuf_i32x4_256_mask:
> -  case X86::BI__builtin_ia32_shuf_i64x2_256_mask:
> -  case X86::BI__builtin_ia32_shufpd128_mask:
> -  case X86::BI__builtin_ia32_insertf64x2_512_mask:
> -  case X86::BI__builtin_ia32_inserti64x2_512_mask:
> -  case X86::BI__builtin_ia32_insertf32x4_mask:
> -  case X86::BI__builtin_ia32_inserti32x4_mask:
> -i = 2; l = 0; u = 3;
> +i = 2;
> +l = 0;
> +u = 3;
>  break;
>case X86::BI__builtin_ia32_vpermil2pd:
>case X86::BI__builtin_ia32_vpermil2pd256:
>case X86::BI__builtin_ia32_vpermil2ps:
>case X86::BI__builtin_ia32_vpermil2ps256:
> -i = 3; l = 0; u = 3;
> +i = 3;
> +l = 0;
> +u = 3;
>  break;
>case X86::BI__builtin_ia32_cmpb128_mask:
>case X86::BI__builtin_ia32_cmpw128_mask:
> @@ -1394,36 +1365,23 @@ bool Sema::CheckX86BuiltinFunctionCall(u
>case X86::BI__builtin_ia32_ucmpw512_mask:
>case X86::BI__builtin_ia32_ucmpd512_mask:
>case X86::BI__builtin_ia32_ucmpq512_mask:
> -  case X86::BI__builtin_ia32_vpcomub:
> -  case X86::BI__builtin_ia32_vpcomuw:
> -  case X86::BI__builtin_ia32_vpcomud:
> -  case X86::BI__builtin_ia32_vpcomuq:
> -  case X86::BI__builtin_ia32_vpcomb:
> -  case X86::BI__builtin_ia32_vpcomw:
> -  case X86::BI__builtin_ia32_vpcomd:
> -  case X86::BI__builtin_ia32_vpcomq:
> -i = 2; l = 0; u = 7;
> +i = 2;
> +l = 0;
> +u = 7;
>  break;
>case X86::BI__builtin_ia32_roundps:
>case X86::BI__builtin_ia32_roundpd:
>case X86::BI__builtin_ia32_roundps256:
>case X86::BI__builtin_ia32_roundpd256:
> -  case X86::BI__builtin_ia32_vpermilpd256_mask:
> -  case X86::BI__builtin_ia32_vpermilps256_mask:
> -i = 1; l = 0; u = 15;
> +i = 1;
> +l = 0;
> +u = 15;
>  break;
>case X86::BI__builtin_ia32_roundss:
>case X86::BI__builtin_ia32_roundsd:
> -  case X86::BI__builtin_ia32_rangepd128_mask:
> -  case X86::BI__builtin_ia32_rangepd256_mask:
> -  case X86::BI__builtin_ia32_rangepd512_mask:
> -  case X86::BI__builtin_ia32_rangeps128_mask:
> -  case X86::BI__builtin_ia32_rangeps256_mask:
> -  case X86::BI__builtin_ia32_rangeps512_mask:
> -  case X86::BI__builtin_ia32_getmantsd_round_mask:
> -  case X86::BI__builtin_ia32_getmantss_round_mask:
> -  case X86::BI__builtin_ia32_shufpd256_mask:
> -i = 2; l = 0; u = 15;
> +i = 2;
> +l = 0;
> +u = 15;
>  break;

Re: r269910 - Update for llvm change.

[Sean Silva via cfe-commits]

On Wed, May 18, 2016 at 4:58 AM, Rafael Espindola via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rafael
> Date: Wed May 18 06:58:56 2016
> New Revision: 269910
>
> URL: http://llvm.org/viewvc/llvm-project?rev=269910&view=rev
> Log:
> Update for llvm change.
>
> Modified:
> cfe/trunk/lib/Parse/ParseStmtAsm.cpp
> cfe/trunk/tools/driver/cc1as_main.cpp
>
> Modified: cfe/trunk/lib/Parse/ParseStmtAsm.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseStmtAsm.cpp?rev=269910&r1=269909&r2=269910&view=diff
>
> ==
> --- cfe/trunk/lib/Parse/ParseStmtAsm.cpp (original)
> +++ cfe/trunk/lib/Parse/ParseStmtAsm.cpp Wed May 18 06:58:56 2016
> @@ -572,8 +572,8 @@ StmtResult Parser::ParseMicrosoftAsmStat
>
>llvm::SourceMgr TempSrcMgr;
>llvm::MCContext Ctx(MAI.get(), MRI.get(), MOFI.get(), &TempSrcMgr);
> -  MOFI->InitMCObjectFileInfo(TheTriple, llvm::Reloc::Default,
> - llvm::CodeModel::Default, Ctx);
> +  MOFI->InitMCObjectFileInfo(TheTriple, /*PIG*/ false,
> llvm::CodeModel::Default,
>

Did you mean "PIC" here insted of PIG?

-- Sean Silva


> + Ctx);
>std::unique_ptr Buffer =
>llvm::MemoryBuffer::getMemBuffer(AsmString, "");
>
>
> Modified: cfe/trunk/tools/driver/cc1as_main.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/driver/cc1as_main.cpp?rev=269910&r1=269909&r2=269910&view=diff
>
> ==
> --- cfe/trunk/tools/driver/cc1as_main.cpp (original)
> +++ cfe/trunk/tools/driver/cc1as_main.cpp Wed May 18 06:58:56 2016
> @@ -326,19 +326,18 @@ static bool ExecuteAssembler(AssemblerIn
>
>MCContext Ctx(MAI.get(), MRI.get(), MOFI.get(), &SrcMgr);
>
> -  llvm::Reloc::Model RM = llvm::Reloc::Default;
> +  bool PIC = false;
>if (Opts.RelocationModel == "static") {
> -RM = llvm::Reloc::Static;
> +PIC = false;
>} else if (Opts.RelocationModel == "pic") {
> -RM = llvm::Reloc::PIC_;
> +PIC = true;
>} else {
>  assert(Opts.RelocationModel == "dynamic-no-pic" &&
> "Invalid PIC model!");
> -RM = llvm::Reloc::DynamicNoPIC;
> +PIC = false;
>}
>
> -  MOFI->InitMCObjectFileInfo(Triple(Opts.Triple), RM,
> - CodeModel::Default, Ctx);
> +  MOFI->InitMCObjectFileInfo(Triple(Opts.Triple), PIC,
> CodeModel::Default, Ctx);
>if (Opts.SaveTemporaryLabels)
>  Ctx.setAllowTemporaryLabels(false);
>if (Opts.GenDwarfForAssembly)
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r270009 - Make Sema::getPrintingPolicy less ridiculously expensive. This used to perform

[Sean Silva via cfe-commits]

On Wed, May 18, 2016 at 6:39 PM, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rsmith
> Date: Wed May 18 20:39:10 2016
> New Revision: 270009
>
> URL: http://llvm.org/viewvc/llvm-project?rev=270009&view=rev
> Log:
> Make Sema::getPrintingPolicy less ridiculously expensive. This used to
> perform
> an identifier table lookup, *and* copy the LangOptions (including various
> std::vectors). Twice. We call this function once each time we
> start
> parsing a declaration specifier sequence, and once for each call to
> Sema::Diag.
>
> This reduces the compile time for a sample .c file from the linux kernel
> by 20%.
>
> Modified:
> cfe/trunk/include/clang/AST/ASTContext.h
> cfe/trunk/include/clang/AST/PrettyPrinter.h
> cfe/trunk/lib/AST/DeclarationName.cpp
> cfe/trunk/lib/AST/StmtPrinter.cpp
> cfe/trunk/lib/AST/TypePrinter.cpp
> cfe/trunk/lib/Parse/ParseDecl.cpp
> cfe/trunk/lib/Sema/Sema.cpp
> cfe/trunk/lib/Sema/SemaCodeComplete.cpp
> cfe/trunk/test/Analysis/initializers-cfg-output.cpp
> cfe/trunk/test/Analysis/temp-obj-dtors-cfg-output.cpp
> cfe/trunk/test/SemaCXX/member-pointer.cpp
>
> Modified: cfe/trunk/include/clang/AST/ASTContext.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ASTContext.h?rev=270009&r1=270008&r2=270009&view=diff
>
> ==
> --- cfe/trunk/include/clang/AST/ASTContext.h (original)
> +++ cfe/trunk/include/clang/AST/ASTContext.h Wed May 18 20:39:10 2016
> @@ -243,6 +243,9 @@ class ASTContext : public RefCountedBase
>QualType ObjCClassRedefinitionType;
>QualType ObjCSelRedefinitionType;
>
> +  /// The identifier 'bool'.
> +  mutable IdentifierInfo *BoolName = nullptr;
> +
>/// The identifier 'NSObject'.
>IdentifierInfo *NSObjectName = nullptr;
>
> @@ -1457,6 +1460,13 @@ public:
>  return NSCopyingName;
>}
>
> +  /// Retrieve the identifier 'bool'.
> +  IdentifierInfo *getBoolName() const {
> +if (!BoolName)
> +  BoolName = &Idents.get("bool");
> +return BoolName;
> +  }
> +
>IdentifierInfo *getMakeIntegerSeqName() const {
>  if (!MakeIntegerSeqName)
>MakeIntegerSeqName = &Idents.get("__make_integer_seq");
>
> Modified: cfe/trunk/include/clang/AST/PrettyPrinter.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/PrettyPrinter.h?rev=270009&r1=270008&r2=270009&view=diff
>
> ==
> --- cfe/trunk/include/clang/AST/PrettyPrinter.h (original)
> +++ cfe/trunk/include/clang/AST/PrettyPrinter.h Wed May 18 20:39:10 2016
> @@ -32,22 +32,35 @@ public:
>
>  /// \brief Describes how types, statements, expressions, and
>  /// declarations should be printed.
> +///
> +/// This type is intended to be small and suitable for passing by value.
> +/// It is very frequently copied.
>  struct PrintingPolicy {
> -  /// \brief Create a default printing policy for C.
> +  /// \brief Create a default printing policy for the specified language.
>PrintingPolicy(const LangOptions &LO)
> -: LangOpts(LO), Indentation(2), SuppressSpecifiers(false),
> -  SuppressTagKeyword(false),
> +: Indentation(2), SuppressSpecifiers(false),
> +  SuppressTagKeyword(LO.CPlusPlus),
>IncludeTagDefinition(false), SuppressScope(false),
>SuppressUnwrittenScope(false), SuppressInitializers(false),
>ConstantArraySizeAsWritten(false), AnonymousTagLocations(true),
>SuppressStrongLifetime(false), SuppressLifetimeQualifiers(false),
>SuppressTemplateArgsInCXXConstructors(false),
> -  Bool(LO.Bool), TerseOutput(false), PolishForDeclaration(false),
> +  Bool(LO.Bool), Restrict(LO.C99),
> +  Alignof(LO.CPlusPlus11), UnderscoreAlignof(LO.C11),
> +  UseVoidForZeroParams(!LO.CPlusPlus),
> +  TerseOutput(false), PolishForDeclaration(false),
>Half(LO.Half), MSWChar(LO.MicrosoftExt && !LO.WChar),
>IncludeNewlines(true), MSVCFormatting(false) { }
>
> -  /// \brief What language we're printing.
> -  LangOptions LangOpts;
> +  /// \brief Adjust this printing policy for cases where it's known that
> +  /// we're printing C++ code (for instance, if AST dumping reaches a
> +  /// C++-only construct). This should not be used if a real LangOptions
> +  /// object is available.
> +  void adjustForCPlusPlus() {
> +SuppressTagKeyword = true;
> +Bool = true;
> +UseVoidForZeroParams = false;
> +  }
>
>/// \brief The number of spaces to use to indent each line.
>unsigned Indentation : 8;
> @@ -143,10 +156,23 @@ struct PrintingPolicy {
>/// constructors.
>unsigned SuppressTemplateArgsInCXXConstructors : 1;
>
> -  /// \brief Whether we can use 'bool' rather than '_Bool', even if the
> language
> -  /// doesn't actually have 'bool' (because, e.g., it is defined as a
> macro).
> +  /// \brief Whether we can use 'bool' rather than '_Bool' (eve

Re: r270009 - Make Sema::getPrintingPolicy less ridiculously expensive. This used to perform

[Sean Silva via cfe-commits]

Ah, just saw 270010

On Wed, May 18, 2016 at 6:49 PM, Sean Silva  wrote:

>
>
> On Wed, May 18, 2016 at 6:39 PM, Richard Smith via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: rsmith
>> Date: Wed May 18 20:39:10 2016
>> New Revision: 270009
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=270009&view=rev
>> Log:
>> Make Sema::getPrintingPolicy less ridiculously expensive. This used to
>> perform
>> an identifier table lookup, *and* copy the LangOptions (including various
>> std::vectors). Twice. We call this function once each time
>> we start
>> parsing a declaration specifier sequence, and once for each call to
>> Sema::Diag.
>>
>> This reduces the compile time for a sample .c file from the linux kernel
>> by 20%.
>>
>> Modified:
>> cfe/trunk/include/clang/AST/ASTContext.h
>> cfe/trunk/include/clang/AST/PrettyPrinter.h
>> cfe/trunk/lib/AST/DeclarationName.cpp
>> cfe/trunk/lib/AST/StmtPrinter.cpp
>> cfe/trunk/lib/AST/TypePrinter.cpp
>> cfe/trunk/lib/Parse/ParseDecl.cpp
>> cfe/trunk/lib/Sema/Sema.cpp
>> cfe/trunk/lib/Sema/SemaCodeComplete.cpp
>> cfe/trunk/test/Analysis/initializers-cfg-output.cpp
>> cfe/trunk/test/Analysis/temp-obj-dtors-cfg-output.cpp
>> cfe/trunk/test/SemaCXX/member-pointer.cpp
>>
>> Modified: cfe/trunk/include/clang/AST/ASTContext.h
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ASTContext.h?rev=270009&r1=270008&r2=270009&view=diff
>>
>> ==
>> --- cfe/trunk/include/clang/AST/ASTContext.h (original)
>> +++ cfe/trunk/include/clang/AST/ASTContext.h Wed May 18 20:39:10 2016
>> @@ -243,6 +243,9 @@ class ASTContext : public RefCountedBase
>>QualType ObjCClassRedefinitionType;
>>QualType ObjCSelRedefinitionType;
>>
>> +  /// The identifier 'bool'.
>> +  mutable IdentifierInfo *BoolName = nullptr;
>> +
>>/// The identifier 'NSObject'.
>>IdentifierInfo *NSObjectName = nullptr;
>>
>> @@ -1457,6 +1460,13 @@ public:
>>  return NSCopyingName;
>>}
>>
>> +  /// Retrieve the identifier 'bool'.
>> +  IdentifierInfo *getBoolName() const {
>> +if (!BoolName)
>> +  BoolName = &Idents.get("bool");
>> +return BoolName;
>> +  }
>> +
>>IdentifierInfo *getMakeIntegerSeqName() const {
>>  if (!MakeIntegerSeqName)
>>MakeIntegerSeqName = &Idents.get("__make_integer_seq");
>>
>> Modified: cfe/trunk/include/clang/AST/PrettyPrinter.h
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/PrettyPrinter.h?rev=270009&r1=270008&r2=270009&view=diff
>>
>> ==
>> --- cfe/trunk/include/clang/AST/PrettyPrinter.h (original)
>> +++ cfe/trunk/include/clang/AST/PrettyPrinter.h Wed May 18 20:39:10 2016
>> @@ -32,22 +32,35 @@ public:
>>
>>  /// \brief Describes how types, statements, expressions, and
>>  /// declarations should be printed.
>> +///
>> +/// This type is intended to be small and suitable for passing by value.
>> +/// It is very frequently copied.
>>  struct PrintingPolicy {
>> -  /// \brief Create a default printing policy for C.
>> +  /// \brief Create a default printing policy for the specified language.
>>PrintingPolicy(const LangOptions &LO)
>> -: LangOpts(LO), Indentation(2), SuppressSpecifiers(false),
>> -  SuppressTagKeyword(false),
>> +: Indentation(2), SuppressSpecifiers(false),
>> +  SuppressTagKeyword(LO.CPlusPlus),
>>IncludeTagDefinition(false), SuppressScope(false),
>>SuppressUnwrittenScope(false), SuppressInitializers(false),
>>ConstantArraySizeAsWritten(false), AnonymousTagLocations(true),
>>SuppressStrongLifetime(false), SuppressLifetimeQualifiers(false),
>>SuppressTemplateArgsInCXXConstructors(false),
>> -  Bool(LO.Bool), TerseOutput(false), PolishForDeclaration(false),
>> +  Bool(LO.Bool), Restrict(LO.C99),
>> +  Alignof(LO.CPlusPlus11), UnderscoreAlignof(LO.C11),
>> +  UseVoidForZeroParams(!LO.CPlusPlus),
>> +  TerseOutput(false), PolishForDeclaration(false),
>>Half(LO.Half), MSWChar(LO.MicrosoftExt && !LO.WChar),
>>IncludeNewlines(true), MSVCFormatting(false) { }
>>
>> -  /// \brief What language we're printing.
>> -  LangOptions LangOpts;
>> +  /// \brief Adjust this printing policy for cases where it's known that
>> +  /// we're printing C++ code (for instance, if AST dumping reaches a
>> +  /// C++-only construct). This should not be used if a real LangOptions
>> +  /// object is available.
>> +  void adjustForCPlusPlus() {
>> +SuppressTagKeyword = true;
>> +Bool = true;
>> +UseVoidForZeroParams = false;
>> +  }
>>
>>/// \brief The number of spaces to use to indent each line.
>>unsigned Indentation : 8;
>> @@ -143,10 +156,23 @@ struct PrintingPolicy {
>>/// constructors.
>>unsigned SuppressTemplateArgsInCXXConstructors : 1;
>>
>> -  /// \brief Whether we can use '

Re: [PATCH] D20404: [Driver] Fix driver support for color diagnostics

[Sean Silva via cfe-commits]

silvas added a subscriber: silvas.
silvas added a comment.

I don't see an issue with putthing this as a helper in libBasic. We may need to 
add a libOption dependency to it but that sounds fine.


http://reviews.llvm.org/D20404



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r266719 - Warn if function or variable cannot be implicitly instantiated

[Sean Silva via cfe-commits]

On Thu, Apr 21, 2016 at 12:44 AM, Serge Pavlov  wrote:

> Let me demonstrate the problem using excerpt from v8 sources:
>
> -- lithium.h 
> template 
> struct LSubKindOperand {
>   static int* Create(int index) { return &cache[index]; }
>   static void SetUpCache();
>   static int* cache;
> };
>
> struct LOperand {
>   static void SetUpCaches();
> };
>
> #define LITHIUM_OPERAND_LIST(V)   \
>   V(DoubleRegister,  1,   16)
>
> #define LITHIUM_TYPEDEF_SUBKIND_OPERAND_CLASS(name, type, number)   \
> typedef LSubKindOperand L##name;
> LITHIUM_OPERAND_LIST(LITHIUM_TYPEDEF_SUBKIND_OPERAND_CLASS)
> /* Expands to: typedef LSubKindOperand<1, 16> LDoubleRegister; */
> #undef LITHIUM_TYPEDEF_SUBKIND_OPERAND_CLASS
>
> -- lithium.cc
> #include "lithium.h"
>
> template
> int* LSubKindOperand::cache = 0;
>
> template
> void LSubKindOperand::SetUpCache() {
>   cache = new int[kNumCachedOperands];
> }
>
> void LOperand::SetUpCaches() {
> #define LITHIUM_OPERAND_SETUP(name, type, number) L##name::SetUpCache();
>   LITHIUM_OPERAND_LIST(LITHIUM_OPERAND_SETUP)
>   /* Expands to: LDoubleRegister::SetUpCache(); */
> #undef LITHIUM_OPERAND_SETUP
> }
>
> -- lithium-x64.cc ---
> #include "lithium.h"
>
> int* GetNextSpillSlot(int kind) {
>   return LSubKindOperand<1,16>::Create(0);
> }
>
> int main(int argc, char *argv[]) {
>   return 0;
> }
>
> -- build.sh -
> g++ lithium.cc lithium-x64.cc
> -
>
> When compiler generates code for 'GetNextSpillSlot' it implicitly
> instantiates the method 'Create'. It can do it as definition of the
> template entity 'LSubKindOperand::Create' is available from lithium.h. Then
> it attempts to instantiate static field 'LSubKindOperand::cache', as it is
> used in the body of just instantiated method 'Create'. But definition of
> this template entity  is not available while compiling lithium-x64.cc.
> Failure to implicitly instantiate a template is not an error, but this
> template must be instantiated somewhere else otherwise linker founds
> undefined references.
>
> Indeed, 'LSubKindOperand<1,16>::cache' is instantiated while compiling
> lithium.cc. Method 'LOperand::SetUpCaches' is not a template, it references
> 'LSubKindOperand::SetUpCache', which in turn uses 'LSubKindOperand::cache'.
> Definitions of these templates are available in lithium.cc, compiler
> instantiates them and the program builds successfully. This solution is
> fragile however, if lithium-x64.cc referenced
> 'LSubKindOperand<1,1>::Create', the build would break because in lithium.cc
> this specialization is not instantiated.
>
> Putting templates definitions into source files rather than headers is
> similar to moving forward declarations into source files. It makes sense if
> user wants to encapsulate some functionality. In this example he should
> also move the definition 'LSubKindOperand::Create' to source file, just for
> the sake of encapsulation. This would prevent compiler from implicit
> instantiation of this method and thus from instantiation of the static
> field as well.
>
> If encapsulation is not an aim, moving template definition into header
> seems to be more natural solution. It would allow for compiler to
> instantiate all entities implicitly.
>
> Static variables of template classes are a source of confusion for some
> reason. Probably people tend to confuse them with static member template
> specializations. Anyway this type of errors is too widespread, the
> aforementioned https://llvm.org/bugs/show_bug.cgi?id=24425 is just one
> example.  The change introduced in r266719 attempts to provide user with
> some assistance in these cases.
>
> I don't know details about  Singleton, but only existence of static
> fields should not produce the warning. There must be a reference to the
> field in some method defined inline. Solution could be similar: either the
> method that references the static field should be encapsulated into source
> file or the static field template should be exposed in header.
>
The use case of Singleton I gave wasn't complete. It was more like this:

template 
struct Singleton {
... other stuff ...
  static T *getInstance() { return Singleton::instance; }
private:
  static T *instance;
};

Making the method private to a .cpp file would defeat the entire purpose of
having the class.

-- Sean Silva


> 2016-04-21 5:36 GMT+06:00 Sean Silva :
>
>>
>>
>> On Tue, Apr 19, 2016 at 7:28 AM, Nico Weber via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> (sorry, accidentally sent this mid-mail)
>>>
>>> ../../v8/src/crankshaft/lithium.h:322:45: error: instantiation of
>>> variable
>>> 'v8::internal::LSubKindOperand>> 128>::cache' required here, but no definition is available
>>> [-Werror,-Wundefined-var-t

Re: r266719 - Warn if function or variable cannot be implicitly instantiated

[Sean Silva via cfe-commits]

On Thu, May 19, 2016 at 12:13 PM, Serge Pavlov  wrote:

> In this case moving implementation of `Singleton::getInstance()` into a
> .cpp file would prevent compiler from instantiation of the method body when
> it sees `Singleton::getInstance()`. In this case
> `Singleton::getInstance()` must be instantiated in some source file
> either explicitly or implicitly. If inline implementation for
> `Singleton::getInstance()` is provided in the header, where
> `Singleton` is defined, the method body is instantiated implicitly when
> it is required. But the static field `instance` referenced in the method
> still must be instantiated in some source file explicitly or implicitly. So
> from viewpoint of convenience, moving the implementation of template
> `Singleton::getInstance()` into source file does not look as more
> inflexible solution.
>
> Probably it is more convenient to put the template for the static member
> to header file too:
>
> template 
> T *Singleton::instance = nullptr;
>
>
> In this case both the method and corresponding static member are
> instantiated implicitly by compiler, no warning occurs.
> Can it be an acceptable solution?
>

I think that is what makes the most sense in this scenario (and it
simplifies things for clients of the library).
Unfortunately, for the library that was producing this warning they already
required clients to provide explicit instantiations in a .cpp file (they
had a macro like `DEFINE_SINGLETON_INSTANCE(T)` which a user would place in
a .cpp file to instantiate Singleton::instance for their type).

So fixing this warning like this would have a compatibility concern.

Thankfully, it seems like some compilers (not clang) have a bug in that
they will emit Singleton::instance any time that Singleton is
instantiated unless they have already seen an explicit instantiation
declaration of Singleton::instance in a header, so this library
already had (under an #if) explicit instantiations for
Singleton::instance for all classes that needed it in order to work
around this compiler bug. So in the end I fixed this by just enabling those
ifdefs so that clang would see the Singleton::instance explicitly
declared in the header.
(This is sort of a strange coincidence, but it worked out nicely)



>
> If there is intention to limit `Singleton` to some selected types,
> explicit instantiation declaration may help. Adding the declarations like:
>
> extern template Foo *Singleton::instance;
>
>
> prevents from warnings.
>
> Or you think that the message should propose moving static member
> definition into header file as well?
>

I'm not sure, but I think that the current diagnostics are not very
actionable. Hopefully google will lead users to your description in this
thread. I wish we had something like
https://doc.rust-lang.org/error-index.html where we could officially
provide a more in-depth explanation similar to your posts in this thread.

-- Sean Silva


>
>
> Thanks,
> --Serge
>
> 2016-05-19 9:15 GMT+06:00 Sean Silva :
>
>>
>>
>> On Thu, Apr 21, 2016 at 12:44 AM, Serge Pavlov 
>> wrote:
>>
>>> Let me demonstrate the problem using excerpt from v8 sources:
>>>
>>> -- lithium.h 
>>> template 
>>> struct LSubKindOperand {
>>>   static int* Create(int index) { return &cache[index]; }
>>>   static void SetUpCache();
>>>   static int* cache;
>>> };
>>>
>>> struct LOperand {
>>>   static void SetUpCaches();
>>> };
>>>
>>> #define LITHIUM_OPERAND_LIST(V)   \
>>>   V(DoubleRegister,  1,   16)
>>>
>>> #define LITHIUM_TYPEDEF_SUBKIND_OPERAND_CLASS(name, type, number)   \
>>> typedef LSubKindOperand L##name;
>>> LITHIUM_OPERAND_LIST(LITHIUM_TYPEDEF_SUBKIND_OPERAND_CLASS)
>>> /* Expands to: typedef LSubKindOperand<1, 16> LDoubleRegister; */
>>> #undef LITHIUM_TYPEDEF_SUBKIND_OPERAND_CLASS
>>>
>>> -- lithium.cc
>>> #include "lithium.h"
>>>
>>> template
>>> int* LSubKindOperand::cache = 0;
>>>
>>> template
>>> void LSubKindOperand::SetUpCache() {
>>>   cache = new int[kNumCachedOperands];
>>> }
>>>
>>> void LOperand::SetUpCaches() {
>>> #define LITHIUM_OPERAND_SETUP(name, type, number) L##name::SetUpCache();
>>>   LITHIUM_OPERAND_LIST(LITHIUM_OPERAND_SETUP)
>>>   /* Expands to: LDoubleRegister::SetUpCache(); */
>>> #undef LITHIUM_OPERAND_SETUP
>>> }
>>>
>>> -- lithium-x64.cc ---
>>> #include "lithium.h"
>>>
>>> int* GetNextSpillSlot(int kind) {
>>>   return LSubKindOperand<1,16>::Create(0);
>>> }
>>>
>>> int main(int argc, char *argv[]) {
>>>   return 0;
>>> }
>>>
>>> -- build.sh -
>>> g++ lithium.cc lithium-x64.cc
>>> -
>>>
>>> When compiler generates code for 'GetNextSpillSlot' it implicitly
>>> instantiates the method 'Create'. It can do it as definition of the
>>> template entity 'LSubKindOperand::Cr