Re: [clang] 0e3a487 - PR12350: Handle remaining cases permitted by CWG DR 244.

[Alex L via cfe-commits]

Hi Rchard,

Some of our code started triggering the warning you added in this code, but
I'm not sure if the warning is actually valid or not in this case:

https://godbolt.org/z/9fxs3K

namespace geo {
  template
class optional {
optional() { }
~optional();
};
}
template
geo::optional::~optional() // Triggers  ISO C++ requires the name after
'::~' to be found in the same scope as the name before '::~'
{
}

Could you confirm whether or not this warning is valid for our code?

Thanks,
Alex


On Thu, 13 Feb 2020 at 00:52, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Thanks, yes, fixed in llvmorg-11-init-3043-gc1394afb8df.
>
> On Thu, 13 Feb 2020 at 02:58, Kostya Serebryany via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Could this have caused a new ubsan failure?
>>
>> clang/lib/AST/NestedNameSpecifier.cpp:485:23: runtime error: null pointer 
>> passed as argument 2, which is declared to never be null
>>
>>
>> http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/38698/steps/check-clang%20ubsan/logs/stdio
>>
>> On Fri, Feb 7, 2020 at 6:41 PM Richard Smith via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>>
>>> Author: Richard Smith
>>> Date: 2020-02-07T18:40:41-08:00
>>> New Revision: 0e3a48778408b505946e465abf5c77a2ddd4918c
>>>
>>> URL:
>>> https://github.com/llvm/llvm-project/commit/0e3a48778408b505946e465abf5c77a2ddd4918c
>>> DIFF:
>>> https://github.com/llvm/llvm-project/commit/0e3a48778408b505946e465abf5c77a2ddd4918c.diff
>>>
>>> LOG: PR12350: Handle remaining cases permitted by CWG DR 244.
>>>
>>> Also add extension warnings for the cases that are disallowed by the
>>> current rules for destructor name lookup, refactor and simplify the
>>> lookup code, and improve the diagnostic quality when lookup fails.
>>>
>>> The special case we previously supported for converting
>>> p->N::S::~S() from naming a class template into naming a
>>> specialization thereof is subsumed by a more general rule here (which is
>>> also consistent with Clang's historical behavior and that of other
>>> compilers): if we can't find a suitable S in N, also look in N::S.
>>>
>>> The extension warnings are off by default, except for a warning when
>>> lookup for p->N::S::~T() looks for T in scope instead of in N (or N::S).
>>> That seems sufficiently heinous to warn on by default, especially since
>>> we can't support it for a dependent nested-name-specifier.
>>>
>>> Added:
>>>
>>>
>>> Modified:
>>> clang/include/clang/Basic/DiagnosticGroups.td
>>> clang/include/clang/Basic/DiagnosticSemaKinds.td
>>> clang/lib/AST/NestedNameSpecifier.cpp
>>> clang/lib/Sema/DeclSpec.cpp
>>> clang/lib/Sema/SemaExprCXX.cpp
>>> clang/test/CXX/class/class.mem/p13.cpp
>>> clang/test/CXX/drs/dr2xx.cpp
>>> clang/test/CXX/drs/dr3xx.cpp
>>> clang/test/FixIt/fixit.cpp
>>> clang/test/Parser/cxx-decl.cpp
>>> clang/test/SemaCXX/constructor.cpp
>>> clang/test/SemaCXX/destructor.cpp
>>> clang/test/SemaCXX/pseudo-destructors.cpp
>>>
>>> Removed:
>>>
>>>
>>>
>>>
>>> 
>>> diff  --git a/clang/include/clang/Basic/DiagnosticGroups.td
>>> b/clang/include/clang/Basic/DiagnosticGroups.td
>>> index a2bc29986a07..8c54723cdbab 100644
>>> --- a/clang/include/clang/Basic/DiagnosticGroups.td
>>> +++ b/clang/include/clang/Basic/DiagnosticGroups.td
>>> @@ -192,6 +192,7 @@ def CXX2aDesignator : DiagGroup<"c++2a-designator">;
>>>  // designators (including the warning controlled by -Wc++2a-designator).
>>>  def C99Designator : DiagGroup<"c99-designator", [CXX2aDesignator]>;
>>>  def GNUDesignator : DiagGroup<"gnu-designator">;
>>> +def DtorName : DiagGroup<"dtor-name">;
>>>
>>>  def DynamicExceptionSpec
>>>  : DiagGroup<"dynamic-exception-spec",
>>> [DeprecatedDynamicExceptionSpec]>;
>>>
>>> diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td
>>> b/clang/include/clang/Basic/DiagnosticSemaKinds.td
>>> index 9de60d3a8d27..82861f0d5d72 100644
>>> --- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
>>> +++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
>>> @@ -1911,17 +1911,33 @@ def err_destructor_with_params :
>>> Error<"destructor cannot have any parameters">;
>>>  def err_destructor_variadic : Error<"destructor cannot be variadic">;
>>>  def err_destructor_typedef_name : Error<
>>>"destructor cannot be declared using a %select{typedef|type alias}1
>>> %0 of the class name">;
>>> +def err_undeclared_destructor_name : Error<
>>> +  "undeclared identifier %0 in destructor name">;
>>>  def err_destructor_name : Error<
>>>"expected the class name after '~' to name the enclosing class">;
>>> -def err_destructor_class_name : Error<
>>> -  "expected the class name after '~' to name a destructor">;
>>> -def err_ident_in_dtor_not_a_type : Error<
>>> +def err_destructor_name_nontype : Error<
>>> +  "identifier %0 after '~' in destructor name does not name a type">;
>>> 

Re: r373159 - For P0784R7: compute whether a variable has constant destruction if it

[Alex L via cfe-commits]

Hi Richard,

I posted a patch that partially reverts your commit:
https://reviews.llvm.org/D72411. Unfortunately I can't revert it fully.

Thanks,
Alex

On Mon, 11 Nov 2019 at 15:30, Alex L  wrote:

> Here's a reduced test case.
>
> ```
> // OPTIONS: -x objective-c -std=gnu99 -fobjc-arc -emit-llvm
> @interface Foo
> @end
>
> Foo *foo() {
>   static Foo *f = ((void*)0;
>   return f;
> }
> // CHECK-NOT: cxa_guard
> ```
>
> AFAIK clang should not emit C++ guard variables in non-C++ code. Is that
> correct?
>
> On Mon, 11 Nov 2019 at 14:16, Alex L  wrote:
>
>> Hi Richard,
>>
>> I have a question about this commit. It looks like it started emitting
>> `cxa_guard_acquire/release` calls in Objective-C code, for globals with
>> constant initializers, causing link failures for things that don't link
>> with libc++abi. Was that intentional? I'm still working on a reduced
>> test-case that I can post.
>>
>> Thanks,
>> Alex
>>
>> On Sat, 28 Sep 2019 at 22:06, Richard Smith via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: rsmith
>>> Date: Sat Sep 28 22:08:46 2019
>>> New Revision: 373159
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=373159=rev
>>> Log:
>>> For P0784R7: compute whether a variable has constant destruction if it
>>> has a constexpr destructor.
>>>
>>> For constexpr variables, reject if the variable does not have constant
>>> destruction. In all cases, do not emit runtime calls to the destructor
>>> for variables with constant destruction.
>>>
>>> Added:
>>> cfe/trunk/test/CXX/expr/expr.const/p6-2a.cpp
>>> cfe/trunk/test/CodeGenCXX/non-const-init-cxx2a.cpp
>>> Modified:
>>> cfe/trunk/include/clang/AST/Decl.h
>>> cfe/trunk/include/clang/Basic/DiagnosticASTKinds.td
>>> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
>>> cfe/trunk/lib/AST/ASTContext.cpp
>>> cfe/trunk/lib/AST/Decl.cpp
>>> cfe/trunk/lib/AST/ExprConstant.cpp
>>> cfe/trunk/lib/AST/Interp/Interp.cpp
>>> cfe/trunk/lib/AST/TextNodeDumper.cpp
>>> cfe/trunk/lib/CodeGen/CGCall.cpp
>>> cfe/trunk/lib/CodeGen/CGClass.cpp
>>> cfe/trunk/lib/CodeGen/CGDecl.cpp
>>> cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
>>> cfe/trunk/lib/CodeGen/CodeGenModule.cpp
>>> cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
>>> cfe/trunk/lib/Sema/SemaDeclCXX.cpp
>>> cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
>>> cfe/trunk/lib/Serialization/ASTWriterDecl.cpp
>>> cfe/trunk/test/CXX/dcl.dcl/dcl.spec/dcl.constexpr/p9.cpp
>>> cfe/trunk/test/CodeGenCXX/attr-no-destroy-d54344.cpp
>>> cfe/trunk/test/CodeGenCXX/const-init-cxx2a.cpp
>>> cfe/trunk/test/CodeGenCXX/no_destroy.cpp
>>>
>>> Modified: cfe/trunk/include/clang/AST/Decl.h
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Decl.h?rev=373159=373158=373159=diff
>>>
>>> ==
>>> --- cfe/trunk/include/clang/AST/Decl.h (original)
>>> +++ cfe/trunk/include/clang/AST/Decl.h Sat Sep 28 22:08:46 2019
>>> @@ -808,12 +808,19 @@ struct EvaluatedStmt {
>>>/// valid if CheckedICE is true.
>>>bool IsICE : 1;
>>>
>>> +  /// Whether this variable is known to have constant destruction. That
>>> is,
>>> +  /// whether running the destructor on the initial value is a
>>> side-effect
>>> +  /// (and doesn't inspect any state that might have changed during
>>> program
>>> +  /// execution). This is currently only computed if the destructor is
>>> +  /// non-trivial.
>>> +  bool HasConstantDestruction : 1;
>>> +
>>>Stmt *Value;
>>>APValue Evaluated;
>>>
>>> -  EvaluatedStmt() : WasEvaluated(false), IsEvaluating(false),
>>> CheckedICE(false),
>>> -CheckingICE(false), IsICE(false) {}
>>> -
>>> +  EvaluatedStmt()
>>> +  : WasEvaluated(false), IsEvaluating(false), CheckedICE(false),
>>> +CheckingICE(false), IsICE(false), HasConstantDestruction(false)
>>> {}
>>>  };
>>>
>>>  /// Represents a variable declaration or definition.
>>> @@ -1267,6 +1274,14 @@ public:
>>>/// to untyped APValue if the value could not be evaluated.
>>>APValue *getEvaluatedValue() const;
>>>
>>> +  /// Evaluate the destruction of this variable to determine if it
>>> constitutes
>>> +  /// constant destruction.
>>> +  ///
>>> +  /// \pre isInitICE()
>>> +  /// \return \c true if this variable has constant destruction, \c
>>> false if
>>> +  /// not.
>>> +  bool evaluateDestruction(SmallVectorImpl )
>>> const;
>>> +
>>>/// Determines whether it is already known whether the
>>>/// initializer is an integral constant expression or not.
>>>bool isInitKnownICE() const;
>>> @@ -1505,9 +1520,14 @@ public:
>>>// has no definition within this source file.
>>>bool isKnownToBeDefined() const;
>>>
>>> -  /// Do we need to emit an exit-time destructor for this variable?
>>> +  /// Is destruction of this variable entirely suppressed? If so, the
>>> variable
>>> +  /// need not have a usable destructor at all.

Re: Github build status reporting

[Alex L via cfe-commits]

Hi Galina,

Thanks for doing this! I'm curious as to how the buildbot CI communicates
with Github, is the buildbot itself capable of performing the Github API
requests, or do you have an external tool/script that does that?

Thanks,
Alex

On Mon, 25 Nov 2019 at 12:59, Galina Kistanova via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Hello everyone,
>
> I have configured buildbot to report build statuses to github. It is
> running in a pilot mode. Only the following 4 builders annotate revisions
> they build for now:
>
> * llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast
> * llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast
> * llvm-clang-x86_64-expensive-checks-ubuntu
> * llvm-clang-x86_64-win-fast
>
> Please let me know if you have any questions, concerns, or see any issues.
>
> Thanks
>
> Galina
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [clang] 7342912 - [clang][IFS] Driver Pipeline: generate stubs after standard pipeline (3)

[Alex L via cfe-commits]

Hi Puyan,

This commit caused two Clang failures on Darwin:

Clang :: InterfaceStubs/merge-conflict-test.c
Clang :: InterfaceStubs/object-float.c

Here's the build log from out bot:
http://lab.llvm.org:8080/green/job/clang-stage1-RA/3929/console

Can you please resolve the issue with the tests?
Thanks,
Alex

On Wed, 20 Nov 2019 at 14:16, Puyan Lotfi via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

>
> Author: Puyan Lotfi
> Date: 2019-11-20T16:22:50-05:00
> New Revision: 73429126c91c2065c6f6ef29b3eec1b7798502bb
>
> URL:
> https://github.com/llvm/llvm-project/commit/73429126c91c2065c6f6ef29b3eec1b7798502bb
> DIFF:
> https://github.com/llvm/llvm-project/commit/73429126c91c2065c6f6ef29b3eec1b7798502bb.diff
>
> LOG: [clang][IFS] Driver Pipeline: generate stubs after standard pipeline
> (3)
>
> Third Landing Attempt (dropping any linker invocation from clang driver):
>
> Up until now, clang interface stubs has replaced the standard
> PP -> C -> BE -> ASM -> LNK pipeline. With this change, it will happen in
> conjunction with it. So what when you build your code you will get an
> a.out or lib.so as well as an interface stub file.
>
> Example:
>
> clang -shared -o libfoo.so -emit-interface-stubs ...
>
> will generate both a libfoo.so and a libfoo.ifso. The .so file will
> contain the code from the standard compilation pipeline and the .ifso
> file will contain the ELF stub library.
>
> Note: For driver-test.c I've added -S in order to prevent any bot failures
> on
> bots that don't have the proper linker for their native triple. You could
> always
> specify a triple like x86_64-unknown-linux-gnu and on bots like
> x86_64-scei-ps4
> the clang driver would invoke regular ld instead of getting the error
> 'Executable "orbis-ld" doesn't exist!' but on bots like ppc64be and s390x
> you'd
> get an error "/usr/bin/ld: unrecognised emulation mode: elf_x86_64"
>
> Differential Revision: https://reviews.llvm.org/D70274
>
> Added:
> clang/test/InterfaceStubs/driver-test2.c
> clang/test/InterfaceStubs/ppc.cpp
>
> Modified:
> clang/lib/Driver/Driver.cpp
> clang/lib/Driver/ToolChains/InterfaceStubs.cpp
> clang/lib/Driver/Types.cpp
> clang/test/InterfaceStubs/driver-test.c
> clang/test/InterfaceStubs/windows.cpp
>
> Removed:
>
>
>
>
> 
> diff  --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
> index cdf4a579f431..83b5db3b2530 100644
> --- a/clang/lib/Driver/Driver.cpp
> +++ b/clang/lib/Driver/Driver.cpp
> @@ -292,10 +292,6 @@ phases::ID Driver::getFinalPhase(const DerivedArgList
> ,
>   (PhaseArg = DAL.getLastArg(options::OPT_emit_ast))) {
>  FinalPhase = phases::Compile;
>
> -  // clang interface stubs
> -  } else if ((PhaseArg =
> DAL.getLastArg(options::OPT_emit_interface_stubs))) {
> -FinalPhase = phases::IfsMerge;
> -
>// -S only runs up to the backend.
>} else if ((PhaseArg = DAL.getLastArg(options::OPT_S))) {
>  FinalPhase = phases::Backend;
> @@ -3502,6 +3498,68 @@ void Driver::BuildActions(Compilation ,
> DerivedArgList ,
>  Actions.push_back(
>  C.MakeAction(MergerInputs, types::TY_Image));
>
> +  if (Arg *A = Args.getLastArg(options::OPT_emit_interface_stubs)) {
> +llvm::SmallVector PhaseList;
> +if (Args.hasArg(options::OPT_c)) {
> +  llvm::SmallVector
> CompilePhaseList;
> +  types::getCompilationPhases(types::TY_IFS_CPP, CompilePhaseList);
> +  llvm::copy_if(CompilePhaseList, std::back_inserter(PhaseList),
> +[&](phases::ID Phase) { return Phase <=
> phases::Compile; });
> +} else {
> +  types::getCompilationPhases(types::TY_IFS_CPP, PhaseList);
> +}
> +
> +ActionList MergerInputs;
> +
> +for (auto  : Inputs) {
> +  types::ID InputType = I.first;
> +  const Arg *InputArg = I.second;
> +
> +  // Currently clang and the llvm assembler do not support generating
> symbol
> +  // stubs from assembly, so we skip the input on asm files. For ifs
> files
> +  // we rely on the normal pipeline setup in the pipeline setup code
> above.
> +  if (InputType == types::TY_IFS || InputType == types::TY_PP_Asm ||
> +  InputType == types::TY_Asm)
> +continue;
> +
> +  Action *Current = C.MakeAction(*InputArg, InputType);
> +
> +  for (auto Phase : PhaseList) {
> +switch (Phase) {
> +default:
> +  llvm_unreachable(
> +  "IFS Pipeline can only consist of Compile followed by
> IfsMerge.");
> +case phases::Compile: {
> +  // Only IfsMerge (llvm-ifs) can handle .o files by looking for
> ifs
> +  // files where the .o file is located. The compile action can
> not
> +  // handle this.
> +  if (InputType == types::TY_Object)
> +break;
> +
> +  Current = C.MakeAction(Current,
> types::TY_IFS_CPP);
> +  break;
> +}
> +case phases::IfsMerge: 

Re: r373159 - For P0784R7: compute whether a variable has constant destruction if it

[Alex L via cfe-commits]

Here's a reduced test case.

```
// OPTIONS: -x objective-c -std=gnu99 -fobjc-arc -emit-llvm
@interface Foo
@end

Foo *foo() {
  static Foo *f = ((void*)0;
  return f;
}
// CHECK-NOT: cxa_guard
```

AFAIK clang should not emit C++ guard variables in non-C++ code. Is that
correct?

On Mon, 11 Nov 2019 at 14:16, Alex L  wrote:

> Hi Richard,
>
> I have a question about this commit. It looks like it started emitting
> `cxa_guard_acquire/release` calls in Objective-C code, for globals with
> constant initializers, causing link failures for things that don't link
> with libc++abi. Was that intentional? I'm still working on a reduced
> test-case that I can post.
>
> Thanks,
> Alex
>
> On Sat, 28 Sep 2019 at 22:06, Richard Smith via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: rsmith
>> Date: Sat Sep 28 22:08:46 2019
>> New Revision: 373159
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=373159=rev
>> Log:
>> For P0784R7: compute whether a variable has constant destruction if it
>> has a constexpr destructor.
>>
>> For constexpr variables, reject if the variable does not have constant
>> destruction. In all cases, do not emit runtime calls to the destructor
>> for variables with constant destruction.
>>
>> Added:
>> cfe/trunk/test/CXX/expr/expr.const/p6-2a.cpp
>> cfe/trunk/test/CodeGenCXX/non-const-init-cxx2a.cpp
>> Modified:
>> cfe/trunk/include/clang/AST/Decl.h
>> cfe/trunk/include/clang/Basic/DiagnosticASTKinds.td
>> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
>> cfe/trunk/lib/AST/ASTContext.cpp
>> cfe/trunk/lib/AST/Decl.cpp
>> cfe/trunk/lib/AST/ExprConstant.cpp
>> cfe/trunk/lib/AST/Interp/Interp.cpp
>> cfe/trunk/lib/AST/TextNodeDumper.cpp
>> cfe/trunk/lib/CodeGen/CGCall.cpp
>> cfe/trunk/lib/CodeGen/CGClass.cpp
>> cfe/trunk/lib/CodeGen/CGDecl.cpp
>> cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
>> cfe/trunk/lib/CodeGen/CodeGenModule.cpp
>> cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
>> cfe/trunk/lib/Sema/SemaDeclCXX.cpp
>> cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
>> cfe/trunk/lib/Serialization/ASTWriterDecl.cpp
>> cfe/trunk/test/CXX/dcl.dcl/dcl.spec/dcl.constexpr/p9.cpp
>> cfe/trunk/test/CodeGenCXX/attr-no-destroy-d54344.cpp
>> cfe/trunk/test/CodeGenCXX/const-init-cxx2a.cpp
>> cfe/trunk/test/CodeGenCXX/no_destroy.cpp
>>
>> Modified: cfe/trunk/include/clang/AST/Decl.h
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Decl.h?rev=373159=373158=373159=diff
>>
>> ==
>> --- cfe/trunk/include/clang/AST/Decl.h (original)
>> +++ cfe/trunk/include/clang/AST/Decl.h Sat Sep 28 22:08:46 2019
>> @@ -808,12 +808,19 @@ struct EvaluatedStmt {
>>/// valid if CheckedICE is true.
>>bool IsICE : 1;
>>
>> +  /// Whether this variable is known to have constant destruction. That
>> is,
>> +  /// whether running the destructor on the initial value is a
>> side-effect
>> +  /// (and doesn't inspect any state that might have changed during
>> program
>> +  /// execution). This is currently only computed if the destructor is
>> +  /// non-trivial.
>> +  bool HasConstantDestruction : 1;
>> +
>>Stmt *Value;
>>APValue Evaluated;
>>
>> -  EvaluatedStmt() : WasEvaluated(false), IsEvaluating(false),
>> CheckedICE(false),
>> -CheckingICE(false), IsICE(false) {}
>> -
>> +  EvaluatedStmt()
>> +  : WasEvaluated(false), IsEvaluating(false), CheckedICE(false),
>> +CheckingICE(false), IsICE(false), HasConstantDestruction(false)
>> {}
>>  };
>>
>>  /// Represents a variable declaration or definition.
>> @@ -1267,6 +1274,14 @@ public:
>>/// to untyped APValue if the value could not be evaluated.
>>APValue *getEvaluatedValue() const;
>>
>> +  /// Evaluate the destruction of this variable to determine if it
>> constitutes
>> +  /// constant destruction.
>> +  ///
>> +  /// \pre isInitICE()
>> +  /// \return \c true if this variable has constant destruction, \c
>> false if
>> +  /// not.
>> +  bool evaluateDestruction(SmallVectorImpl )
>> const;
>> +
>>/// Determines whether it is already known whether the
>>/// initializer is an integral constant expression or not.
>>bool isInitKnownICE() const;
>> @@ -1505,9 +1520,14 @@ public:
>>// has no definition within this source file.
>>bool isKnownToBeDefined() const;
>>
>> -  /// Do we need to emit an exit-time destructor for this variable?
>> +  /// Is destruction of this variable entirely suppressed? If so, the
>> variable
>> +  /// need not have a usable destructor at all.
>>bool isNoDestroy(const ASTContext &) const;
>>
>> +  /// Do we need to emit an exit-time destructor for this variable, and
>> if so,
>> +  /// what kind?
>> +  QualType::DestructionKind needsDestruction(const ASTContext )
>> const;
>> +
>>// Implement isa/cast/dyncast/etc.
>>static bool classof(const Decl *D) { return 

Re: r373159 - For P0784R7: compute whether a variable has constant destruction if it

[Alex L via cfe-commits]

Hi Richard,

I have a question about this commit. It looks like it started emitting
`cxa_guard_acquire/release` calls in Objective-C code, for globals with
constant initializers, causing link failures for things that don't link
with libc++abi. Was that intentional? I'm still working on a reduced
test-case that I can post.

Thanks,
Alex

On Sat, 28 Sep 2019 at 22:06, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rsmith
> Date: Sat Sep 28 22:08:46 2019
> New Revision: 373159
>
> URL: http://llvm.org/viewvc/llvm-project?rev=373159=rev
> Log:
> For P0784R7: compute whether a variable has constant destruction if it
> has a constexpr destructor.
>
> For constexpr variables, reject if the variable does not have constant
> destruction. In all cases, do not emit runtime calls to the destructor
> for variables with constant destruction.
>
> Added:
> cfe/trunk/test/CXX/expr/expr.const/p6-2a.cpp
> cfe/trunk/test/CodeGenCXX/non-const-init-cxx2a.cpp
> Modified:
> cfe/trunk/include/clang/AST/Decl.h
> cfe/trunk/include/clang/Basic/DiagnosticASTKinds.td
> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> cfe/trunk/lib/AST/ASTContext.cpp
> cfe/trunk/lib/AST/Decl.cpp
> cfe/trunk/lib/AST/ExprConstant.cpp
> cfe/trunk/lib/AST/Interp/Interp.cpp
> cfe/trunk/lib/AST/TextNodeDumper.cpp
> cfe/trunk/lib/CodeGen/CGCall.cpp
> cfe/trunk/lib/CodeGen/CGClass.cpp
> cfe/trunk/lib/CodeGen/CGDecl.cpp
> cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
> cfe/trunk/lib/CodeGen/CodeGenModule.cpp
> cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
> cfe/trunk/lib/Sema/SemaDeclCXX.cpp
> cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
> cfe/trunk/lib/Serialization/ASTWriterDecl.cpp
> cfe/trunk/test/CXX/dcl.dcl/dcl.spec/dcl.constexpr/p9.cpp
> cfe/trunk/test/CodeGenCXX/attr-no-destroy-d54344.cpp
> cfe/trunk/test/CodeGenCXX/const-init-cxx2a.cpp
> cfe/trunk/test/CodeGenCXX/no_destroy.cpp
>
> Modified: cfe/trunk/include/clang/AST/Decl.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Decl.h?rev=373159=373158=373159=diff
>
> ==
> --- cfe/trunk/include/clang/AST/Decl.h (original)
> +++ cfe/trunk/include/clang/AST/Decl.h Sat Sep 28 22:08:46 2019
> @@ -808,12 +808,19 @@ struct EvaluatedStmt {
>/// valid if CheckedICE is true.
>bool IsICE : 1;
>
> +  /// Whether this variable is known to have constant destruction. That
> is,
> +  /// whether running the destructor on the initial value is a side-effect
> +  /// (and doesn't inspect any state that might have changed during
> program
> +  /// execution). This is currently only computed if the destructor is
> +  /// non-trivial.
> +  bool HasConstantDestruction : 1;
> +
>Stmt *Value;
>APValue Evaluated;
>
> -  EvaluatedStmt() : WasEvaluated(false), IsEvaluating(false),
> CheckedICE(false),
> -CheckingICE(false), IsICE(false) {}
> -
> +  EvaluatedStmt()
> +  : WasEvaluated(false), IsEvaluating(false), CheckedICE(false),
> +CheckingICE(false), IsICE(false), HasConstantDestruction(false) {}
>  };
>
>  /// Represents a variable declaration or definition.
> @@ -1267,6 +1274,14 @@ public:
>/// to untyped APValue if the value could not be evaluated.
>APValue *getEvaluatedValue() const;
>
> +  /// Evaluate the destruction of this variable to determine if it
> constitutes
> +  /// constant destruction.
> +  ///
> +  /// \pre isInitICE()
> +  /// \return \c true if this variable has constant destruction, \c false
> if
> +  /// not.
> +  bool evaluateDestruction(SmallVectorImpl )
> const;
> +
>/// Determines whether it is already known whether the
>/// initializer is an integral constant expression or not.
>bool isInitKnownICE() const;
> @@ -1505,9 +1520,14 @@ public:
>// has no definition within this source file.
>bool isKnownToBeDefined() const;
>
> -  /// Do we need to emit an exit-time destructor for this variable?
> +  /// Is destruction of this variable entirely suppressed? If so, the
> variable
> +  /// need not have a usable destructor at all.
>bool isNoDestroy(const ASTContext &) const;
>
> +  /// Do we need to emit an exit-time destructor for this variable, and
> if so,
> +  /// what kind?
> +  QualType::DestructionKind needsDestruction(const ASTContext ) const;
> +
>// Implement isa/cast/dyncast/etc.
>static bool classof(const Decl *D) { return classofKind(D->getKind()); }
>static bool classofKind(Kind K) { return K >= firstVar && K <= lastVar;
> }
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticASTKinds.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticASTKinds.td?rev=373159=373158=373159=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticASTKinds.td (original)
> +++ 

Re: r369932 - Fix use of invalidated iterator introduced by r369680.

[Alex L via cfe-commits]

Thanks for the fix!

On Mon, 26 Aug 2019 at 10:29, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rsmith
> Date: Mon Aug 26 10:31:06 2019
> New Revision: 369932
>
> URL: http://llvm.org/viewvc/llvm-project?rev=369932=rev
> Log:
> Fix use of invalidated iterator introduced by r369680.
>
> Modified:
> cfe/trunk/lib/Basic/FileManager.cpp
>
> Modified: cfe/trunk/lib/Basic/FileManager.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/FileManager.cpp?rev=369932=369931=369932=diff
>
> ==
> --- cfe/trunk/lib/Basic/FileManager.cpp (original)
> +++ cfe/trunk/lib/Basic/FileManager.cpp Mon Aug 26 10:31:06 2019
> @@ -263,15 +263,15 @@ FileManager::getFileRef(StringRef Filena
>// If the name returned by getStatValue is different than Filename,
> re-intern
>// the name.
>if (Status.getName() != Filename) {
> -auto  =
> +auto  =
>  *SeenFileEntries.insert({Status.getName(), }).first;
> -assert((*NamedFileEnt.second).get() ==  &&
> +assert((*NewNamedFileEnt.second).get() ==  &&
> "filename from getStatValue() refers to wrong file");
> -InterndFileName = NamedFileEnt.first().data();
> +InterndFileName = NewNamedFileEnt.first().data();
>  // In addition to re-interning the name, construct a redirecting seen
> file
>  // entry, that will point to the name the filesystem actually wants
> to use.
>  StringRef *Redirect = new (CanonicalNameStorage)
> StringRef(InterndFileName);
> -SeenFileInsertResult.first->second = Redirect;
> +NamedFileEnt.second = Redirect;
>}
>
>if (UFE.isValid()) { // Already have an entry with this inode, return
> it.
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r368354 - Mark clang-scan-deps test as requiring thread support

[Alex L via cfe-commits]

Hi Reid,

I have fixed this issue in r368640, clang-scan-deps will no longer spawn
threads if threading if disabled.

Cheers,
Alex


On Thu, 8 Aug 2019 at 15:13, Alex L  wrote:

> Thanks for fixing this!
>
> I think changing clang-scan-deps to ignore -j when `LLVM_ENABLE_THREADS`
> is probably a better solution. I'll work on a patch that does that.
>
>
>
> On Thu, 8 Aug 2019 at 15:07, Reid Kleckner  wrote:
>
>> The specific issue here is that clang-scan-deps uses threads, which seems
>> to work just fine. But, it calls some code that sets up PrettyStackTrace
>> RAII objects, which normally use TLS. And when LLVM_ENABLE_THREADS is off,
>> LLVM_THREAD_LOCAL expands to nothing, so the TLS variables are simply
>> global, and the RAII objects assert that things haven't been constructed
>> and destructed in the correct order.
>>
>> So, going forward you will probably need to remember to add REQUIRES:
>> thread_support to individual tests, or change clang-scan-deps to ignore the
>> -j parameter when threads have been disabled.
>>
>> On Thu, Aug 8, 2019 at 2:45 PM Reid Kleckner via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: rnk
>>> Date: Thu Aug  8 14:45:59 2019
>>> New Revision: 368354
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=368354=rev
>>> Log:
>>> Mark clang-scan-deps test as requiring thread support
>>>
>>> Otherwise the test calls a pure virtual method and crashes. Perhaps this
>>> could be improved.
>>>
>>> Modified:
>>> cfe/trunk/test/ClangScanDeps/regular_cdb.cpp
>>>
>>> Modified: cfe/trunk/test/ClangScanDeps/regular_cdb.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/ClangScanDeps/regular_cdb.cpp?rev=368354=368353=368354=diff
>>>
>>> ==
>>> --- cfe/trunk/test/ClangScanDeps/regular_cdb.cpp (original)
>>> +++ cfe/trunk/test/ClangScanDeps/regular_cdb.cpp Thu Aug  8 14:45:59 2019
>>> @@ -1,3 +1,4 @@
>>> +// REQUIRES: thread_support
>>>  // RUN: rm -rf %t.dir
>>>  // RUN: rm -rf %t.cdb
>>>  // RUN: mkdir -p %t.dir
>>>
>>>
>>> ___
>>> cfe-commits mailing list
>>> cfe-commits@lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>>
>>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r368354 - Mark clang-scan-deps test as requiring thread support

[Alex L via cfe-commits]

Thanks for fixing this!

I think changing clang-scan-deps to ignore -j when `LLVM_ENABLE_THREADS` is
probably a better solution. I'll work on a patch that does that.



On Thu, 8 Aug 2019 at 15:07, Reid Kleckner  wrote:

> The specific issue here is that clang-scan-deps uses threads, which seems
> to work just fine. But, it calls some code that sets up PrettyStackTrace
> RAII objects, which normally use TLS. And when LLVM_ENABLE_THREADS is off,
> LLVM_THREAD_LOCAL expands to nothing, so the TLS variables are simply
> global, and the RAII objects assert that things haven't been constructed
> and destructed in the correct order.
>
> So, going forward you will probably need to remember to add REQUIRES:
> thread_support to individual tests, or change clang-scan-deps to ignore the
> -j parameter when threads have been disabled.
>
> On Thu, Aug 8, 2019 at 2:45 PM Reid Kleckner via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: rnk
>> Date: Thu Aug  8 14:45:59 2019
>> New Revision: 368354
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=368354=rev
>> Log:
>> Mark clang-scan-deps test as requiring thread support
>>
>> Otherwise the test calls a pure virtual method and crashes. Perhaps this
>> could be improved.
>>
>> Modified:
>> cfe/trunk/test/ClangScanDeps/regular_cdb.cpp
>>
>> Modified: cfe/trunk/test/ClangScanDeps/regular_cdb.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/ClangScanDeps/regular_cdb.cpp?rev=368354=368353=368354=diff
>>
>> ==
>> --- cfe/trunk/test/ClangScanDeps/regular_cdb.cpp (original)
>> +++ cfe/trunk/test/ClangScanDeps/regular_cdb.cpp Thu Aug  8 14:45:59 2019
>> @@ -1,3 +1,4 @@
>> +// REQUIRES: thread_support
>>  // RUN: rm -rf %t.dir
>>  // RUN: rm -rf %t.cdb
>>  // RUN: mkdir -p %t.dir
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D64149: [clang-scan-deps] use `-Wno-error` when scanning for dependencies

[Alex L via cfe-commits]

The warning output is suppressed, yes. Yeah, we should probably just
disable them. I'll follow up with a commit.

On Wed, 3 Jul 2019 at 15:25, Duncan P. N. Exon Smith via Phabricator <
revi...@reviews.llvm.org> wrote:

> dexonsmith added a comment.
>
> Is warning output suppressed?  If so, should we just/also disable all
> warnings?  (IIRC, the flag is `-w`.)
>
>
> Repository:
>   rL LLVM
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D64149/new/
>
> https://reviews.llvm.org/D64149
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r363204 - [clang-scan-deps] initial outline of the tool that runs preprocessor to find

[Alex L via cfe-commits]

I committed r363742 with the fix to the test.

Cheers,
Alex

On Tue, 18 Jun 2019 at 10:23, Alex L  wrote:

> Hi Douglas,
>
> Thanks for the heads up! That's definitely a bug.
> I don't think "-c" is needed here. I will adjust this test this morning to
> remove the "-c", and will address the bug later.
>
> Thanks,
> Alex
>
> On Mon, 17 Jun 2019 at 18:02,  wrote:
>
>> Hi Alex,
>>
>> In the test you added here, the json file contains compile commands that
>> includes "-c". Is that really necessary for the test to work properly?
>>
>> The reason I ask is that if you run in a configuration which does not use
>> the integrated assembler, the test fails with an error due to the fact that
>> an external assembler must be invoked:
>>
>> error: unable to handle compilation, expected exactly one compiler job in
>> ' "clang" "-cc1" ...; "/usr/bin/as" "--64" "-I" "Inputs" "-o" "/dev/null"
>>
>> Changing the "-c" to "-S" still shows the test passing when I run it
>> locally, so if the "-c" is not really needed, can it be changed to "-S" to
>> work correctly where the integrated assembler is not the default option?
>>
>> Douglas Yung
>>
>> -Original Message-
>> From: cfe-commits  On Behalf Of Alex
>> Lorenz via cfe-commits
>> Sent: Wednesday, June 12, 2019 14:33
>> To: cfe-commits@lists.llvm.org
>> Subject: r363204 - [clang-scan-deps] initial outline of the tool that
>> runs preprocessor to find
>>
>> Author: arphaman
>> Date: Wed Jun 12 14:32:49 2019
>> New Revision: 363204
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=363204=rev
>> Log:
>> [clang-scan-deps] initial outline of the tool that runs preprocessor to
>> find dependencies over a JSON compilation database
>>
>> This commit introduces an outline for the clang-scan-deps tool that will
>> be used to implement fast dependency discovery phase using implicit modules
>> for explicit module builds.
>>
>> The initial version of the tool works by computing non-modular header
>> dependencies for files in the compilation database without any
>> optimizations (i.e. without source minimization from r362459).
>> The tool spawns a number of worker threads to run the clang compiler
>> workers in parallel.
>>
>> The immediate goal for clang-scan-deps is to create a ClangScanDeps
>> library which will be used to build up this tool to use the source
>> minimization and caching multi-threaded filesystem to implement the
>> optimized non-incremental dependency scanning phase for a non-modular
>> build. This will allow us to do benchmarks and comparisons for performance
>> that the minimization and caching give us
>>
>> Differential Revision: https://reviews.llvm.org/D60233
>>
>> Added:
>> cfe/trunk/test/ClangScanDeps/
>> cfe/trunk/test/ClangScanDeps/Inputs/
>> cfe/trunk/test/ClangScanDeps/Inputs/header.h
>> cfe/trunk/test/ClangScanDeps/Inputs/header2.h
>> cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json
>> cfe/trunk/test/ClangScanDeps/regular_cdb.cpp
>> cfe/trunk/tools/clang-scan-deps/
>> cfe/trunk/tools/clang-scan-deps/CMakeLists.txt
>> cfe/trunk/tools/clang-scan-deps/ClangScanDeps.cpp
>> Modified:
>> cfe/trunk/test/CMakeLists.txt
>> cfe/trunk/tools/CMakeLists.txt
>>
>> Modified: cfe/trunk/test/CMakeLists.txt
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CMakeLists.txt?rev=363204=363203=363204=diff
>>
>> ==
>> --- cfe/trunk/test/CMakeLists.txt (original)
>> +++ cfe/trunk/test/CMakeLists.txt Wed Jun 12 14:32:49 2019
>> @@ -57,6 +57,7 @@ list(APPEND CLANG_TEST_DEPS
>>clang-rename
>>clang-refactor
>>clang-diff
>> +  clang-scan-deps
>>diagtool
>>hmaptool
>>)
>>
>> Added: cfe/trunk/test/ClangScanDeps/Inputs/header.h
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/ClangScanDeps/Inputs/header.h?rev=363204=auto
>>
>> ==
>> --- cfe/trunk/test/ClangScanDeps/Inputs/header.h (added)
>> +++ cfe/trunk/test/ClangScanDeps/Inputs/header.h Wed Jun 12 14:32:49
>> +++ 2019
>> @@ -0,0 +1,3 @@
>> +#ifdef INCLUDE_HEADER2
>> +#include "header2.h"
>> +#endif
>>
>> Added: cfe/trunk/test/ClangScanDeps/Inputs/header2.h
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/ClangScanDeps/Inputs/header2.h?rev=363204=auto
>>
>> ==
>> --- cfe/trunk/test/ClangScanDeps/Inputs/header2.h (added)
>> +++ cfe/trunk/test/ClangScanDeps/Inputs/header2.h Wed Jun 12 14:32:49
>> +++ 2019
>> @@ -0,0 +1 @@
>> +// header 2.
>>
>> Added: cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json?rev=363204=auto
>>
>> ==
>> --- cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json (added)
>> +++ 

Re: r363204 - [clang-scan-deps] initial outline of the tool that runs preprocessor to find

[Alex L via cfe-commits]

Hi Douglas,

Thanks for the heads up! That's definitely a bug.
I don't think "-c" is needed here. I will adjust this test this morning to
remove the "-c", and will address the bug later.

Thanks,
Alex

On Mon, 17 Jun 2019 at 18:02,  wrote:

> Hi Alex,
>
> In the test you added here, the json file contains compile commands that
> includes "-c". Is that really necessary for the test to work properly?
>
> The reason I ask is that if you run in a configuration which does not use
> the integrated assembler, the test fails with an error due to the fact that
> an external assembler must be invoked:
>
> error: unable to handle compilation, expected exactly one compiler job in
> ' "clang" "-cc1" ...; "/usr/bin/as" "--64" "-I" "Inputs" "-o" "/dev/null"
>
> Changing the "-c" to "-S" still shows the test passing when I run it
> locally, so if the "-c" is not really needed, can it be changed to "-S" to
> work correctly where the integrated assembler is not the default option?
>
> Douglas Yung
>
> -Original Message-
> From: cfe-commits  On Behalf Of Alex
> Lorenz via cfe-commits
> Sent: Wednesday, June 12, 2019 14:33
> To: cfe-commits@lists.llvm.org
> Subject: r363204 - [clang-scan-deps] initial outline of the tool that runs
> preprocessor to find
>
> Author: arphaman
> Date: Wed Jun 12 14:32:49 2019
> New Revision: 363204
>
> URL: http://llvm.org/viewvc/llvm-project?rev=363204=rev
> Log:
> [clang-scan-deps] initial outline of the tool that runs preprocessor to
> find dependencies over a JSON compilation database
>
> This commit introduces an outline for the clang-scan-deps tool that will
> be used to implement fast dependency discovery phase using implicit modules
> for explicit module builds.
>
> The initial version of the tool works by computing non-modular header
> dependencies for files in the compilation database without any
> optimizations (i.e. without source minimization from r362459).
> The tool spawns a number of worker threads to run the clang compiler
> workers in parallel.
>
> The immediate goal for clang-scan-deps is to create a ClangScanDeps
> library which will be used to build up this tool to use the source
> minimization and caching multi-threaded filesystem to implement the
> optimized non-incremental dependency scanning phase for a non-modular
> build. This will allow us to do benchmarks and comparisons for performance
> that the minimization and caching give us
>
> Differential Revision: https://reviews.llvm.org/D60233
>
> Added:
> cfe/trunk/test/ClangScanDeps/
> cfe/trunk/test/ClangScanDeps/Inputs/
> cfe/trunk/test/ClangScanDeps/Inputs/header.h
> cfe/trunk/test/ClangScanDeps/Inputs/header2.h
> cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json
> cfe/trunk/test/ClangScanDeps/regular_cdb.cpp
> cfe/trunk/tools/clang-scan-deps/
> cfe/trunk/tools/clang-scan-deps/CMakeLists.txt
> cfe/trunk/tools/clang-scan-deps/ClangScanDeps.cpp
> Modified:
> cfe/trunk/test/CMakeLists.txt
> cfe/trunk/tools/CMakeLists.txt
>
> Modified: cfe/trunk/test/CMakeLists.txt
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CMakeLists.txt?rev=363204=363203=363204=diff
>
> ==
> --- cfe/trunk/test/CMakeLists.txt (original)
> +++ cfe/trunk/test/CMakeLists.txt Wed Jun 12 14:32:49 2019
> @@ -57,6 +57,7 @@ list(APPEND CLANG_TEST_DEPS
>clang-rename
>clang-refactor
>clang-diff
> +  clang-scan-deps
>diagtool
>hmaptool
>)
>
> Added: cfe/trunk/test/ClangScanDeps/Inputs/header.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/ClangScanDeps/Inputs/header.h?rev=363204=auto
>
> ==
> --- cfe/trunk/test/ClangScanDeps/Inputs/header.h (added)
> +++ cfe/trunk/test/ClangScanDeps/Inputs/header.h Wed Jun 12 14:32:49
> +++ 2019
> @@ -0,0 +1,3 @@
> +#ifdef INCLUDE_HEADER2
> +#include "header2.h"
> +#endif
>
> Added: cfe/trunk/test/ClangScanDeps/Inputs/header2.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/ClangScanDeps/Inputs/header2.h?rev=363204=auto
>
> ==
> --- cfe/trunk/test/ClangScanDeps/Inputs/header2.h (added)
> +++ cfe/trunk/test/ClangScanDeps/Inputs/header2.h Wed Jun 12 14:32:49
> +++ 2019
> @@ -0,0 +1 @@
> +// header 2.
>
> Added: cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json?rev=363204=auto
>
> ==
> --- cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json (added)
> +++ cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json Wed Jun 12
> +++ 14:32:49 2019
> @@ -0,0 +1,12 @@
> +[
> +{
> +  "directory": "DIR",
> +  "command": "clang -c DIR/regular_cdb.cpp -IInputs -MD -MF
> +DIR/regular_cdb.d",
> +  "file": "DIR/regular_cdb.cpp"
> +},

Re: r363204 - [clang-scan-deps] initial outline of the tool that runs preprocessor to find

[Alex L via cfe-commits]

On Wed, 12 Jun 2019 at 14:29, Alex Lorenz via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: arphaman
> Date: Wed Jun 12 14:32:49 2019
> New Revision: 363204
>
> URL: http://llvm.org/viewvc/llvm-project?rev=363204=rev
> Log:
> [clang-scan-deps] initial outline of the tool that runs preprocessor to
> find
> dependencies over a JSON compilation database
>
> This commit introduces an outline for the clang-scan-deps tool that will be
> used to implement fast dependency discovery phase using implicit modules
> for
> explicit module builds.
>
> The initial version of the tool works by computing non-modular header
> dependencies
> for files in the compilation database without any optimizations
> (i.e. without source minimization from r362459).
> The tool spawns a number of worker threads to run the clang compiler
> workers in parallel.
>
> The immediate goal for clang-scan-deps is to create a ClangScanDeps library
> which will be used to build up this tool to use the source minimization and
> caching multi-threaded filesystem to implement the optimized
> non-incremental
> dependency scanning phase for a non-modular build. This will allow us to do
> benchmarks and comparisons for performance that the minimization and
> caching give us
>
> Differential Revision: https://reviews.llvm.org/D60233
>
> Added:
> cfe/trunk/test/ClangScanDeps/
> cfe/trunk/test/ClangScanDeps/Inputs/
> cfe/trunk/test/ClangScanDeps/Inputs/header.h
> cfe/trunk/test/ClangScanDeps/Inputs/header2.h
> cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json
> cfe/trunk/test/ClangScanDeps/regular_cdb.cpp
> cfe/trunk/tools/clang-scan-deps/
> cfe/trunk/tools/clang-scan-deps/CMakeLists.txt
> cfe/trunk/tools/clang-scan-deps/ClangScanDeps.cpp
> Modified:
> cfe/trunk/test/CMakeLists.txt
> cfe/trunk/tools/CMakeLists.txt
>
> Modified: cfe/trunk/test/CMakeLists.txt
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CMakeLists.txt?rev=363204=363203=363204=diff
>
> ==
> --- cfe/trunk/test/CMakeLists.txt (original)
> +++ cfe/trunk/test/CMakeLists.txt Wed Jun 12 14:32:49 2019
> @@ -57,6 +57,7 @@ list(APPEND CLANG_TEST_DEPS
>clang-rename
>clang-refactor
>clang-diff
> +  clang-scan-deps
>diagtool
>hmaptool
>)
>
> Added: cfe/trunk/test/ClangScanDeps/Inputs/header.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/ClangScanDeps/Inputs/header.h?rev=363204=auto
>
> ==
> --- cfe/trunk/test/ClangScanDeps/Inputs/header.h (added)
> +++ cfe/trunk/test/ClangScanDeps/Inputs/header.h Wed Jun 12 14:32:49 2019
> @@ -0,0 +1,3 @@
> +#ifdef INCLUDE_HEADER2
> +#include "header2.h"
> +#endif
>
> Added: cfe/trunk/test/ClangScanDeps/Inputs/header2.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/ClangScanDeps/Inputs/header2.h?rev=363204=auto
>
> ==
> --- cfe/trunk/test/ClangScanDeps/Inputs/header2.h (added)
> +++ cfe/trunk/test/ClangScanDeps/Inputs/header2.h Wed Jun 12 14:32:49 2019
> @@ -0,0 +1 @@
> +// header 2.
>
> Added: cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json?rev=363204=auto
>
> ==
> --- cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json (added)
> +++ cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json Wed Jun 12
> 14:32:49 2019
> @@ -0,0 +1,12 @@
> +[
> +{
> +  "directory": "DIR",
> +  "command": "clang -c DIR/regular_cdb.cpp -IInputs -MD -MF
> DIR/regular_cdb.d",
> +  "file": "DIR/regular_cdb.cpp"
> +},
> +{
> +  "directory": "DIR",
> +  "command": "clang -c DIR/regular_cdb.cpp -IInputs -D INCLUDE_HEADER2
> -MD -MF DIR/regular_cdb2.d",
> +  "file": "DIR/regular_cdb.cpp"
> +}
> +]
>
> Added: cfe/trunk/test/ClangScanDeps/regular_cdb.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/ClangScanDeps/regular_cdb.cpp?rev=363204=auto
>
> ==
> --- cfe/trunk/test/ClangScanDeps/regular_cdb.cpp (added)
> +++ cfe/trunk/test/ClangScanDeps/regular_cdb.cpp Wed Jun 12 14:32:49 2019
> @@ -0,0 +1,27 @@
> +// RUN: rm -rf %t.dir
> +// RUN: rm -rf %t.cdb
> +// RUN: mkdir -p %t.dir
> +// RUN: cp %s %t.dir/regular_cdb.cpp
> +// RUN: mkdir %t.dir/Inputs
> +// RUN: cp %S/Inputs/header.h %t.dir/Inputs/header.h
> +// RUN: cp %S/Inputs/header2.h %t.dir/Inputs/header2.h
> +// RUN: sed -e "s|DIR|%/t.dir|g" %S/Inputs/regular_cdb.json > %t.cdb
> +//
> +// RUN: clang-scan-deps -compilation-database %t.cdb -j 1
> +// RUN: cat %t.dir/regular_cdb.d | FileCheck %s
> +// RUN: cat %t.dir/regular_cdb2.d | FileCheck --check-prefix=CHECK2 %s
> +// RUN: rm -rf %t.dir/regular_cdb.d %t.dir/regular_cdb2.d
> +//
> +// 

Re: r363009 - [Frontend] SetUpDiagnosticLog should handle unowned diagnostic consumer

[Alex L via cfe-commits]

Thanks, that sounds good to me. I added the assignment with the new comment
in 363199.

On Wed, 12 Jun 2019 at 03:59, Ilya Biryukov  wrote:

> Sure, that should work just fine. Could you also add a comment what events
> setting the log file sets in motion? It is not obvious from the test code.
>
> On Tue, Jun 11, 2019 at 6:51 PM Alex L  wrote:
>
>> Hmm, the logging was meant to exercise the creation of chained diagnostic
>> consumer, so without it the test is kind of pointless. I'll undo your
>> change, but will set the file to "-" which will print the log to STDERR and
>> won't create new files. Does that sound reasonable?
>>
>> Cheers,
>> Alex
>>
>> On Tue, 11 Jun 2019 at 02:51, Ilya Biryukov  wrote:
>>
>>> Hi Alex,
>>>
>>> Just wanted to let you know that I removed logging of diagnostics into a
>>> file inside the unit test in r363041 to unbreak our integrate.
>>>
>>> On Tue, Jun 11, 2019 at 1:29 AM Alex Lorenz via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 Author: arphaman
 Date: Mon Jun 10 16:32:42 2019
 New Revision: 363009

 URL: http://llvm.org/viewvc/llvm-project?rev=363009=rev
 Log:
 [Frontend] SetUpDiagnosticLog should handle unowned diagnostic consumer
 in the compiler

 The function SetUpDiagnosticLog that was called from createDiagnostics
 didn't
 handle the case where the diagnostics engine didn't own the diagnostics
 consumer.
 This is a potential problem for a clang tool, in particular some of the
 follow-up
 patches for clang-scan-deps will need this fix.

 Differential Revision: https://reviews.llvm.org/D63101

 Modified:
 cfe/trunk/lib/Frontend/CompilerInstance.cpp
 cfe/trunk/unittests/Frontend/CompilerInstanceTest.cpp

 Modified: cfe/trunk/lib/Frontend/CompilerInstance.cpp
 URL:
 http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/CompilerInstance.cpp?rev=363009=363008=363009=diff

 ==
 --- cfe/trunk/lib/Frontend/CompilerInstance.cpp (original)
 +++ cfe/trunk/lib/Frontend/CompilerInstance.cpp Mon Jun 10 16:32:42 2019
 @@ -232,9 +232,13 @@ static void SetUpDiagnosticLog(Diagnosti

  std::move(StreamOwner));
if (CodeGenOpts)
  Logger->setDwarfDebugFlags(CodeGenOpts->DwarfDebugFlags);
 -  assert(Diags.ownsClient());
 -  Diags.setClient(
 -  new ChainedDiagnosticConsumer(Diags.takeClient(),
 std::move(Logger)));
 +  if (Diags.ownsClient()) {
 +Diags.setClient(
 +new ChainedDiagnosticConsumer(Diags.takeClient(),
 std::move(Logger)));
 +  } else {
 +Diags.setClient(
 +new ChainedDiagnosticConsumer(Diags.getClient(),
 std::move(Logger)));
 +  }
  }

  static void SetupSerializedDiagnostics(DiagnosticOptions *DiagOpts,

 Modified: cfe/trunk/unittests/Frontend/CompilerInstanceTest.cpp
 URL:
 http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Frontend/CompilerInstanceTest.cpp?rev=363009=363008=363009=diff

 ==
 --- cfe/trunk/unittests/Frontend/CompilerInstanceTest.cpp (original)
 +++ cfe/trunk/unittests/Frontend/CompilerInstanceTest.cpp Mon Jun 10
 16:32:42 2019
 @@ -8,6 +8,7 @@

  #include "clang/Frontend/CompilerInstance.h"
  #include "clang/Frontend/CompilerInvocation.h"
 +#include "clang/Frontend/TextDiagnosticPrinter.h"
  #include "llvm/Support/FileSystem.h"
  #include "llvm/Support/Format.h"
  #include "llvm/Support/ToolOutputFile.h"
 @@ -70,4 +71,21 @@ TEST(CompilerInstance, DefaultVFSOverlay
ASSERT_TRUE(Instance.getFileManager().getFile("vfs-virtual.file"));
  }

 +TEST(CompilerInstance,
 AllowDiagnosticLogWithUnownedDiagnosticConsumer) {
 +  auto DiagOpts = new DiagnosticOptions();
 +  DiagOpts->DiagnosticLogFile = "log.diags";
 +
 +  // Create the diagnostic engine with unowned consumer.
 +  std::string DiagnosticOutput;
 +  llvm::raw_string_ostream DiagnosticsOS(DiagnosticOutput);
 +  auto DiagPrinter = llvm::make_unique(
 +  DiagnosticsOS, new DiagnosticOptions());
 +  CompilerInstance Instance;
 +  IntrusiveRefCntPtr Diags =
 Instance.createDiagnostics(
 +  DiagOpts, DiagPrinter.get(), /*ShouldOwnClient=*/false);
 +
 +  Diags->Report(diag::err_expected) << "no crash";
 +  ASSERT_EQ(DiagnosticsOS.str(), "error: expected no crash\n");
 +}
 +
  } // anonymous namespace


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

>>>
>>>
>>> --
>>> Regards,
>>> Ilya Biryukov
>>>
>>
>
> --
> Regards,
> Ilya Biryukov
>

Re: r363009 - [Frontend] SetUpDiagnosticLog should handle unowned diagnostic consumer

[Alex L via cfe-commits]

Hmm, the logging was meant to exercise the creation of chained diagnostic
consumer, so without it the test is kind of pointless. I'll undo your
change, but will set the file to "-" which will print the log to STDERR and
won't create new files. Does that sound reasonable?

Cheers,
Alex

On Tue, 11 Jun 2019 at 02:51, Ilya Biryukov  wrote:

> Hi Alex,
>
> Just wanted to let you know that I removed logging of diagnostics into a
> file inside the unit test in r363041 to unbreak our integrate.
>
> On Tue, Jun 11, 2019 at 1:29 AM Alex Lorenz via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: arphaman
>> Date: Mon Jun 10 16:32:42 2019
>> New Revision: 363009
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=363009=rev
>> Log:
>> [Frontend] SetUpDiagnosticLog should handle unowned diagnostic consumer
>> in the compiler
>>
>> The function SetUpDiagnosticLog that was called from createDiagnostics
>> didn't
>> handle the case where the diagnostics engine didn't own the diagnostics
>> consumer.
>> This is a potential problem for a clang tool, in particular some of the
>> follow-up
>> patches for clang-scan-deps will need this fix.
>>
>> Differential Revision: https://reviews.llvm.org/D63101
>>
>> Modified:
>> cfe/trunk/lib/Frontend/CompilerInstance.cpp
>> cfe/trunk/unittests/Frontend/CompilerInstanceTest.cpp
>>
>> Modified: cfe/trunk/lib/Frontend/CompilerInstance.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/CompilerInstance.cpp?rev=363009=363008=363009=diff
>>
>> ==
>> --- cfe/trunk/lib/Frontend/CompilerInstance.cpp (original)
>> +++ cfe/trunk/lib/Frontend/CompilerInstance.cpp Mon Jun 10 16:32:42 2019
>> @@ -232,9 +232,13 @@ static void SetUpDiagnosticLog(Diagnosti
>>
>>  std::move(StreamOwner));
>>if (CodeGenOpts)
>>  Logger->setDwarfDebugFlags(CodeGenOpts->DwarfDebugFlags);
>> -  assert(Diags.ownsClient());
>> -  Diags.setClient(
>> -  new ChainedDiagnosticConsumer(Diags.takeClient(),
>> std::move(Logger)));
>> +  if (Diags.ownsClient()) {
>> +Diags.setClient(
>> +new ChainedDiagnosticConsumer(Diags.takeClient(),
>> std::move(Logger)));
>> +  } else {
>> +Diags.setClient(
>> +new ChainedDiagnosticConsumer(Diags.getClient(),
>> std::move(Logger)));
>> +  }
>>  }
>>
>>  static void SetupSerializedDiagnostics(DiagnosticOptions *DiagOpts,
>>
>> Modified: cfe/trunk/unittests/Frontend/CompilerInstanceTest.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Frontend/CompilerInstanceTest.cpp?rev=363009=363008=363009=diff
>>
>> ==
>> --- cfe/trunk/unittests/Frontend/CompilerInstanceTest.cpp (original)
>> +++ cfe/trunk/unittests/Frontend/CompilerInstanceTest.cpp Mon Jun 10
>> 16:32:42 2019
>> @@ -8,6 +8,7 @@
>>
>>  #include "clang/Frontend/CompilerInstance.h"
>>  #include "clang/Frontend/CompilerInvocation.h"
>> +#include "clang/Frontend/TextDiagnosticPrinter.h"
>>  #include "llvm/Support/FileSystem.h"
>>  #include "llvm/Support/Format.h"
>>  #include "llvm/Support/ToolOutputFile.h"
>> @@ -70,4 +71,21 @@ TEST(CompilerInstance, DefaultVFSOverlay
>>ASSERT_TRUE(Instance.getFileManager().getFile("vfs-virtual.file"));
>>  }
>>
>> +TEST(CompilerInstance, AllowDiagnosticLogWithUnownedDiagnosticConsumer) {
>> +  auto DiagOpts = new DiagnosticOptions();
>> +  DiagOpts->DiagnosticLogFile = "log.diags";
>> +
>> +  // Create the diagnostic engine with unowned consumer.
>> +  std::string DiagnosticOutput;
>> +  llvm::raw_string_ostream DiagnosticsOS(DiagnosticOutput);
>> +  auto DiagPrinter = llvm::make_unique(
>> +  DiagnosticsOS, new DiagnosticOptions());
>> +  CompilerInstance Instance;
>> +  IntrusiveRefCntPtr Diags =
>> Instance.createDiagnostics(
>> +  DiagOpts, DiagPrinter.get(), /*ShouldOwnClient=*/false);
>> +
>> +  Diags->Report(diag::err_expected) << "no crash";
>> +  ASSERT_EQ(DiagnosticsOS.str(), "error: expected no crash\n");
>> +}
>> +
>>  } // anonymous namespace
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>
>
> --
> Regards,
> Ilya Biryukov
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r357713 - Verify that Android targets generate DWARF 4 by default.

[Alex L via cfe-commits]

Thanks! I committed the fix in r357740. The test should start passing now.

Cheers,
Alex

On Thu, 4 Apr 2019 at 18:32, Stephen Hines  wrote:

> Ah I just saw this. Please feel free to CC me on the fix CL and I will
> approve it. I didn't realize that the exact specification was missing
> for that.
>
> Thanks,
> Steve
>
> On Thu, Apr 4, 2019 at 6:31 PM Alex L  wrote:
> >
> > Thanks, for the explanation, it makes sense. It looks like an explicit
> `darwin14` in one of the non-versioned darwin triples fixes the issue. I
> will commit the fix right away.
> >
> > Cheers,
> > Alex
> >
> >
> > On Thu, 4 Apr 2019 at 18:24, Adrian Prantl  wrote:
> >>
> >> IIRC, the dwarf version on Darwin depends on the deployment target and
> is 2 for earlier versions of macOS and and 4 for newer ones (I need to dig
> through the driver code to determine the exact version).
> >>
> >> I can take a look at this tomorrow morning.
> >>
> >> -- adrian
> >>
> >> On Apr 4, 2019, at 6:21 PM, Alex L  wrote:
> >>
> >> Hi Stephen,
> >>
> >> It looks like your change has caused the 'debug-options.c' test to
> start failing on Darwin. It looks like we emit "-dwarf-version=4" by
> default, and not 2. Could you please take a look.
> >>
> >> Here's a link to a latest build on the public LLVM CI that contains the
> failure:
> >>
> http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental/59772/console
> >>
> >> Here's the failure itself:
> >> Command Output (stderr): --
> /Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/llvm/tools/clang/test/Driver/debug-options.c:280:14:
> error: G_DWARF2: expected string not found in input // G_DWARF2:
> "-dwarf-version=2" ^ :5:515: note: scanning from here
> "/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/clang-build/bin/clang-9"
> "-cc1" "-triple" "x86_64-apple-macosx10.13.0" "-Wdeprecated-objc-isa-usage"
> "-Werror=deprecated-objc-isa-usage" "-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" "-munwind-tables" "-faligned-alloc-unavailable"
> "-target-cpu" "penryn" "-dwarf-column-info" "-debug-info-kind=standalone"
> "-dwarf-version=4" "-debugger-tuning=lldb" "-ggnu-pubnames"
> "-target-linker-version" "351.8" "-coverage-notes-file"
> "/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/clang-build/tools/clang/test/Driver/debug-options.gcno"
> "-resource-dir"
> "/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/clang-build/lib/clang/9.0.0"
> "-fdebug-compilation-dir"
> "/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/clang-build/tools/clang/test/Driver"
> "-ferror-limit" "19" "-fmessage-length" "0" "-stack-protector" "1"
> "-fblocks" "-fencode-extended-block-signature"
> "-fregister-global-dtors-with-atexit" "-fobjc-runtime=macosx-10.13.0"
> "-fmax-type-align=16" "-fdiagnostics-show-option" "-o" "debug-options.o"
> "-x" "c"
> "/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/llvm/tools/clang/test/Driver/debug-options.c"
> ^
> >>
> >>
> >> Adrian, I've looped you in since you reviewed the commit it looks like.
> Do you know if that's expected behavior on Darwin?
> >>
> >> Cheers,
> >> Alex
> >>
> >> On Thu, 4 Apr 2019 at 11:16, Stephen Hines via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
> >>>
> >>> Author: srhines
> >>> Date: Thu Apr  4 11:17:46 2019
> >>> New Revision: 357713
> >>>
> >>> URL: http://llvm.org/viewvc/llvm-project?rev=357713=rev
> >>> Log:
> >>> Verify that Android targets generate DWARF 4 by default.
> >>>
> >>> Summary:
> >>> In the future, Android releases will support DWARF 5, but we need to
> >>> ensure that older targets only have DWARF 4 generated for them. This
> >>> patch inserts that verification for all Android releases now. The patch
> >>> also fixes 2 minor mistakes (a mistakenly moved RUN line, and the
> >>> missing G_DWARF2 check label).
> >>>
> >>> Reviewers: aprantl
> >>>
> >>> Reviewed By: aprantl
> >>>
> >>> Subscribers: chh, pirama, cfe-commits
> >>>
> >>> Tags: #clang
> >>>
> >>> Differential Revision: https://reviews.llvm.org/D60238
> >>>
> >>> Modified:
> >>> cfe/trunk/test/Driver/debug-options.c
> >>>
> >>> Modified: cfe/trunk/test/Driver/debug-options.c
> >>> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/debug-options.c?rev=357713=357712=357713=diff
> >>>
> ==
> >>> --- cfe/trunk/test/Driver/debug-options.c (original)
> >>> +++ cfe/trunk/test/Driver/debug-options.c Thu Apr  4 11:17:46 2019
> >>> @@ -17,9 +17,14 @@
> >>>  // RUN: %clang -### -c -glldb %s -target x86_64-linux-gnu 2>&1 \
> >>>  // RUN: | FileCheck -check-prefix=G -check-prefix=G_LLDB
> %s
> >>>  // RUN: %clang -### -c -gsce %s -target x86_64-linux-gnu 2>&1 \
> >>> +// RUN: | FileCheck -check-prefix=G 

Re: r357713 - Verify that Android targets generate DWARF 4 by default.

[Alex L via cfe-commits]

Thanks, for the explanation, it makes sense. It looks like an explicit
`darwin14` in one of the non-versioned darwin triples fixes the issue. I
will commit the fix right away.

Cheers,
Alex


On Thu, 4 Apr 2019 at 18:24, Adrian Prantl  wrote:

> IIRC, the dwarf version on Darwin depends on the deployment target and is
> 2 for earlier versions of macOS and and 4 for newer ones (I need to dig
> through the driver code to determine the exact version).
>
> I can take a look at this tomorrow morning.
>
> -- adrian
>
> On Apr 4, 2019, at 6:21 PM, Alex L  wrote:
>
> Hi Stephen,
>
> It looks like your change has caused the 'debug-options.c' test to start
> failing on Darwin. It looks like we emit "-dwarf-version=4" by default, and
> not 2. Could you please take a look.
>
> Here's a link to a latest build on the public LLVM CI that contains the
> failure:
>
> http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental/59772/console
>
> Here's the failure itself:
> Command Output (stderr): -- 
> /Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/llvm/tools/clang/test/Driver/debug-options.c:280:14:
> error: G_DWARF2: expected string not found in input // G_DWARF2:
> "-dwarf-version=2" ^ :5:515: note: scanning from here
> "/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/clang-build/bin/clang-9"
> "-cc1" "-triple" "x86_64-apple-macosx10.13.0" "-Wdeprecated-objc-isa-usage"
> "-Werror=deprecated-objc-isa-usage" "-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" "-munwind-tables" "-faligned-alloc-unavailable"
> "-target-cpu" "penryn" "-dwarf-column-info" "-debug-info-kind=standalone"
> "-dwarf-version=4" "-debugger-tuning=lldb" "-ggnu-pubnames"
> "-target-linker-version" "351.8" "-coverage-notes-file"
> "/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/clang-build/tools/clang/test/Driver/debug-options.gcno"
> "-resource-dir"
> "/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/clang-build/lib/clang/9.0.0"
> "-fdebug-compilation-dir"
> "/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/clang-build/tools/clang/test/Driver"
> "-ferror-limit" "19" "-fmessage-length" "0" "-stack-protector" "1"
> "-fblocks" "-fencode-extended-block-signature"
> "-fregister-global-dtors-with-atexit" "-fobjc-runtime=macosx-10.13.0"
> "-fmax-type-align=16" "-fdiagnostics-show-option" "-o" "debug-options.o"
> "-x" "c"
> "/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/llvm/tools/clang/test/Driver/debug-options.c"
> ^
>
>
> Adrian, I've looped you in since you reviewed the commit it looks like. Do
> you know if that's expected behavior on Darwin?
>
> Cheers,
> Alex
>
> On Thu, 4 Apr 2019 at 11:16, Stephen Hines via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: srhines
>> Date: Thu Apr  4 11:17:46 2019
>> New Revision: 357713
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=357713=rev
>> Log:
>> Verify that Android targets generate DWARF 4 by default.
>>
>> Summary:
>> In the future, Android releases will support DWARF 5, but we need to
>> ensure that older targets only have DWARF 4 generated for them. This
>> patch inserts that verification for all Android releases now. The patch
>> also fixes 2 minor mistakes (a mistakenly moved RUN line, and the
>> missing G_DWARF2 check label).
>>
>> Reviewers: aprantl
>>
>> Reviewed By: aprantl
>>
>> Subscribers: chh, pirama, cfe-commits
>>
>> Tags: #clang
>>
>> Differential Revision: https://reviews.llvm.org/D60238
>>
>> Modified:
>> cfe/trunk/test/Driver/debug-options.c
>>
>> Modified: cfe/trunk/test/Driver/debug-options.c
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/debug-options.c?rev=357713=357712=357713=diff
>>
>> ==
>> --- cfe/trunk/test/Driver/debug-options.c (original)
>> +++ cfe/trunk/test/Driver/debug-options.c Thu Apr  4 11:17:46 2019
>> @@ -17,9 +17,14 @@
>>  // RUN: %clang -### -c -glldb %s -target x86_64-linux-gnu 2>&1 \
>>  // RUN: | FileCheck -check-prefix=G -check-prefix=G_LLDB %s
>>  // RUN: %clang -### -c -gsce %s -target x86_64-linux-gnu 2>&1 \
>> +// RUN: | FileCheck -check-prefix=G -check-prefix=G_SCE %s
>> +
>> +// Android.
>> +// Android should always generate DWARF4.
>> +// RUN: %clang -### -c -g %s -target arm-linux-androideabi 2>&1 \
>> +// RUN: | FileCheck -check-prefix=G -check-prefix=G_DWARF4 %s
>>
>>  // Darwin.
>> -// RUN: | FileCheck -check-prefix=G -check-prefix=G_SCE %s
>>  // RUN: %clang -### -c -g %s -target x86_64-apple-darwin 2>&1 \
>>  // RUN: | FileCheck -check-prefix=G_STANDALONE \
>>  // RUN: -check-prefix=G_DWARF2 \
>> @@ -272,6 +277,7 @@
>>  //
>>  // G_STANDALONE: "-cc1"
>>  // G_STANDALONE: 

Re: r357713 - Verify that Android targets generate DWARF 4 by default.

[Alex L via cfe-commits]

Hi Stephen,

It looks like your change has caused the 'debug-options.c' test to start
failing on Darwin. It looks like we emit "-dwarf-version=4" by default, and
not 2. Could you please take a look.

Here's a link to a latest build on the public LLVM CI that contains the
failure:
http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental/59772/console

Here's the failure itself:
Command Output (stderr): --
/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/llvm/tools/clang/test/Driver/debug-options.c:280:14:
error: G_DWARF2: expected string not found in input // G_DWARF2:
"-dwarf-version=2" ^ :5:515: note: scanning from here
"/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/clang-build/bin/clang-9"
"-cc1" "-triple" "x86_64-apple-macosx10.13.0" "-Wdeprecated-objc-isa-usage"
"-Werror=deprecated-objc-isa-usage" "-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" "-munwind-tables" "-faligned-alloc-unavailable"
"-target-cpu" "penryn" "-dwarf-column-info" "-debug-info-kind=standalone"
"-dwarf-version=4" "-debugger-tuning=lldb" "-ggnu-pubnames"
"-target-linker-version" "351.8" "-coverage-notes-file"
"/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/clang-build/tools/clang/test/Driver/debug-options.gcno"
"-resource-dir"
"/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/clang-build/lib/clang/9.0.0"
"-fdebug-compilation-dir"
"/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/clang-build/tools/clang/test/Driver"
"-ferror-limit" "19" "-fmessage-length" "0" "-stack-protector" "1"
"-fblocks" "-fencode-extended-block-signature"
"-fregister-global-dtors-with-atexit" "-fobjc-runtime=macosx-10.13.0"
"-fmax-type-align=16" "-fdiagnostics-show-option" "-o" "debug-options.o"
"-x" "c"
"/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/llvm/tools/clang/test/Driver/debug-options.c"
^


Adrian, I've looped you in since you reviewed the commit it looks like. Do
you know if that's expected behavior on Darwin?

Cheers,
Alex

On Thu, 4 Apr 2019 at 11:16, Stephen Hines via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: srhines
> Date: Thu Apr  4 11:17:46 2019
> New Revision: 357713
>
> URL: http://llvm.org/viewvc/llvm-project?rev=357713=rev
> Log:
> Verify that Android targets generate DWARF 4 by default.
>
> Summary:
> In the future, Android releases will support DWARF 5, but we need to
> ensure that older targets only have DWARF 4 generated for them. This
> patch inserts that verification for all Android releases now. The patch
> also fixes 2 minor mistakes (a mistakenly moved RUN line, and the
> missing G_DWARF2 check label).
>
> Reviewers: aprantl
>
> Reviewed By: aprantl
>
> Subscribers: chh, pirama, cfe-commits
>
> Tags: #clang
>
> Differential Revision: https://reviews.llvm.org/D60238
>
> Modified:
> cfe/trunk/test/Driver/debug-options.c
>
> Modified: cfe/trunk/test/Driver/debug-options.c
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/debug-options.c?rev=357713=357712=357713=diff
>
> ==
> --- cfe/trunk/test/Driver/debug-options.c (original)
> +++ cfe/trunk/test/Driver/debug-options.c Thu Apr  4 11:17:46 2019
> @@ -17,9 +17,14 @@
>  // RUN: %clang -### -c -glldb %s -target x86_64-linux-gnu 2>&1 \
>  // RUN: | FileCheck -check-prefix=G -check-prefix=G_LLDB %s
>  // RUN: %clang -### -c -gsce %s -target x86_64-linux-gnu 2>&1 \
> +// RUN: | FileCheck -check-prefix=G -check-prefix=G_SCE %s
> +
> +// Android.
> +// Android should always generate DWARF4.
> +// RUN: %clang -### -c -g %s -target arm-linux-androideabi 2>&1 \
> +// RUN: | FileCheck -check-prefix=G -check-prefix=G_DWARF4 %s
>
>  // Darwin.
> -// RUN: | FileCheck -check-prefix=G -check-prefix=G_SCE %s
>  // RUN: %clang -### -c -g %s -target x86_64-apple-darwin 2>&1 \
>  // RUN: | FileCheck -check-prefix=G_STANDALONE \
>  // RUN: -check-prefix=G_DWARF2 \
> @@ -272,6 +277,7 @@
>  //
>  // G_STANDALONE: "-cc1"
>  // G_STANDALONE: "-debug-info-kind=standalone"
> +// G_DWARF2: "-dwarf-version=2"
>  // G_DWARF4: "-dwarf-version=4"
>  //
>  // G_GDB:  "-debugger-tuning=gdb"
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r351459 - [ObjC] Follow-up r350768 and allow the use of unavailable methods that are

[Alex L via cfe-commits]

Hi Hans,

Could you please cherry-pick this change into the release branch?

Cheers,
Alex

On Thu, 17 Jan 2019 at 10:16, Alex Lorenz via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: arphaman
> Date: Thu Jan 17 10:12:45 2019
> New Revision: 351459
>
> URL: http://llvm.org/viewvc/llvm-project?rev=351459=rev
> Log:
> [ObjC] Follow-up r350768 and allow the use of unavailable methods that are
> declared in a parent class from within the @implementation context
>
> This commit extends r350768 and allows the use of methods marked as
> unavailable
> that are declared in a parent class/category from within the
> @implementation of
> the class where the method is marked as unavailable.
> This allows users to call init that's marked as unavailable even if they
> don't
> define it.
>
> rdar://47134898
>
> Differential Revision: https://reviews.llvm.org/D56816
>
> Modified:
> cfe/trunk/lib/Sema/SemaDeclAttr.cpp
> cfe/trunk/test/SemaObjC/call-unavailable-init-in-self.m
> cfe/trunk/test/SemaObjC/infer-availability-from-init.m
>
> Modified: cfe/trunk/lib/Sema/SemaDeclAttr.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclAttr.cpp?rev=351459=351458=351459=diff
>
> ==
> --- cfe/trunk/lib/Sema/SemaDeclAttr.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaDeclAttr.cpp Thu Jan 17 10:12:45 2019
> @@ -7365,13 +7365,11 @@ ShouldDiagnoseAvailabilityInContext(Sema
>  return true;
>  } else if (K == AR_Unavailable) {
>// It is perfectly fine to refer to an 'unavailable' Objective-C
> method
> -  // when it's actually defined and is referenced from within the
> -  // @implementation itself. In this context, we interpret
> unavailable as a
> -  // form of access control.
> +  // when it is referenced from within the @implementation itself. In
> this
> +  // context, we interpret unavailable as a form of access control.
>if (const auto *MD = dyn_cast(OffendingDecl)) {
>  if (const auto *Impl = dyn_cast(C)) {
> -  if (MD->getClassInterface() == Impl->getClassInterface() &&
> -  MD->isDefined())
> +  if (MD->getClassInterface() == Impl->getClassInterface())
>  return true;
>  }
>}
>
> Modified: cfe/trunk/test/SemaObjC/call-unavailable-init-in-self.m
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaObjC/call-unavailable-init-in-self.m?rev=351459=351458=351459=diff
>
> ==
> --- cfe/trunk/test/SemaObjC/call-unavailable-init-in-self.m (original)
> +++ cfe/trunk/test/SemaObjC/call-unavailable-init-in-self.m Thu Jan 17
> 10:12:45 2019
> @@ -5,13 +5,24 @@
>  + (instancetype)new;
>  + (instancetype)alloc;
>
> +- (void)declaredInSuper;
> +
> +@end
> +
> +@interface NSObject (Category)
> +
> +- (void)declaredInSuperCategory;
> +
>  @end
>
>  @interface Sub: NSObject
>
>  - (instancetype)init __attribute__((unavailable)); // expected-note 4
> {{'init' has been explicitly marked unavailable here}}
>
> -- (void)notImplemented __attribute__((unavailable)); // expected-note
> {{'notImplemented' has been explicitly marked unavailable here}}
> +- (void)notImplemented __attribute__((unavailable));
> +
> +- (void)declaredInSuper __attribute__((unavailable));
> +- (void)declaredInSuperCategory __attribute__((unavailable));
>
>  @end
>
> @@ -34,7 +45,14 @@
>  }
>
>  - (void)reportUseOfUnimplemented {
> -  [self notImplemented]; // expected-error {{'notImplemented' is
> unavailable}}
> +  [self notImplemented];
> +}
> +
> +- (void)allowSuperCallUsingSelf {
> +  [self declaredInSuper];
> +  [[Sub alloc] declaredInSuper];
> +  [self declaredInSuperCategory];
> +  [[Sub alloc] declaredInSuperCategory];
>  }
>
>  @end
>
> Modified: cfe/trunk/test/SemaObjC/infer-availability-from-init.m
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaObjC/infer-availability-from-init.m?rev=351459=351458=351459=diff
>
> ==
> --- cfe/trunk/test/SemaObjC/infer-availability-from-init.m (original)
> +++ cfe/trunk/test/SemaObjC/infer-availability-from-init.m Thu Jan 17
> 10:12:45 2019
> @@ -47,12 +47,12 @@ void usenotmyobject() {
>  }
>
>  @interface FromSelf : NSObject
> --(instancetype)init __attribute__((unavailable)); // expected-note
> {{'init' has been explicitly marked unavailable here}}
> +-(instancetype)init __attribute__((unavailable));
>  +(FromSelf*)another_one;
>  @end
>
>  @implementation FromSelf
>  +(FromSelf*)another_one {
> -  [self new]; // expected-error{{'new' is unavailable}}
> +  [self new];
>  }
>  @end
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list

Re: r350768 - [ObjC] Allow the use of implemented unavailable methods from within

[Alex L via cfe-commits]

Hi,

We are planning to fix this issue by not checking if the method is defined.
I will post a patch this week.

Cheers,
Alex

On Fri, 11 Jan 2019 at 10:26, Alex L  wrote:

> Thanks, we might have similar cases in our code base as well. We'll see if
> we can fix that too.
>
> On Fri, 11 Jan 2019 at 06:13, Nico Weber  wrote:
>
>> Here's some user feedback on this new feature.
>>
>> It looks like the warning is only suppressed if `init` has a definition
>> in the @interface block. In the 4 cases where we saw this warning fire
>> after r349841, it still fires after this change because in all 4 cases a
>> class marked init as unavailable in the @interface but didn't add a
>> definition of it in the classes @implementation (instead relying on calling
>> the superclass's (NSObject) init).
>>
>> It's pretty easy to just add
>>
>> - (instancetype)init { return [super init]; }
>>
>> to these 4 classes, but:
>> a) it doesn't Just Work
>> b) the diagnostic doesn't make it clear that adding a definition of init
>> will suppress the warning.
>>
>> Up to you to decide what (if anything) to do with this feedback :-)
>>
>> (https://bugs.chromium.org/p/chromium/issues/detail?id=917351#c17 has a
>> full reduced code snippet.)
>>
>> On Wed, Jan 9, 2019 at 5:35 PM Alex Lorenz via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: arphaman
>>> Date: Wed Jan  9 14:31:37 2019
>>> New Revision: 350768
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=350768=rev
>>> Log:
>>> [ObjC] Allow the use of implemented unavailable methods from within
>>> the @implementation context
>>>
>>> In Objective-C, it's common for some frameworks to mark some methods
>>> like init
>>> as unavailable in the @interface to prohibit their usage. However, these
>>> frameworks then often implemented said method and refer to it in another
>>> method
>>> that acts as a factory for that object. The recent change to how
>>> messages to
>>> self are type checked in clang (r349841) introduced a regression which
>>> started
>>> to prohibit this pattern with an X is unavailable error. This commit
>>> addresses
>>> the aforementioned regression.
>>>
>>> rdar://47134898
>>>
>>> Differential Revision: https://reviews.llvm.org/D56469
>>>
>>> Added:
>>> cfe/trunk/test/SemaObjC/call-unavailable-init-in-self.m
>>> Modified:
>>> cfe/trunk/lib/Sema/SemaDeclAttr.cpp
>>>
>>> Modified: cfe/trunk/lib/Sema/SemaDeclAttr.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclAttr.cpp?rev=350768=350767=350768=diff
>>>
>>> ==
>>> --- cfe/trunk/lib/Sema/SemaDeclAttr.cpp (original)
>>> +++ cfe/trunk/lib/Sema/SemaDeclAttr.cpp Wed Jan  9 14:31:37 2019
>>> @@ -7269,9 +7269,10 @@ ShouldDiagnoseAvailabilityOfDecl(Sema 
>>>  /// whether we should emit a diagnostic for \c K and \c DeclVersion in
>>>  /// the context of \c Ctx. For example, we should emit an unavailable
>>> diagnostic
>>>  /// in a deprecated context, but not the other way around.
>>> -static bool ShouldDiagnoseAvailabilityInContext(Sema ,
>>> AvailabilityResult K,
>>> -VersionTuple
>>> DeclVersion,
>>> -Decl *Ctx) {
>>> +static bool
>>> +ShouldDiagnoseAvailabilityInContext(Sema , AvailabilityResult K,
>>> +VersionTuple DeclVersion, Decl *Ctx,
>>> +const NamedDecl *OffendingDecl) {
>>>assert(K != AR_Available && "Expected an unavailable declaration
>>> here!");
>>>
>>>// Checks if we should emit the availability diagnostic in the
>>> context of C.
>>> @@ -7280,9 +7281,22 @@ static bool ShouldDiagnoseAvailabilityIn
>>>if (const AvailabilityAttr *AA = getAttrForPlatform(S.Context, C))
>>>  if (AA->getIntroduced() >= DeclVersion)
>>>return true;
>>> -} else if (K == AR_Deprecated)
>>> +} else if (K == AR_Deprecated) {
>>>if (C->isDeprecated())
>>>  return true;
>>> +} else if (K == AR_Unavailable) {
>>> +  // It is perfectly fine to refer to an 'unavailable' Objective-C
>>> method
>>> +  // when it's actually defined and is referenced from within the
>>> +  // @implementation itself. In this context, we interpret
>>> unavailable as a
>>> +  // form of access control.
>>> +  if (const auto *MD = dyn_cast(OffendingDecl)) {
>>> +if (const auto *Impl = dyn_cast(C)) {
>>> +  if (MD->getClassInterface() == Impl->getClassInterface() &&
>>> +  MD->isDefined())
>>> +return true;
>>> +}
>>> +  }
>>> +}
>>>
>>>  if (C->isUnavailable())
>>>return true;
>>> @@ -7471,7 +7485,8 @@ static void DoEmitAvailabilityWarning(Se
>>>if (const AvailabilityAttr *AA = getAttrForPlatform(S.Context,
>>> OffendingDecl))
>>>  DeclVersion = AA->getIntroduced();
>>>
>>> -  if 

Re: r350768 - [ObjC] Allow the use of implemented unavailable methods from within

[Alex L via cfe-commits]

Thanks, we might have similar cases in our code base as well. We'll see if
we can fix that too.

On Fri, 11 Jan 2019 at 06:13, Nico Weber  wrote:

> Here's some user feedback on this new feature.
>
> It looks like the warning is only suppressed if `init` has a definition in
> the @interface block. In the 4 cases where we saw this warning fire after
> r349841, it still fires after this change because in all 4 cases a class
> marked init as unavailable in the @interface but didn't add a definition of
> it in the classes @implementation (instead relying on calling the
> superclass's (NSObject) init).
>
> It's pretty easy to just add
>
> - (instancetype)init { return [super init]; }
>
> to these 4 classes, but:
> a) it doesn't Just Work
> b) the diagnostic doesn't make it clear that adding a definition of init
> will suppress the warning.
>
> Up to you to decide what (if anything) to do with this feedback :-)
>
> (https://bugs.chromium.org/p/chromium/issues/detail?id=917351#c17 has a
> full reduced code snippet.)
>
> On Wed, Jan 9, 2019 at 5:35 PM Alex Lorenz via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: arphaman
>> Date: Wed Jan  9 14:31:37 2019
>> New Revision: 350768
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=350768=rev
>> Log:
>> [ObjC] Allow the use of implemented unavailable methods from within
>> the @implementation context
>>
>> In Objective-C, it's common for some frameworks to mark some methods like
>> init
>> as unavailable in the @interface to prohibit their usage. However, these
>> frameworks then often implemented said method and refer to it in another
>> method
>> that acts as a factory for that object. The recent change to how messages
>> to
>> self are type checked in clang (r349841) introduced a regression which
>> started
>> to prohibit this pattern with an X is unavailable error. This commit
>> addresses
>> the aforementioned regression.
>>
>> rdar://47134898
>>
>> Differential Revision: https://reviews.llvm.org/D56469
>>
>> Added:
>> cfe/trunk/test/SemaObjC/call-unavailable-init-in-self.m
>> Modified:
>> cfe/trunk/lib/Sema/SemaDeclAttr.cpp
>>
>> Modified: cfe/trunk/lib/Sema/SemaDeclAttr.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclAttr.cpp?rev=350768=350767=350768=diff
>>
>> ==
>> --- cfe/trunk/lib/Sema/SemaDeclAttr.cpp (original)
>> +++ cfe/trunk/lib/Sema/SemaDeclAttr.cpp Wed Jan  9 14:31:37 2019
>> @@ -7269,9 +7269,10 @@ ShouldDiagnoseAvailabilityOfDecl(Sema 
>>  /// whether we should emit a diagnostic for \c K and \c DeclVersion in
>>  /// the context of \c Ctx. For example, we should emit an unavailable
>> diagnostic
>>  /// in a deprecated context, but not the other way around.
>> -static bool ShouldDiagnoseAvailabilityInContext(Sema ,
>> AvailabilityResult K,
>> -VersionTuple DeclVersion,
>> -Decl *Ctx) {
>> +static bool
>> +ShouldDiagnoseAvailabilityInContext(Sema , AvailabilityResult K,
>> +VersionTuple DeclVersion, Decl *Ctx,
>> +const NamedDecl *OffendingDecl) {
>>assert(K != AR_Available && "Expected an unavailable declaration
>> here!");
>>
>>// Checks if we should emit the availability diagnostic in the context
>> of C.
>> @@ -7280,9 +7281,22 @@ static bool ShouldDiagnoseAvailabilityIn
>>if (const AvailabilityAttr *AA = getAttrForPlatform(S.Context, C))
>>  if (AA->getIntroduced() >= DeclVersion)
>>return true;
>> -} else if (K == AR_Deprecated)
>> +} else if (K == AR_Deprecated) {
>>if (C->isDeprecated())
>>  return true;
>> +} else if (K == AR_Unavailable) {
>> +  // It is perfectly fine to refer to an 'unavailable' Objective-C
>> method
>> +  // when it's actually defined and is referenced from within the
>> +  // @implementation itself. In this context, we interpret
>> unavailable as a
>> +  // form of access control.
>> +  if (const auto *MD = dyn_cast(OffendingDecl)) {
>> +if (const auto *Impl = dyn_cast(C)) {
>> +  if (MD->getClassInterface() == Impl->getClassInterface() &&
>> +  MD->isDefined())
>> +return true;
>> +}
>> +  }
>> +}
>>
>>  if (C->isUnavailable())
>>return true;
>> @@ -7471,7 +7485,8 @@ static void DoEmitAvailabilityWarning(Se
>>if (const AvailabilityAttr *AA = getAttrForPlatform(S.Context,
>> OffendingDecl))
>>  DeclVersion = AA->getIntroduced();
>>
>> -  if (!ShouldDiagnoseAvailabilityInContext(S, K, DeclVersion, Ctx))
>> +  if (!ShouldDiagnoseAvailabilityInContext(S, K, DeclVersion, Ctx,
>> +   OffendingDecl))
>>  return;
>>
>>SourceLocation Loc = Locs.front();
>> @@ -7955,7 +7970,8 @@ void DiagnoseUnguardedAvailability::Diag
>>
>>  

Re: r336716 - Revert r336590 "[libclang] evalute compound statement cursors before trying to evaluate"

[Alex L via cfe-commits]

Fixed in r350680.

On Tue, 8 Jan 2019 at 15:24, Alex L  wrote:

> Looks like there was another leak I missed. I'm working on fixing it now.
> Cheers,
> Alex
>
> On Tue, 8 Jan 2019 at 14:38, Alex L  wrote:
>
>> Thanks for reverting the commit! Unfortunately I missed the failure back
>> then.
>> I fixed the leak and recommitted the change in r350666.
>>
>> Cheers,
>> Alex
>>
>> On Tue, 10 Jul 2018 at 12:53, Evgeniy Stepanov via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: eugenis
>>> Date: Tue Jul 10 12:49:07 2018
>>> New Revision: 336716
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=336716=rev
>>> Log:
>>> Revert r336590 "[libclang] evalute compound statement cursors before
>>> trying to evaluate"
>>>
>>> New memory leaks in
>>> LibclangParseTest_EvaluateChildExpression_Test::TestBody()
>>>
>>> Modified:
>>> cfe/trunk/tools/libclang/CIndex.cpp
>>> cfe/trunk/unittests/libclang/LibclangTest.cpp
>>>
>>> Modified: cfe/trunk/tools/libclang/CIndex.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/libclang/CIndex.cpp?rev=336716=336715=336716=diff
>>>
>>> ==
>>> --- cfe/trunk/tools/libclang/CIndex.cpp (original)
>>> +++ cfe/trunk/tools/libclang/CIndex.cpp Tue Jul 10 12:49:07 2018
>>> @@ -3890,19 +3890,6 @@ static const ExprEvalResult* evaluateExp
>>>  }
>>>
>>>  CXEvalResult clang_Cursor_Evaluate(CXCursor C) {
>>> -  if (clang_getCursorKind(C) == CXCursor_CompoundStmt) {
>>> -const CompoundStmt *compoundStmt =
>>> cast(getCursorStmt(C));
>>> -Expr *expr = nullptr;
>>> -for (auto *bodyIterator : compoundStmt->body()) {
>>> -  if ((expr = dyn_cast(bodyIterator))) {
>>> -break;
>>> -  }
>>> -}
>>> -if (expr)
>>> -  return const_cast(
>>> -  reinterpret_cast(evaluateExpr(expr, C)));
>>> -  }
>>> -
>>>const Decl *D = getCursorDecl(C);
>>>if (D) {
>>>  const Expr *expr = nullptr;
>>> @@ -3916,6 +3903,19 @@ CXEvalResult clang_Cursor_Evaluate(CXCur
>>>evaluateExpr(const_cast(expr), C)));
>>>  return nullptr;
>>>}
>>> +
>>> +  const CompoundStmt *compoundStmt =
>>> dyn_cast_or_null(getCursorStmt(C));
>>> +  if (compoundStmt) {
>>> +Expr *expr = nullptr;
>>> +for (auto *bodyIterator : compoundStmt->body()) {
>>> +  if ((expr = dyn_cast(bodyIterator))) {
>>> +break;
>>> +  }
>>> +}
>>> +if (expr)
>>> +  return const_cast(
>>> +  reinterpret_cast(evaluateExpr(expr, C)));
>>> +  }
>>>return nullptr;
>>>  }
>>>
>>>
>>> Modified: cfe/trunk/unittests/libclang/LibclangTest.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/libclang/LibclangTest.cpp?rev=336716=336715=336716=diff
>>>
>>> ==
>>> --- cfe/trunk/unittests/libclang/LibclangTest.cpp (original)
>>> +++ cfe/trunk/unittests/libclang/LibclangTest.cpp Tue Jul 10 12:49:07
>>> 2018
>>> @@ -461,47 +461,6 @@ TEST_F(LibclangParseTest, AllSkippedRang
>>>clang_disposeSourceRangeList(Ranges);
>>>  }
>>>
>>> -TEST_F(LibclangParseTest, EvaluateChildExpression) {
>>> -  std::string Main = "main.m";
>>> -  WriteFile(Main, "#define kFOO @\"foo\"\n"
>>> -  "void foobar(void) {\n"
>>> -  " {kFOO;}\n"
>>> -  "}\n");
>>> -  ClangTU = clang_parseTranslationUnit(Index, Main.c_str(), nullptr, 0,
>>> nullptr,
>>> -   0, TUFlags);
>>> -
>>> -  CXCursor C = clang_getTranslationUnitCursor(ClangTU);
>>> -  clang_visitChildren(
>>> -  C,
>>> -  [](CXCursor cursor, CXCursor parent,
>>> - CXClientData client_data) -> CXChildVisitResult {
>>> -if (clang_getCursorKind(cursor) == CXCursor_FunctionDecl) {
>>> -  int numberedStmt = 0;
>>> -  clang_visitChildren(
>>> -  cursor,
>>> -  [](CXCursor cursor, CXCursor parent,
>>> - CXClientData client_data) -> CXChildVisitResult {
>>> -int  = *((int *)client_data);
>>> -if (clang_getCursorKind(cursor) ==
>>> CXCursor_CompoundStmt) {
>>> -  if (numberedStmt) {
>>> -CXEvalResult RE = clang_Cursor_Evaluate(cursor);
>>> -EXPECT_NE(RE, nullptr);
>>> -EXPECT_EQ(clang_EvalResult_getKind(RE),
>>> -  CXEval_ObjCStrLiteral);
>>> -return CXChildVisit_Break;
>>> -  }
>>> -  numberedStmt++;
>>> -}
>>> -return CXChildVisit_Recurse;
>>> -  },
>>> -  );
>>> -  EXPECT_EQ(numberedStmt, 1);
>>> -}
>>> -return CXChildVisit_Continue;
>>> -  },
>>> -  nullptr);
>>> -}
>>> -
>>>  class LibclangReparseTest : public LibclangParseTest {
>>>  public:
>>>void DisplayDiagnostics() {
>>>
>>>
>>> 

Re: r336716 - Revert r336590 "[libclang] evalute compound statement cursors before trying to evaluate"

[Alex L via cfe-commits]

Looks like there was another leak I missed. I'm working on fixing it now.
Cheers,
Alex

On Tue, 8 Jan 2019 at 14:38, Alex L  wrote:

> Thanks for reverting the commit! Unfortunately I missed the failure back
> then.
> I fixed the leak and recommitted the change in r350666.
>
> Cheers,
> Alex
>
> On Tue, 10 Jul 2018 at 12:53, Evgeniy Stepanov via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: eugenis
>> Date: Tue Jul 10 12:49:07 2018
>> New Revision: 336716
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=336716=rev
>> Log:
>> Revert r336590 "[libclang] evalute compound statement cursors before
>> trying to evaluate"
>>
>> New memory leaks in
>> LibclangParseTest_EvaluateChildExpression_Test::TestBody()
>>
>> Modified:
>> cfe/trunk/tools/libclang/CIndex.cpp
>> cfe/trunk/unittests/libclang/LibclangTest.cpp
>>
>> Modified: cfe/trunk/tools/libclang/CIndex.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/libclang/CIndex.cpp?rev=336716=336715=336716=diff
>>
>> ==
>> --- cfe/trunk/tools/libclang/CIndex.cpp (original)
>> +++ cfe/trunk/tools/libclang/CIndex.cpp Tue Jul 10 12:49:07 2018
>> @@ -3890,19 +3890,6 @@ static const ExprEvalResult* evaluateExp
>>  }
>>
>>  CXEvalResult clang_Cursor_Evaluate(CXCursor C) {
>> -  if (clang_getCursorKind(C) == CXCursor_CompoundStmt) {
>> -const CompoundStmt *compoundStmt =
>> cast(getCursorStmt(C));
>> -Expr *expr = nullptr;
>> -for (auto *bodyIterator : compoundStmt->body()) {
>> -  if ((expr = dyn_cast(bodyIterator))) {
>> -break;
>> -  }
>> -}
>> -if (expr)
>> -  return const_cast(
>> -  reinterpret_cast(evaluateExpr(expr, C)));
>> -  }
>> -
>>const Decl *D = getCursorDecl(C);
>>if (D) {
>>  const Expr *expr = nullptr;
>> @@ -3916,6 +3903,19 @@ CXEvalResult clang_Cursor_Evaluate(CXCur
>>evaluateExpr(const_cast(expr), C)));
>>  return nullptr;
>>}
>> +
>> +  const CompoundStmt *compoundStmt =
>> dyn_cast_or_null(getCursorStmt(C));
>> +  if (compoundStmt) {
>> +Expr *expr = nullptr;
>> +for (auto *bodyIterator : compoundStmt->body()) {
>> +  if ((expr = dyn_cast(bodyIterator))) {
>> +break;
>> +  }
>> +}
>> +if (expr)
>> +  return const_cast(
>> +  reinterpret_cast(evaluateExpr(expr, C)));
>> +  }
>>return nullptr;
>>  }
>>
>>
>> Modified: cfe/trunk/unittests/libclang/LibclangTest.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/libclang/LibclangTest.cpp?rev=336716=336715=336716=diff
>>
>> ==
>> --- cfe/trunk/unittests/libclang/LibclangTest.cpp (original)
>> +++ cfe/trunk/unittests/libclang/LibclangTest.cpp Tue Jul 10 12:49:07 2018
>> @@ -461,47 +461,6 @@ TEST_F(LibclangParseTest, AllSkippedRang
>>clang_disposeSourceRangeList(Ranges);
>>  }
>>
>> -TEST_F(LibclangParseTest, EvaluateChildExpression) {
>> -  std::string Main = "main.m";
>> -  WriteFile(Main, "#define kFOO @\"foo\"\n"
>> -  "void foobar(void) {\n"
>> -  " {kFOO;}\n"
>> -  "}\n");
>> -  ClangTU = clang_parseTranslationUnit(Index, Main.c_str(), nullptr, 0,
>> nullptr,
>> -   0, TUFlags);
>> -
>> -  CXCursor C = clang_getTranslationUnitCursor(ClangTU);
>> -  clang_visitChildren(
>> -  C,
>> -  [](CXCursor cursor, CXCursor parent,
>> - CXClientData client_data) -> CXChildVisitResult {
>> -if (clang_getCursorKind(cursor) == CXCursor_FunctionDecl) {
>> -  int numberedStmt = 0;
>> -  clang_visitChildren(
>> -  cursor,
>> -  [](CXCursor cursor, CXCursor parent,
>> - CXClientData client_data) -> CXChildVisitResult {
>> -int  = *((int *)client_data);
>> -if (clang_getCursorKind(cursor) ==
>> CXCursor_CompoundStmt) {
>> -  if (numberedStmt) {
>> -CXEvalResult RE = clang_Cursor_Evaluate(cursor);
>> -EXPECT_NE(RE, nullptr);
>> -EXPECT_EQ(clang_EvalResult_getKind(RE),
>> -  CXEval_ObjCStrLiteral);
>> -return CXChildVisit_Break;
>> -  }
>> -  numberedStmt++;
>> -}
>> -return CXChildVisit_Recurse;
>> -  },
>> -  );
>> -  EXPECT_EQ(numberedStmt, 1);
>> -}
>> -return CXChildVisit_Continue;
>> -  },
>> -  nullptr);
>> -}
>> -
>>  class LibclangReparseTest : public LibclangParseTest {
>>  public:
>>void DisplayDiagnostics() {
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>
___

Re: r336716 - Revert r336590 "[libclang] evalute compound statement cursors before trying to evaluate"

[Alex L via cfe-commits]

Thanks for reverting the commit! Unfortunately I missed the failure back
then.
I fixed the leak and recommitted the change in r350666.

Cheers,
Alex

On Tue, 10 Jul 2018 at 12:53, Evgeniy Stepanov via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: eugenis
> Date: Tue Jul 10 12:49:07 2018
> New Revision: 336716
>
> URL: http://llvm.org/viewvc/llvm-project?rev=336716=rev
> Log:
> Revert r336590 "[libclang] evalute compound statement cursors before
> trying to evaluate"
>
> New memory leaks in
> LibclangParseTest_EvaluateChildExpression_Test::TestBody()
>
> Modified:
> cfe/trunk/tools/libclang/CIndex.cpp
> cfe/trunk/unittests/libclang/LibclangTest.cpp
>
> Modified: cfe/trunk/tools/libclang/CIndex.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/libclang/CIndex.cpp?rev=336716=336715=336716=diff
>
> ==
> --- cfe/trunk/tools/libclang/CIndex.cpp (original)
> +++ cfe/trunk/tools/libclang/CIndex.cpp Tue Jul 10 12:49:07 2018
> @@ -3890,19 +3890,6 @@ static const ExprEvalResult* evaluateExp
>  }
>
>  CXEvalResult clang_Cursor_Evaluate(CXCursor C) {
> -  if (clang_getCursorKind(C) == CXCursor_CompoundStmt) {
> -const CompoundStmt *compoundStmt =
> cast(getCursorStmt(C));
> -Expr *expr = nullptr;
> -for (auto *bodyIterator : compoundStmt->body()) {
> -  if ((expr = dyn_cast(bodyIterator))) {
> -break;
> -  }
> -}
> -if (expr)
> -  return const_cast(
> -  reinterpret_cast(evaluateExpr(expr, C)));
> -  }
> -
>const Decl *D = getCursorDecl(C);
>if (D) {
>  const Expr *expr = nullptr;
> @@ -3916,6 +3903,19 @@ CXEvalResult clang_Cursor_Evaluate(CXCur
>evaluateExpr(const_cast(expr), C)));
>  return nullptr;
>}
> +
> +  const CompoundStmt *compoundStmt =
> dyn_cast_or_null(getCursorStmt(C));
> +  if (compoundStmt) {
> +Expr *expr = nullptr;
> +for (auto *bodyIterator : compoundStmt->body()) {
> +  if ((expr = dyn_cast(bodyIterator))) {
> +break;
> +  }
> +}
> +if (expr)
> +  return const_cast(
> +  reinterpret_cast(evaluateExpr(expr, C)));
> +  }
>return nullptr;
>  }
>
>
> Modified: cfe/trunk/unittests/libclang/LibclangTest.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/libclang/LibclangTest.cpp?rev=336716=336715=336716=diff
>
> ==
> --- cfe/trunk/unittests/libclang/LibclangTest.cpp (original)
> +++ cfe/trunk/unittests/libclang/LibclangTest.cpp Tue Jul 10 12:49:07 2018
> @@ -461,47 +461,6 @@ TEST_F(LibclangParseTest, AllSkippedRang
>clang_disposeSourceRangeList(Ranges);
>  }
>
> -TEST_F(LibclangParseTest, EvaluateChildExpression) {
> -  std::string Main = "main.m";
> -  WriteFile(Main, "#define kFOO @\"foo\"\n"
> -  "void foobar(void) {\n"
> -  " {kFOO;}\n"
> -  "}\n");
> -  ClangTU = clang_parseTranslationUnit(Index, Main.c_str(), nullptr, 0,
> nullptr,
> -   0, TUFlags);
> -
> -  CXCursor C = clang_getTranslationUnitCursor(ClangTU);
> -  clang_visitChildren(
> -  C,
> -  [](CXCursor cursor, CXCursor parent,
> - CXClientData client_data) -> CXChildVisitResult {
> -if (clang_getCursorKind(cursor) == CXCursor_FunctionDecl) {
> -  int numberedStmt = 0;
> -  clang_visitChildren(
> -  cursor,
> -  [](CXCursor cursor, CXCursor parent,
> - CXClientData client_data) -> CXChildVisitResult {
> -int  = *((int *)client_data);
> -if (clang_getCursorKind(cursor) == CXCursor_CompoundStmt)
> {
> -  if (numberedStmt) {
> -CXEvalResult RE = clang_Cursor_Evaluate(cursor);
> -EXPECT_NE(RE, nullptr);
> -EXPECT_EQ(clang_EvalResult_getKind(RE),
> -  CXEval_ObjCStrLiteral);
> -return CXChildVisit_Break;
> -  }
> -  numberedStmt++;
> -}
> -return CXChildVisit_Recurse;
> -  },
> -  );
> -  EXPECT_EQ(numberedStmt, 1);
> -}
> -return CXChildVisit_Continue;
> -  },
> -  nullptr);
> -}
> -
>  class LibclangReparseTest : public LibclangParseTest {
>  public:
>void DisplayDiagnostics() {
>
>
> ___
> 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: r350282 - [libclang] CoroutineBody/Coreturn statements are UnexposedStmts and not Exprs

[Alex L via cfe-commits]

Oops, I committed wrong column number in the test due to reindentation.
Fixed in r350283.

~ Alex

On Wed, 2 Jan 2019 at 17:16, Alex Lorenz via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: arphaman
> Date: Wed Jan  2 17:13:33 2019
> New Revision: 350282
>
> URL: http://llvm.org/viewvc/llvm-project?rev=350282=rev
> Log:
> [libclang] CoroutineBody/Coreturn statements are UnexposedStmts and not
> Exprs
>
> This change ensures that the libclang CXCursor represents the CoroutineBody
> and the Coreturn statement using the appropriate CXCursor_UnexposedStmt
> kind
> instead of CXCursor_UnexposedExpr. The problem with CXCursor_UnexposedExpr
> is
> that the consumer functions assumed that CoroutineBody/Coreturn statements
> were valid expressions and performed an invalid downcast to Expr causing
> assertion failures or other crashes.
>
> rdar://40204290
>
> Added:
> cfe/trunk/test/Index/coroutines.cpp
> Modified:
> cfe/trunk/tools/libclang/CXCursor.cpp
>
> Added: cfe/trunk/test/Index/coroutines.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Index/coroutines.cpp?rev=350282=auto
>
> ==
> --- cfe/trunk/test/Index/coroutines.cpp (added)
> +++ cfe/trunk/test/Index/coroutines.cpp Wed Jan  2 17:13:33 2019
> @@ -0,0 +1,24 @@
> +// RUN: c-index-test -test-load-source all -c %s -fsyntax-only -target
> x86_64-apple-darwin9 -fcoroutines-ts -std=c++1z -I%S/../SemaCXX/Inputs |
> FileCheck %s
> +#include "std-coroutine.h"
> +
> +using std::experimental::suspend_always;
> +using std::experimental::suspend_never;
> +
> +struct promise_void {
> +  void get_return_object();
> +  suspend_always initial_suspend();
> +  suspend_always final_suspend();
> +  void return_void();
> +  void unhandled_exception();
> +};
> +
> +template <>
> +struct std::experimental::coroutine_traits { using promise_type =
> promise_void; };
> +
> +void CoroutineTestRet() {
> +  co_return;
> +}
> +// CHECK: [[@LINE-3]]:25: UnexposedStmt=
> +// CHECK-SAME: [[@LINE-4]]:25 - [[@LINE-2]]:2]
> +// CHECK: [[@LINE-4]]:5: UnexposedStmt=
> +// CHECK-SAME: [[@LINE-5]]:5 - [[@LINE-5]]:14]
>
> Modified: cfe/trunk/tools/libclang/CXCursor.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/libclang/CXCursor.cpp?rev=350282=350281=350282=diff
>
> ==
> --- cfe/trunk/tools/libclang/CXCursor.cpp (original)
> +++ cfe/trunk/tools/libclang/CXCursor.cpp Wed Jan  2 17:13:33 2019
> @@ -241,16 +241,19 @@ CXCursor cxcursor::MakeCXCursor(const St
>case Stmt::SEHLeaveStmtClass:
>  K = CXCursor_SEHLeaveStmt;
>  break;
> -
> +
> +  case Stmt::CoroutineBodyStmtClass:
> +  case Stmt::CoreturnStmtClass:
> +K = CXCursor_UnexposedStmt;
> +break;
> +
>case Stmt::ArrayTypeTraitExprClass:
>case Stmt::AsTypeExprClass:
>case Stmt::AtomicExprClass:
>case Stmt::BinaryConditionalOperatorClass:
>case Stmt::TypeTraitExprClass:
> -  case Stmt::CoroutineBodyStmtClass:
>case Stmt::CoawaitExprClass:
>case Stmt::DependentCoawaitExprClass:
> -  case Stmt::CoreturnStmtClass:
>case Stmt::CoyieldExprClass:
>case Stmt::CXXBindTemporaryExprClass:
>case Stmt::CXXDefaultArgExprClass:
>
>
> ___
> 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: r335081 - Recommit r335063: [Darwin] Add a warning for missing include path for libstdc++

[Alex L via cfe-commits]

On Fri, 7 Sep 2018 at 12:02, Alex L  wrote:

>
> On Fri, 7 Sep 2018 at 05:41, Nico Weber  wrote:
>
>> On Wed, Sep 5, 2018 at 9:25 PM Alex L  wrote:
>>
>>> Sorry for the late response,
>>>
>>> On Sat, 18 Aug 2018 at 20:10, Nico Weber  wrote:
>>>
 Also, the diag text should probably say "pass '-stdlib=libc++' " not
 "pass '-std=libc++' "?

>>>
>>> Good catch, thanks! I'll commit a fixup for it.
>>>
>>
> Fixed in r341697.
>
>
>>
>>>

 On Sat, Aug 18, 2018 at 11:06 PM Nico Weber 
 wrote:

> Should this maybe not be emitted when compiling e.g. .ii files
> (preprocessed output)? I just got this when I built a standalone .ii file
> with some bug repro after I deleted all -I and -isysroot flags and 
> whatnot,
> since they aren't needed for preprocessed files.
>

>>> That would make sense, but I'm not sure how easy it is to determine if a
>>> file is already preprocessed. I'll try to create a patch for this fixup.
>>>
>>
>> Probably you'd want something like
>> http://llvm-cs.pcc.me.uk/tools/clang/lib/Driver/Types.cpp#123 that
>> returns true for all (or most) of the TY_PP_ types, and then just rely
>> on lookupTypeForExtension.
>>
>
> Good idea, I'll try it out.
>

Apologies for the delay, I fixed the issue with preprocessed inputs in
r348540.

Cheers,
Alex


>
>
>>
>>
>>>
>>>
>>>

> On Tue, Jun 19, 2018 at 6:52 PM Alex Lorenz via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: arphaman
>> Date: Tue Jun 19 15:47:53 2018
>> New Revision: 335081
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=335081=rev
>> Log:
>> Recommit r335063: [Darwin] Add a warning for missing include path for
>> libstdc++
>>
>> The recommit ensures that the tests that failed on bots don't trigger
>> the warning.
>>
>> Xcode 10 removes support for libstdc++, but the users just get a
>> confusing
>> include not file warning when including an STL header (when building
>> for iOS6
>> which uses libstdc++ by default for example).
>> This patch adds a new warning that lets the user know that the
>> libstdc++ include
>> path was not found to ensure that the user is more aware of why the
>> error occurs.
>>
>> rdar://40830462
>>
>> Differential Revision: https://reviews.llvm.org/D48297
>>
>> Added:
>> cfe/trunk/test/Frontend/warning-stdlibcxx-darwin.cpp
>> Modified:
>> cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
>> cfe/trunk/include/clang/Lex/HeaderSearch.h
>> cfe/trunk/lib/Frontend/InitHeaderSearch.cpp
>> cfe/trunk/test/CodeGenCXX/apple-kext-guard-variable.cpp
>> cfe/trunk/test/Misc/backend-stack-frame-diagnostics.cpp
>>
>> Modified: cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td?rev=335081=335080=335081=diff
>>
>> ==
>> --- cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
>> (original)
>> +++ cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td Tue Jun
>> 19 15:47:53 2018
>> @@ -236,4 +236,9 @@ def err_invalid_vfs_overlay : Error<
>>
>>  def warn_option_invalid_ocl_version : Warning<
>>"OpenCL version %0 does not support the option '%1'">,
>> InGroup;
>> +
>> +def warn_stdlibcxx_not_found : Warning<
>> +  "include path for stdlibc++ headers not found; pass '-std=libc++'
>> on the "
>> +  "command line to use the libc++ standard library instead">,
>> +  InGroup>;
>>  }
>>
>> Modified: cfe/trunk/include/clang/Lex/HeaderSearch.h
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Lex/HeaderSearch.h?rev=335081=335080=335081=diff
>>
>> ==
>> --- cfe/trunk/include/clang/Lex/HeaderSearch.h (original)
>> +++ cfe/trunk/include/clang/Lex/HeaderSearch.h Tue Jun 19 15:47:53
>> 2018
>> @@ -272,6 +272,8 @@ public:
>>
>>FileManager () const { return FileMgr; }
>>
>> +  DiagnosticsEngine () const { return Diags; }
>> +
>>/// Interface for setting the file search paths.
>>void SetSearchPaths(const std::vector ,
>>unsigned angledDirIdx, unsigned systemDirIdx,
>>
>> Modified: cfe/trunk/lib/Frontend/InitHeaderSearch.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/InitHeaderSearch.cpp?rev=335081=335080=335081=diff
>>
>> ==
>> --- cfe/trunk/lib/Frontend/InitHeaderSearch.cpp (original)
>> +++ cfe/trunk/lib/Frontend/InitHeaderSearch.cpp Tue Jun 19 15:47:53
>> 2018
>> @@ -14,6 +14,7 @@

Re: [cfe-dev] r347339 - [clang][Parse] Diagnose useless null statements / empty init-statements

[Alex L via cfe-commits]

We have about 100k unique occurrences of this warning across a slice of our
software stack. It's simply not feasible to us to adopt it, so we would
prefer for it to be reverted to avoid downstream divergence in Apple's
clang. Granted, these occur in projects that use -Weverything but those
projects are typically understanding of warnings that they can turn off
when they see that they provide useful value in terms of warnings about
unintended behavior that's sometimes caught. This warning doesn't seem to
catch unintended bugs and it would be a heroic battle to adopt it for us in
a way where projects are somewhat satisfied. It seems to be a better fit
for a clang-tidy check that could suggest automatic fixits and that the
users could run on their codebase to "modernize" if they want to.

Cheers,
Alex

On Wed, 5 Dec 2018 at 10:43, Richard Smith via cfe-dev <
cfe-...@lists.llvm.org> wrote:

> On Wed, 5 Dec 2018, 10:01 George Karpenkov via cfe-commits <
> cfe-commits@lists.llvm.org wrote:
>
>> These are the cases I get:
>>
>> #define unexpected(a) { kprintf("unexpected %s:%d\n", __FILE__,
>> __LINE__); a; }
>>
>> and
>>
>> #if 0
>> #define DEBG(fmt, args...)  { IOLog(fmt, ## args); kprintf(fmt, ##
>> args); }
>> #else
>> #define DEBG(fmt, args...)  {}
>> #endif
>>
>> Now calls
>>
>> `DEBG(‘x’);` and `unexpected(‘msg’);`
>>
>> cause the warning to be fired.
>> Of course, semicolon could be omitted, but the fact that the macro has
>> braces is sort of an implementation detail.
>>
>> Greg Parker has pointed out it’s possible to rewrite the macros using the
>> “do { … } while (0)”,
>> but that is a lot of macros to change, and the resulting code would be
>> arguably less readable.
>>
>
> That suggestion is the (or at least an) idiomatic way to write a
> "statement-like" macro that expects a semicolon. The approach taken by the
> above macros is often considered to be a macro antipattern (try putting it
> in an unbraced if and adding an else clause, for example).
>
>> On Dec 5, 2018, at 5:10 AM, Aaron Ballman  wrote:
>>
>> On Wed, Dec 5, 2018 at 1:40 AM Roman Lebedev 
>> wrote:
>>
>>
>> It is a problem in practice for us since we have projects which enable
>> all available warnings and also enable “-Werror”.
>>
>> Hm, they have asked for -Weverything and they got it. Seems to be
>> working as intended.
>> When in previous discussions elsewhere i have talked about
>> -Weverything, i was always
>> been told that it isn't supposed to be used like that (admittedly, i
>> *do* use it like that :)).
>>
>> Could you explain how is this different from any other warning that is
>> considered pointless by the project?
>> Why not simply disable it?
>>
>>
>> You are right, it could be disabled. It’s just for this warning the noise
>> vs. usefulness ratio seemed pretty low.
>>
>>
>> Would you be okay with the warning if it was only diagnosed when the
>> source location of the semi-colon is not immediately preceded by a
>> macro expansion location? e.g.,
>>
>> EMPTY_EXPANSION(12); // Not diagnosed
>> EMPTY_EXPANSION; // Not diagnosed
>> ; // Diagnosed
>>
>> This could work provided that all empty space preceding the semicolon is
>> ignored (as the macro could be separated by space(s) or newline(s).
>> I’m not sure the complexity would be worth it, as I haven’t seen bugs
>> arising from extra semicolons and empty statements,
>> but it would take care of my use case.
>>
>>
>> Or rather when the *previous* semicolon is coming from a macro.
>>
>> I don't like this. clang is already wa-a-ay too forgiving about
>> macros, it almost ignores almost every warning in macros.
>> It was an *intentional* decision to still warn on useless ';' after
>> non-empty macros.
>>
>>
>> I think I'm confused now. This is a test case:
>>
>> NULLMACRO(v7); // OK. This could be either GOODMACRO() or
>> BETTERMACRO() situation, so we can't know we can drop it.
>>
>> So empty macro expansions should be ignored as I expected... so what
>> is being diagnosed? George, can you provide a more clear example that
>> demonstrates the issue?
>>
>> To be clear, I do *not* think this is a situation we should spend
>> effort supporting (assuming "all available warnings" really means
>> -Weverything and not something else):
>>
>> It is a problem in practice for us since we have projects which enable
>> all available warnings and also enable “-Werror”.
>>
>>
>> However, if we are diagnosing *empty* macro expansions followed by a
>> semi-colon, I think that would be unacceptably chatty and is worth
>> fixing on its own merits.
>>
>> ~Aaron
>>
>>
>> ~Aaron
>>
>> Regards,
>> George
>>
>> Roman.
>>
>> On Nov 20, 2018, at 10:59 AM, Roman Lebedev via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>> Author: lebedevri
>> Date: Tue Nov 20 10:59:05 2018
>> New Revision: 347339
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=347339=rev
>> Log:
>> [clang][Parse] Diagnose useless null statements / empty init-statements
>>
>> Summary:
>> clang has `-Wextra-semi` 

Re: r335081 - Recommit r335063: [Darwin] Add a warning for missing include path for libstdc++

[Alex L via cfe-commits]

On Fri, 7 Sep 2018 at 05:41, Nico Weber  wrote:

> On Wed, Sep 5, 2018 at 9:25 PM Alex L  wrote:
>
>> Sorry for the late response,
>>
>> On Sat, 18 Aug 2018 at 20:10, Nico Weber  wrote:
>>
>>> Also, the diag text should probably say "pass '-stdlib=libc++' " not
>>> "pass '-std=libc++' "?
>>>
>>
>> Good catch, thanks! I'll commit a fixup for it.
>>
>
Fixed in r341697.


>
>>
>>>
>>> On Sat, Aug 18, 2018 at 11:06 PM Nico Weber  wrote:
>>>
 Should this maybe not be emitted when compiling e.g. .ii files
 (preprocessed output)? I just got this when I built a standalone .ii file
 with some bug repro after I deleted all -I and -isysroot flags and whatnot,
 since they aren't needed for preprocessed files.

>>>
>> That would make sense, but I'm not sure how easy it is to determine if a
>> file is already preprocessed. I'll try to create a patch for this fixup.
>>
>
> Probably you'd want something like
> http://llvm-cs.pcc.me.uk/tools/clang/lib/Driver/Types.cpp#123 that
> returns true for all (or most) of the TY_PP_ types, and then just rely
> on lookupTypeForExtension.
>

Good idea, I'll try it out.


>
>
>>
>>
>>
>>>
 On Tue, Jun 19, 2018 at 6:52 PM Alex Lorenz via cfe-commits <
 cfe-commits@lists.llvm.org> wrote:

> Author: arphaman
> Date: Tue Jun 19 15:47:53 2018
> New Revision: 335081
>
> URL: http://llvm.org/viewvc/llvm-project?rev=335081=rev
> Log:
> Recommit r335063: [Darwin] Add a warning for missing include path for
> libstdc++
>
> The recommit ensures that the tests that failed on bots don't trigger
> the warning.
>
> Xcode 10 removes support for libstdc++, but the users just get a
> confusing
> include not file warning when including an STL header (when building
> for iOS6
> which uses libstdc++ by default for example).
> This patch adds a new warning that lets the user know that the
> libstdc++ include
> path was not found to ensure that the user is more aware of why the
> error occurs.
>
> rdar://40830462
>
> Differential Revision: https://reviews.llvm.org/D48297
>
> Added:
> cfe/trunk/test/Frontend/warning-stdlibcxx-darwin.cpp
> Modified:
> cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
> cfe/trunk/include/clang/Lex/HeaderSearch.h
> cfe/trunk/lib/Frontend/InitHeaderSearch.cpp
> cfe/trunk/test/CodeGenCXX/apple-kext-guard-variable.cpp
> cfe/trunk/test/Misc/backend-stack-frame-diagnostics.cpp
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td?rev=335081=335080=335081=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td Tue Jun
> 19 15:47:53 2018
> @@ -236,4 +236,9 @@ def err_invalid_vfs_overlay : Error<
>
>  def warn_option_invalid_ocl_version : Warning<
>"OpenCL version %0 does not support the option '%1'">,
> InGroup;
> +
> +def warn_stdlibcxx_not_found : Warning<
> +  "include path for stdlibc++ headers not found; pass '-std=libc++'
> on the "
> +  "command line to use the libc++ standard library instead">,
> +  InGroup>;
>  }
>
> Modified: cfe/trunk/include/clang/Lex/HeaderSearch.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Lex/HeaderSearch.h?rev=335081=335080=335081=diff
>
> ==
> --- cfe/trunk/include/clang/Lex/HeaderSearch.h (original)
> +++ cfe/trunk/include/clang/Lex/HeaderSearch.h Tue Jun 19 15:47:53 2018
> @@ -272,6 +272,8 @@ public:
>
>FileManager () const { return FileMgr; }
>
> +  DiagnosticsEngine () const { return Diags; }
> +
>/// Interface for setting the file search paths.
>void SetSearchPaths(const std::vector ,
>unsigned angledDirIdx, unsigned systemDirIdx,
>
> Modified: cfe/trunk/lib/Frontend/InitHeaderSearch.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/InitHeaderSearch.cpp?rev=335081=335080=335081=diff
>
> ==
> --- cfe/trunk/lib/Frontend/InitHeaderSearch.cpp (original)
> +++ cfe/trunk/lib/Frontend/InitHeaderSearch.cpp Tue Jun 19 15:47:53
> 2018
> @@ -14,6 +14,7 @@
>  #include "clang/Basic/FileManager.h"
>  #include "clang/Basic/LangOptions.h"
>  #include "clang/Config/config.h" // C_INCLUDE_DIRS
> +#include "clang/Frontend/FrontendDiagnostic.h"
>  #include "clang/Frontend/Utils.h"
>  #include "clang/Lex/HeaderMap.h"
>  #include 

Re: r335081 - Recommit r335063: [Darwin] Add a warning for missing include path for libstdc++

[Alex L via cfe-commits]

Sorry for the late response,

On Sat, 18 Aug 2018 at 20:10, Nico Weber  wrote:

> Also, the diag text should probably say "pass '-stdlib=libc++' " not "pass
> '-std=libc++' "?
>

Good catch, thanks! I'll commit a fixup for it.


>
> On Sat, Aug 18, 2018 at 11:06 PM Nico Weber  wrote:
>
>> Should this maybe not be emitted when compiling e.g. .ii files
>> (preprocessed output)? I just got this when I built a standalone .ii file
>> with some bug repro after I deleted all -I and -isysroot flags and whatnot,
>> since they aren't needed for preprocessed files.
>>
>
That would make sense, but I'm not sure how easy it is to determine if a
file is already preprocessed. I'll try to create a patch for this fixup.



>
>> On Tue, Jun 19, 2018 at 6:52 PM Alex Lorenz via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: arphaman
>>> Date: Tue Jun 19 15:47:53 2018
>>> New Revision: 335081
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=335081=rev
>>> Log:
>>> Recommit r335063: [Darwin] Add a warning for missing include path for
>>> libstdc++
>>>
>>> The recommit ensures that the tests that failed on bots don't trigger
>>> the warning.
>>>
>>> Xcode 10 removes support for libstdc++, but the users just get a
>>> confusing
>>> include not file warning when including an STL header (when building for
>>> iOS6
>>> which uses libstdc++ by default for example).
>>> This patch adds a new warning that lets the user know that the libstdc++
>>> include
>>> path was not found to ensure that the user is more aware of why the
>>> error occurs.
>>>
>>> rdar://40830462
>>>
>>> Differential Revision: https://reviews.llvm.org/D48297
>>>
>>> Added:
>>> cfe/trunk/test/Frontend/warning-stdlibcxx-darwin.cpp
>>> Modified:
>>> cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
>>> cfe/trunk/include/clang/Lex/HeaderSearch.h
>>> cfe/trunk/lib/Frontend/InitHeaderSearch.cpp
>>> cfe/trunk/test/CodeGenCXX/apple-kext-guard-variable.cpp
>>> cfe/trunk/test/Misc/backend-stack-frame-diagnostics.cpp
>>>
>>> Modified: cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td?rev=335081=335080=335081=diff
>>>
>>> ==
>>> --- cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td (original)
>>> +++ cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td Tue Jun 19
>>> 15:47:53 2018
>>> @@ -236,4 +236,9 @@ def err_invalid_vfs_overlay : Error<
>>>
>>>  def warn_option_invalid_ocl_version : Warning<
>>>"OpenCL version %0 does not support the option '%1'">,
>>> InGroup;
>>> +
>>> +def warn_stdlibcxx_not_found : Warning<
>>> +  "include path for stdlibc++ headers not found; pass '-std=libc++' on
>>> the "
>>> +  "command line to use the libc++ standard library instead">,
>>> +  InGroup>;
>>>  }
>>>
>>> Modified: cfe/trunk/include/clang/Lex/HeaderSearch.h
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Lex/HeaderSearch.h?rev=335081=335080=335081=diff
>>>
>>> ==
>>> --- cfe/trunk/include/clang/Lex/HeaderSearch.h (original)
>>> +++ cfe/trunk/include/clang/Lex/HeaderSearch.h Tue Jun 19 15:47:53 2018
>>> @@ -272,6 +272,8 @@ public:
>>>
>>>FileManager () const { return FileMgr; }
>>>
>>> +  DiagnosticsEngine () const { return Diags; }
>>> +
>>>/// Interface for setting the file search paths.
>>>void SetSearchPaths(const std::vector ,
>>>unsigned angledDirIdx, unsigned systemDirIdx,
>>>
>>> Modified: cfe/trunk/lib/Frontend/InitHeaderSearch.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/InitHeaderSearch.cpp?rev=335081=335080=335081=diff
>>>
>>> ==
>>> --- cfe/trunk/lib/Frontend/InitHeaderSearch.cpp (original)
>>> +++ cfe/trunk/lib/Frontend/InitHeaderSearch.cpp Tue Jun 19 15:47:53 2018
>>> @@ -14,6 +14,7 @@
>>>  #include "clang/Basic/FileManager.h"
>>>  #include "clang/Basic/LangOptions.h"
>>>  #include "clang/Config/config.h" // C_INCLUDE_DIRS
>>> +#include "clang/Frontend/FrontendDiagnostic.h"
>>>  #include "clang/Frontend/Utils.h"
>>>  #include "clang/Lex/HeaderMap.h"
>>>  #include "clang/Lex/HeaderSearch.h"
>>> @@ -55,11 +56,13 @@ public:
>>>
>>>/// AddPath - Add the specified path to the specified group list,
>>> prefixing
>>>/// the sysroot if used.
>>> -  void AddPath(const Twine , IncludeDirGroup Group, bool
>>> isFramework);
>>> +  /// Returns true if the path exists, false if it was ignored.
>>> +  bool AddPath(const Twine , IncludeDirGroup Group, bool
>>> isFramework);
>>>
>>>/// AddUnmappedPath - Add the specified path to the specified group
>>> list,
>>>/// without performing any sysroot remapping.
>>> -  void AddUnmappedPath(const Twine , IncludeDirGroup Group,
>>> +  /// 

Re: [PATCH] D50154: [clangd] capitalize diagnostic messages

[Alex L via cfe-commits]

On 7 August 2018 at 17:40, Fangrui Song  wrote:

>
> On 2018-08-07, David Blaikie wrote:
>
>>
>> On Tue, Aug 7, 2018 at 4:02 PM Alex L  wrote:
>>
>>On Tue, 7 Aug 2018 at 11:38, David Blaikie  wrote:
>>
>>On Tue, Aug 7, 2018 at 11:22 AM Alex L  wrote:
>>
>>On Tue, 7 Aug 2018 at 10:52, David Blaikie via cfe-commits <
>>cfe-commits@lists.llvm.org> wrote:
>>
>>On Tue, Aug 7, 2018 at 10:33 AM Alex Lorenz via
>> Phabricator <
>>revi...@reviews.llvm.org> wrote:
>>
>>arphaman added a comment.
>>
>>In https://reviews.llvm.org/D50154#1191002, @dblaikie
>>wrote:
>>
>>> What's the motivation for clangd to differ from clang
>>here? (& if the first
>>>  letter is going to be capitalized, should there be a
>>period at the end? But
>>>  also the phrasing of most/all diagnostic text isn't
>> in
>>the form of complete
>>>  sentences, so this might not make sense)
>>
>>It's mostly for the presentation purposes, to match the
>>needs of our client. I first implemented it as an
>> opt-in
>>feature, but the consensus was to capitalize the
>> messages
>>all the time.
>>
>>Doesn't seem like it'd be any more expensive (amount of
>> code or
>>performance) to do that up in your client code, then,
>> would it?
>>I guess if most users of this API in time ended up
>> preferring
>>capitalized values, it'd make sense to share that
>>implementation - but to me it seems like a strange
>>transformation to happen at this level. (since it depends
>> on
>>what kind of client/how they want to render things - so it
>>seems an odd choice to bake in to the API (or even provide
>> an
>>option for, unless there are lots of users/the code was
>>especially complicated))
>>
>>My 2c - I've no vested interest or authority here.
>>
>>I think it's more in spirit with Clangd to provide output
>> that's as
>>close to the one presented by the client as possible.
>>
>>That assumes there's one client though, right? Different clients
>> might
>>reasonably have different needs for how they'd want the text
>> rendered,
>>I'd imagine.
>>
>>True. This transformation is lossless though, so the clients will
>> still be
>>able to get back the original text if needed.
>>
>> I'm not sure that c == lower(upper(c)) - well, if the character is ever
>> uppercase to begin with, it's clearly not. But even in the case of a
>> lowercase
>> character to start with I didn't think that was always true - I guess for
>> ASCII
>> /English it is, and that's all we're dealing with here.
>>
>
> Not bijection :) classical German example 'ß'.upper().lower() => 'ss'
> Though for the context (diagnostic messages where i18n is not
> concerned), this works well enough.
>
>
>>
>>And if the consensus about this particular text transformation changes
>> I'm
>>willing to revert this change for sure.
>>
>> *nod* I mean if everyone who's invested in/working on clangd agrees with
>> your
>> direction, that's cool/good. My 2c is that this sort of thing seems like
>> the
>> responsibility of the client, not the API - but that's by no means
>> authoritative.
>>
>
> Alex, would you mind sharing the discussion thread of the editor you use?


I'm not working with any particular editor right now, just working on
supporting Clangd for an internal client that used libclang before.


>
>
>
>>I would argue there's already a precedence for this kind of
>>transformations, for example, Clangd merges the diagnostic
>> messages
>>of notes and the main diagnostics into one, to make it a better
>>presentation experience in the client:
>>
>>https://github.com/llvm-mirror/clang-tools-extra/blob/
>>55bfabcc1bd75447d6338ffe6ff27c1624a8c15a/clangd/Diagnostics.
>> cpp#
>>L161
>>
>>I'm assuming that's because the API/protocol only supports a single
>>message, so the multi-message/location nuance of LLVM's
>> diagnostics are
>>necessarily lost when converting to that format?
>>
>>If that's not the case, and the API/protocol does support a
>>multiple-message diagnostic & ClangD is collapsing them early -
>> that
>>also seems like an unfortunate loss in fidelity.
>>
>>Clangd sends out both the main diagnostic, and the attached notes (that
>>don't have fixits) in a list (i.e. the hierarchy isn't directly
>> preserved,
>>although it can be recreated by the client).
>>So it looks like they're collapsed early, 

Re: [PATCH] D50154: [clangd] capitalize diagnostic messages

[Alex L via cfe-commits]

On Tue, 7 Aug 2018 at 11:38, David Blaikie  wrote:

>
>
> On Tue, Aug 7, 2018 at 11:22 AM Alex L  wrote:
>
>> On Tue, 7 Aug 2018 at 10:52, David Blaikie via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>>
>>>
>>> On Tue, Aug 7, 2018 at 10:33 AM Alex Lorenz via Phabricator <
>>> revi...@reviews.llvm.org> wrote:
>>>
 arphaman added a comment.

 In https://reviews.llvm.org/D50154#1191002, @dblaikie wrote:

 > What's the motivation for clangd to differ from clang here? (& if the
 first
 >  letter is going to be capitalized, should there be a period at the
 end? But
 >  also the phrasing of most/all diagnostic text isn't in the form of
 complete
 >  sentences, so this might not make sense)


 It's mostly for the presentation purposes, to match the needs of our
 client. I first implemented it as an opt-in feature, but the consensus was
 to capitalize the messages all the time.

>>>
>>> Doesn't seem like it'd be any more expensive (amount of code or
>>> performance) to do that up in your client code, then, would it? I guess if
>>> most users of this API in time ended up preferring capitalized values, it'd
>>> make sense to share that implementation - but to me it seems like a strange
>>> transformation to happen at this level. (since it depends on what kind of
>>> client/how they want to render things - so it seems an odd choice to bake
>>> in to the API (or even provide an option for, unless there are lots of
>>> users/the code was especially complicated))
>>>
>>> My 2c - I've no vested interest or authority here.
>>>
>>
>> I think it's more in spirit with Clangd to provide output that's as close
>> to the one presented by the client as possible.
>>
>
> That assumes there's one client though, right? Different clients might
> reasonably have different needs for how they'd want the text rendered, I'd
> imagine.
>

True. This transformation is lossless though, so the clients will still be
able to get back the original text if needed. And if the consensus about
this particular text transformation changes I'm willing to revert this
change for sure.


>
>
>> I would argue there's already a precedence for this kind of
>> transformations, for example, Clangd merges the diagnostic messages of
>> notes and the main diagnostics into one, to make it a better presentation
>> experience in the client:
>>
>>
>> https://github.com/llvm-mirror/clang-tools-extra/blob/55bfabcc1bd75447d6338ffe6ff27c1624a8c15a/clangd/Diagnostics.cpp#L161
>>
>
> I'm assuming that's because the API/protocol only supports a single
> message, so the multi-message/location nuance of LLVM's diagnostics are
> necessarily lost when converting to that format?
>
> If that's not the case, and the API/protocol does support a
> multiple-message diagnostic & ClangD is collapsing them early - that also
> seems like an unfortunate loss in fidelity.
>

Clangd sends out both the main diagnostic, and the attached notes (that
don't have fixits) in a list (i.e. the hierarchy isn't directly preserved,
although it can be recreated by the client).
So it looks like they're collapsed early, but at the same time the client
has enough information to do this transformation itself if desired.
I'm planning to work on an option to remove this behavior if desired by the
client.


>
>
>>
>>
>>
>>
>>
>>>
>>>
 I don't think it would make sense to insert the period at the end,
 because, as you said, not all diagnostics are complete sentences


 Repository:
   rCTE Clang Tools Extra

 https://reviews.llvm.org/D50154



 ___
>>> 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] D50154: [clangd] capitalize diagnostic messages

[Alex L via cfe-commits]

On Tue, 7 Aug 2018 at 10:52, David Blaikie via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

>
>
> On Tue, Aug 7, 2018 at 10:33 AM Alex Lorenz via Phabricator <
> revi...@reviews.llvm.org> wrote:
>
>> arphaman added a comment.
>>
>> In https://reviews.llvm.org/D50154#1191002, @dblaikie wrote:
>>
>> > What's the motivation for clangd to differ from clang here? (& if the
>> first
>> >  letter is going to be capitalized, should there be a period at the
>> end? But
>> >  also the phrasing of most/all diagnostic text isn't in the form of
>> complete
>> >  sentences, so this might not make sense)
>>
>>
>> It's mostly for the presentation purposes, to match the needs of our
>> client. I first implemented it as an opt-in feature, but the consensus was
>> to capitalize the messages all the time.
>>
>
> Doesn't seem like it'd be any more expensive (amount of code or
> performance) to do that up in your client code, then, would it? I guess if
> most users of this API in time ended up preferring capitalized values, it'd
> make sense to share that implementation - but to me it seems like a strange
> transformation to happen at this level. (since it depends on what kind of
> client/how they want to render things - so it seems an odd choice to bake
> in to the API (or even provide an option for, unless there are lots of
> users/the code was especially complicated))
>
> My 2c - I've no vested interest or authority here.
>

I think it's more in spirit with Clangd to provide output that's as close
to the one presented by the client as possible.
I would argue there's already a precedence for this kind of
transformations, for example, Clangd merges the diagnostic messages of
notes and the main diagnostics into one, to make it a better presentation
experience in the client:

https://github.com/llvm-mirror/clang-tools-extra/blob/55bfabcc1bd75447d6338ffe6ff27c1624a8c15a/clangd/Diagnostics.cpp#L161




>
>
>> I don't think it would make sense to insert the period at the end,
>> because, as you said, not all diagnostics are complete sentences
>>
>>
>> Repository:
>>   rCTE Clang Tools Extra
>>
>> https://reviews.llvm.org/D50154
>>
>>
>>
>> ___
> 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: [clang-tools-extra] r338518 - [clangd] Receive compilationDatabasePath in 'initialize' request

[Alex L via cfe-commits]

On 1 August 2018 at 11:21, Simon Marchi  wrote:

> On 2018-08-01 01:30 PM, Alex L wrote:
> > Is there a particular reason why this commit didn't have a corresponding
> test included?
> > Cheers,
> > Alex
>
> Back when we made the corresponding change in "onChangeConfiguration",
> there was no
> straightforward way to make a lit test for it:
>
> https://reviews.llvm.org/D39571?id=124024#inline-359345
>
> I am not sure, but I think the issue was that we had to hard-code the
> length of the
> messages we sent.  Since we had to use temp directory names, the length
> was not
> known in advance.  I don't think we have that limitation anymore.
>

Yes, I believe this limitation doesn't exist anymore.


>
> We would need to create a temporary directory hierarchy, and then refer to
> it in
> the messages we send to switch between build configurations.  Is it
> something that
> sounds possible with lit?  Do you know about other tests doing something
> similar?
>

I think it's be possible, albeit in a more complicated way than the regular
Clangd test. We just need to generate a new test file that we can give to
the Clangd from the included test file.

I think this kind of solution should work (*) :

First, you would create a temporary directory in lit:

RUN: rm -rf %t.dir
RUN: mkdir %t.dir
RUN: ... populate the temporary directory ...

Then, you would generate the input file (i.e. replace INPUT_DIR in the
original test with the temporary directory):

RUN: rm -rf %t.test
RUN: sed -e "s:INPUT_DIR:%t.dir:g" %s > %t.test

And then you can invoke the test:

RUN: clang -lit-test < %t.test | FileCheck -strict-whitespace %s

* The only problem might be JSON string encoding of the INPUT_DIR (i.e.
you'll generate a test file that contains "C:\\temp\foo" on Windows, which
would be invalid JSON string). You should be able to use 'sed' here as well
to fix this up.

Thanks,
Alex



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

Re: [clang-tools-extra] r338518 - [clangd] Receive compilationDatabasePath in 'initialize' request

[Alex L via cfe-commits]

Is there a particular reason why this commit didn't have a corresponding
test included?
Cheers,
Alex

On 1 August 2018 at 04:28, Simon Marchi via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: simark
> Date: Wed Aug  1 04:28:49 2018
> New Revision: 338518
>
> URL: http://llvm.org/viewvc/llvm-project?rev=338518=rev
> Log:
> [clangd] Receive compilationDatabasePath in 'initialize' request
>
> Summary:
> That way, as soon as the "initialize" is received by the server, it can
> start
> parsing/indexing with a valid compilation database and not have to wait
> for a
> an initial 'didChangeConfiguration' that might or might not happen.
> Then, when the user changes configuration, a didChangeConfiguration can be
> sent.
>
> Signed-off-by: Marc-Andre Laperle 
>
> Reviewers: malaperle
>
> Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, arphaman, cfe-commits
>
> Differential Revision: https://reviews.llvm.org/D49833
>
> Modified:
> clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp
> clang-tools-extra/trunk/clangd/ClangdLSPServer.h
> clang-tools-extra/trunk/clangd/Protocol.cpp
> clang-tools-extra/trunk/clangd/Protocol.h
>
> Modified: clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp
> URL: http://llvm.org/viewvc/llvm-project/clang-tools-extra/
> trunk/clangd/ClangdLSPServer.cpp?rev=338518=338517=338518=diff
> 
> ==
> --- clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp (original)
> +++ clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp Wed Aug  1
> 04:28:49 2018
> @@ -72,6 +72,9 @@ SymbolKindBitset defaultSymbolKinds() {
>  } // namespace
>
>  void ClangdLSPServer::onInitialize(InitializeParams ) {
> +  if (Params.initializationOptions)
> +applyConfiguration(*Params.initializationOptions);
> +
>if (Params.rootUri && *Params.rootUri)
>  Server.setRootPath(Params.rootUri->file());
>else if (Params.rootPath && !Params.rootPath->empty())
> @@ -398,11 +401,8 @@ void ClangdLSPServer::onHover(TextDocume
> });
>  }
>
> -// FIXME: This function needs to be properly tested.
> -void ClangdLSPServer::onChangeConfiguration(
> -DidChangeConfigurationParams ) {
> -  ClangdConfigurationParamsChange  = Params.settings;
> -
> +void ClangdLSPServer::applyConfiguration(
> +const ClangdConfigurationParamsChange ) {
>// Compilation database change.
>if (Settings.compilationDatabasePath.hasValue()) {
>  NonCachedCDB.setCompileCommandsDir(
> @@ -413,6 +413,12 @@ void ClangdLSPServer::onChangeConfigurat
>}
>  }
>
> +// FIXME: This function needs to be properly tested.
> +void ClangdLSPServer::onChangeConfiguration(
> +DidChangeConfigurationParams ) {
> +  applyConfiguration(Params.settings);
> +}
> +
>  ClangdLSPServer::ClangdLSPServer(JSONOutput ,
>   const clangd::CodeCompleteOptions
> ,
>   llvm::Optional CompileCommandsDir,
>
> Modified: clang-tools-extra/trunk/clangd/ClangdLSPServer.h
> URL: http://llvm.org/viewvc/llvm-project/clang-tools-extra/
> trunk/clangd/ClangdLSPServer.h?rev=338518=338517=338518=diff
> 
> ==
> --- clang-tools-extra/trunk/clangd/ClangdLSPServer.h (original)
> +++ clang-tools-extra/trunk/clangd/ClangdLSPServer.h Wed Aug  1 04:28:49
> 2018
> @@ -82,6 +82,7 @@ private:
>/// may be very expensive.  This method is normally called when the
>/// compilation database is changed.
>void reparseOpenedFiles();
> +  void applyConfiguration(const ClangdConfigurationParamsChange
> );
>
>JSONOutput 
>/// Used to indicate that the 'shutdown' request was received from the
>
> Modified: clang-tools-extra/trunk/clangd/Protocol.cpp
> URL: http://llvm.org/viewvc/llvm-project/clang-tools-extra/
> trunk/clangd/Protocol.cpp?rev=338518=338517=338518=diff
> 
> ==
> --- clang-tools-extra/trunk/clangd/Protocol.cpp (original)
> +++ clang-tools-extra/trunk/clangd/Protocol.cpp Wed Aug  1 04:28:49 2018
> @@ -263,7 +263,7 @@ bool fromJSON(const json::Value ,
>O.map("rootPath", R.rootPath);
>O.map("capabilities", R.capabilities);
>O.map("trace", R.trace);
> -  // initializationOptions, capabilities unused
> +  O.map("initializationOptions", R.initializationOptions);
>return true;
>  }
>
>
> Modified: clang-tools-extra/trunk/clangd/Protocol.h
> URL: http://llvm.org/viewvc/llvm-project/clang-tools-extra/
> trunk/clangd/Protocol.h?rev=338518=338517=338518=diff
> 
> ==
> --- clang-tools-extra/trunk/clangd/Protocol.h (original)
> +++ clang-tools-extra/trunk/clangd/Protocol.h Wed Aug  1 04:28:49 2018
> @@ -322,6 +322,16 @@ struct ClientCapabilities {
>
>  bool fromJSON(const llvm::json::Value &, ClientCapabilities &);
>
> +/// Clangd extension to set 

Re: [libcxx] r337727 - [CMake] Fix the setting of LIBCXX_HEADER_DIR

[Alex L via cfe-commits]

Hi,

I had to revert your commit as it caused a number of failures in our public
and internal CI.
When building compiler-rt on Darwin (stage1), after this commit the build
failed to build X-ray and libfuzzer because the libc++ headers were no
longer found. The compiler-rt libraries were built using freshly built
stage1, so it makes sense why this happened (clang expected to find the
libc++ headers in ../include, but they got moved to
../projects/libcxx/include).
Here are a couple of examples of the failures that we've observed:

http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA/47583/console
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/projects/compiler-rt/lib/xray/xray_utils.h:18:10:
fatal error: 'cstddef' file not found
#include 
 ^
1 error generated.

http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-expensive/12202/consoleFull
/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-expensive/llvm/projects/compiler-rt/lib/fuzzer/FuzzerDefs.h:15:10:
fatal error: 'cassert' file not found
#include 
 ^
1 error generated.

Let me know if you need help looking at or testing out a potential fix for
Darwin.
Thanks,
Alex


On 23 July 2018 at 11:58, Heejin Ahn via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: aheejin
> Date: Mon Jul 23 11:58:12 2018
> New Revision: 337727
>
> URL: http://llvm.org/viewvc/llvm-project?rev=337727=rev
> Log:
> [CMake] Fix the setting of LIBCXX_HEADER_DIR
>
> Reviewers: phosek
>
> Subscribers: mgorny, christof, ldionne, cfe-commits
>
> Differential Revision: https://reviews.llvm.org/D49629
>
> Modified:
> libcxx/trunk/CMakeLists.txt
>
> Modified: libcxx/trunk/CMakeLists.txt
> URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/
> CMakeLists.txt?rev=337727=337726=337727=diff
> 
> ==
> --- libcxx/trunk/CMakeLists.txt (original)
> +++ libcxx/trunk/CMakeLists.txt Mon Jul 23 11:58:12 2018
> @@ -378,7 +378,7 @@ endif ()
>  set(LIBCXX_COMPILER${CMAKE_CXX_COMPILER})
>  set(LIBCXX_SOURCE_DIR  ${CMAKE_CURRENT_SOURCE_DIR})
>  set(LIBCXX_BINARY_DIR  ${CMAKE_CURRENT_BINARY_DIR})
> -set(LIBCXX_HEADER_DIR  ${LLVM_BINARY_DIR})
> +set(LIBCXX_HEADER_DIR  ${LIBCXX_BINARY_DIR})
>  set(LIBCXX_BINARY_INCLUDE_DIR "${LIBCXX_BINARY_DIR}/include/c++build")
>
>  string(REGEX MATCH "[0-9]+\\.[0-9]+(\\.[0-9]+)?" CLANG_VERSION
>
>
> ___
> 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: [libcxx] r337727 - [CMake] Fix the setting of LIBCXX_HEADER_DIR

[Alex L via cfe-commits]

The revert commit is r337782.

On 23 July 2018 at 17:32, Alex L  wrote:

> Hi,
>
> I had to revert your commit as it caused a number of failures in our
> public and internal CI.
> When building compiler-rt on Darwin (stage1), after this commit the build
> failed to build X-ray and libfuzzer because the libc++ headers were no
> longer found. The compiler-rt libraries were built using freshly built
> stage1, so it makes sense why this happened (clang expected to find the
> libc++ headers in ../include, but they got moved to
> ../projects/libcxx/include).
> Here are a couple of examples of the failures that we've observed:
>
> http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA/47583/console
> /Users/buildslave/jenkins/workspace/clang-stage1-
> configure-RA/llvm/projects/compiler-rt/lib/xray/xray_utils.h:18:10: fatal
> error: 'cstddef' file not found
> #include 
>  ^
> 1 error generated.
>
> http://lab.llvm.org:8080/green/job/clang-stage1-cmake-
> RA-expensive/12202/consoleFull
> /Users/buildslave/jenkins/workspace/clang-stage1-cmake-
> RA-expensive/llvm/projects/compiler-rt/lib/fuzzer/FuzzerDefs.h:15:10:
> fatal error: 'cassert' file not found
> #include 
>  ^
> 1 error generated.
>
> Let me know if you need help looking at or testing out a potential fix for
> Darwin.
> Thanks,
> Alex
>
>
> On 23 July 2018 at 11:58, Heejin Ahn via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: aheejin
>> Date: Mon Jul 23 11:58:12 2018
>> New Revision: 337727
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=337727=rev
>> Log:
>> [CMake] Fix the setting of LIBCXX_HEADER_DIR
>>
>> Reviewers: phosek
>>
>> Subscribers: mgorny, christof, ldionne, cfe-commits
>>
>> Differential Revision: https://reviews.llvm.org/D49629
>>
>> Modified:
>> libcxx/trunk/CMakeLists.txt
>>
>> Modified: libcxx/trunk/CMakeLists.txt
>> URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.
>> txt?rev=337727=337726=337727=diff
>> 
>> ==
>> --- libcxx/trunk/CMakeLists.txt (original)
>> +++ libcxx/trunk/CMakeLists.txt Mon Jul 23 11:58:12 2018
>> @@ -378,7 +378,7 @@ endif ()
>>  set(LIBCXX_COMPILER${CMAKE_CXX_COMPILER})
>>  set(LIBCXX_SOURCE_DIR  ${CMAKE_CURRENT_SOURCE_DIR})
>>  set(LIBCXX_BINARY_DIR  ${CMAKE_CURRENT_BINARY_DIR})
>> -set(LIBCXX_HEADER_DIR  ${LLVM_BINARY_DIR})
>> +set(LIBCXX_HEADER_DIR  ${LIBCXX_BINARY_DIR})
>>  set(LIBCXX_BINARY_INCLUDE_DIR "${LIBCXX_BINARY_DIR}/include/c++build")
>>
>>  string(REGEX MATCH "[0-9]+\\.[0-9]+(\\.[0-9]+)?" CLANG_VERSION
>>
>>
>> ___
>> 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: r329110 - [driver][darwin] Do not infer -simulator environment for non-simulator SDKs

[Alex L via cfe-commits]

On 3 April 2018 at 14:30, Chandler Carruth  wrote:

> On Tue, Apr 3, 2018 at 1:52 PM Alex Lorenz via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: arphaman
>> Date: Tue Apr  3 13:50:05 2018
>> New Revision: 329110
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=329110=rev
>> Log:
>> [driver][darwin] Do not infer -simulator environment for non-simulator
>> SDKs
>>
>
> I know you added a REQUIRES line to these tests, but I think there is a
> much better way:
>
>
>> --- cfe/trunk/test/Driver/darwin-sdkroot.c (original)
>> +++ cfe/trunk/test/Driver/darwin-sdkroot.c Tue Apr  3 13:50:05 2018
>> @@ -51,12 +51,21 @@
>>  // CHECK-IPHONE: "-triple" "arm64-apple-ios8.0.0"
>>  // CHECK-IPHONE: ld
>>  // CHECK-IPHONE: "-iphoneos_version_min" "8.0.0"
>> +// RUN: env SDKROOT=%t/SDKs/iPhoneOS8.0.0.sdk %clang %s -### 2>&1 \
>>
>
> Instead of just running %clang, actually pass the `-target` you want to it
> like we do in the below invocation and the other invocations in this file.
>
> We shouldn't lose driver testing on other systems as long as you can
> specify the desired target.
>


Hi Chandler!

Thanks for pointing this out! We actually can't use -target here because
when -target is specified, Darwin's driver won't infer the triple's
environment from the SDKROOT. So this test covers the path in the driver
that won't be taken when -target is specified.

You've made a good point about losing testing though. I can split out this
test into the original file (with -target use) and the new tests which
can't use -target and are Darwin specific to ensure we won't loose the
existing coverage. I will commit a follow-up commit that does this.

Cheers,
Alex




>
>
>> +// RUN:   | FileCheck --check-prefix=CHECK-IPHONE-X86 %s
>> +// CHECK-IPHONE-X86: clang
>> +// CHECK-IPHONE-X86: "-cc1"
>> +// CHECK-IPHONE-X86: -apple-ios8.0.0"
>> +// CHECK-IPHONE-X86: ld
>> +// CHECK-IPHONE-X86: "-iphoneos_version_min" "8.0.0"
>>  //
>>  //
>>  // RUN: rm -rf %t/SDKs/iPhoneSimulator8.0.sdk
>>  // RUN: mkdir -p %t/SDKs/iPhoneSimulator8.0.sdk
>>  // RUN: env SDKROOT=%t/SDKs/iPhoneSimulator8.0.sdk %clang -target
>> x86_64-apple-darwin %s -### 2>&1 \
>>  // RUN:   | FileCheck --check-prefix=CHECK-SIMULATOR %s
>> +// RUN: env SDKROOT=%t/SDKs/iPhoneSimulator8.0.sdk %clang -arch x86_64
>> %s -### 2>&1 \
>> +// RUN:   | FileCheck --check-prefix=CHECK-SIMULATOR %s
>>  //
>>  // CHECK-SIMULATOR: clang
>>  // CHECK-SIMULATOR: "-cc1"
>> @@ -74,3 +83,49 @@
>>  // CHECK-MACOSX: "-triple" "x86_64-apple-macosx10.10.0"
>>  // CHECK-MACOSX: ld
>>  // CHECK-MACOSX: "-macosx_version_min" "10.10.0"
>> +
>> +// RUN: rm -rf %t/SDKs/WatchOS3.0.sdk
>> +// RUN: mkdir -p %t/SDKs/WatchOS3.0.sdk
>> +// RUN: env SDKROOT=%t/SDKs/WatchOS3.0.sdk %clang %s -### 2>&1 \
>> +// RUN:   | FileCheck --check-prefix=CHECK-WATCH %s
>> +//
>> +// CHECK-WATCH: clang
>> +// CHECK-WATCH: "-cc1"
>> +// CHECK-WATCH: -apple-watchos3.0.0"
>> +// CHECK-WATCH: ld
>> +// CHECK-WATCH: "-watchos_version_min" "3.0.0"
>> +//
>> +//
>> +// RUN: rm -rf %t/SDKs/WatchSimulator3.0.sdk
>> +// RUN: mkdir -p %t/SDKs/WatchSimulator3.0.sdk
>> +// RUN: env SDKROOT=%t/SDKs/WatchSimulator3.0.sdk %clang %s -### 2>&1 \
>> +// RUN:   | FileCheck --check-prefix=CHECK-WATCH-SIMULATOR %s
>> +//
>> +// CHECK-WATCH-SIMULATOR: clang
>> +// CHECK-WATCH-SIMULATOR: "-cc1"
>> +// CHECK-WATCH-SIMULATOR: -apple-watchos3.0.0-simulator"
>> +// CHECK-WATCH-SIMULATOR: ld
>> +// CHECK-WATCH-SIMULATOR: "-watchos_simulator_version_min" "3.0.0"
>> +
>> +// RUN: rm -rf %t/SDKs/AppleTVOS10.0.sdk
>> +// RUN: mkdir -p %t/SDKs/AppleTVOS10.0.sdk
>> +// RUN: env SDKROOT=%t/SDKs/AppleTVOS10.0.sdk %clang %s -### 2>&1 \
>> +// RUN:   | FileCheck --check-prefix=CHECK-TV %s
>> +//
>> +// CHECK-TV: clang
>> +// CHECK-TV: "-cc1"
>> +// CHECK-TV: -apple-tvos10.0.0"
>> +// CHECK-TV: ld
>> +// CHECK-TV: "-tvos_version_min" "10.0.0"
>> +//
>> +//
>> +// RUN: rm -rf %t/SDKs/AppleTVSimulator10.0.sdk
>> +// RUN: mkdir -p %t/SDKs/AppleTVSimulator10.0.sdk
>> +// RUN: env SDKROOT=%t/SDKs/AppleTVSimulator10.0.sdk %clang %s -###
>> 2>&1 \
>> +// RUN:   | FileCheck --check-prefix=CHECK-TV-SIMULATOR %s
>> +//
>> +// CHECK-TV-SIMULATOR: clang
>> +// CHECK-TV-SIMULATOR: "-cc1"
>> +// CHECK-TV-SIMULATOR: -apple-tvos10.0.0-simulator"
>> +// CHECK-TV-SIMULATOR: ld
>> +// CHECK-TV-SIMULATOR: "-tvos_simulator_version_min" "10.0.0"
>>
>>
>> ___
>> 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: r313729 - Implement C++ [basic.link]p8.

[Alex L via cfe-commits]

Hi Richard,

This commit has caused a second regression in Clang which triggers a new
invalid -Wunused-function warning. I filed
https://bugs.llvm.org/show_bug.cgi?id=36584 which contains the minimized
test case for this issue. Do you mind taking a look at it?

Thanks,
Alex

On 19 December 2017 at 11:14, Alex L  wrote:

> Hi Richard,
>
> This commit has caused a new regression in Clang which causes an assertion
> failure for extern "C" function definitions whose return type is a pointer
> to a record. I filed https://bugs.llvm.org/show_bug.cgi?id=35697 which
> contains the minimized test case for this issue. Do you mind taking a look
> at it?
>
> Cheers,
> Alex
>
> On 20 September 2017 at 00:22, Richard Smith via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: rsmith
>> Date: Wed Sep 20 00:22:00 2017
>> New Revision: 313729
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=313729=rev
>> Log:
>> Implement C++ [basic.link]p8.
>>
>> If a function or variable has a type with no linkage (and is not extern
>> "C"),
>> any use of it requires a definition within the same translation unit; the
>> idea
>> is that it is not possible to define the entity elsewhere, so any such
>> use is
>> necessarily an error.
>>
>> There is an exception, though: some types formally have no linkage but
>> nonetheless can be referenced from other translation units (for example,
>> this
>> happens to anonymous structures defined within inline functions). For
>> entities
>> with those types, we suppress the diagnostic except under -pedantic.
>>
>> Added:
>> cfe/trunk/test/CXX/basic/basic.link/p8.cpp
>> Modified:
>> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
>> cfe/trunk/include/clang/Sema/Sema.h
>> cfe/trunk/include/clang/Sema/SemaInternal.h
>> cfe/trunk/lib/AST/Decl.cpp
>> cfe/trunk/lib/Sema/Sema.cpp
>> cfe/trunk/lib/Sema/SemaDecl.cpp
>> cfe/trunk/lib/Sema/SemaExpr.cpp
>> cfe/trunk/test/Analysis/malloc.mm
>> cfe/trunk/test/Analysis/reference.cpp
>> cfe/trunk/test/CodeGenCXX/debug-info-method.cpp
>> cfe/trunk/test/CodeGenCXX/mangle-ms-cxx11.cpp
>> cfe/trunk/test/CodeGenCXX/mangle.cpp
>> cfe/trunk/test/PCH/cxx11-lambdas.mm
>> cfe/trunk/test/SemaCXX/warn-unreachable.cpp
>>
>> Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/
>> Basic/DiagnosticSemaKinds.td?rev=313729=313728=313729=diff
>> 
>> ==
>> --- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
>> +++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Wed Sep 20
>> 00:22:00 2017
>> @@ -4707,6 +4707,14 @@ def note_deleted_assign_field : Note<
>>  def warn_undefined_internal : Warning<
>>"%select{function|variable}0 %q1 has internal linkage but is not
>> defined">,
>>InGroup>;
>> +def err_undefined_internal_type : Error<
>> +  "%select{function|variable}0 %q1 is used but not defined in this "
>> +  "translation unit, and cannot be defined in any other translation unit
>> "
>> +  "because its type does not have linkage">;
>> +def ext_undefined_internal_type : Extension<
>> +  "ISO C++ requires a definition in this translation unit for "
>> +  "%select{function|variable}0 %q1 because its type does not have
>> linkage">,
>> +  InGroup>;
>>  def warn_undefined_inline : Warning<"inline function %q0 is not
>> defined">,
>>InGroup>;
>>  def err_undefined_inline_var : Error<"inline variable %q0 is not
>> defined">;
>>
>> Modified: cfe/trunk/include/clang/Sema/Sema.h
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/
>> Sema/Sema.h?rev=313729=313728=313729=diff
>> 
>> ==
>> --- cfe/trunk/include/clang/Sema/Sema.h (original)
>> +++ cfe/trunk/include/clang/Sema/Sema.h Wed Sep 20 00:22:00 2017
>> @@ -1086,6 +1086,11 @@ public:
>>/// definition in this translation unit.
>>llvm::MapVector UndefinedButUsed;
>>
>> +  /// Determine if VD, which must be a variable or function, is an
>> external
>> +  /// symbol that nonetheless can't be referenced from outside this
>> translation
>> +  /// unit because its type has no linkage and it's not extern "C".
>> +  bool isExternalWithNoLinkageType(ValueDecl *VD);
>> +
>>/// Obtain a sorted list of functions that are undefined but ODR-used.
>>void getUndefinedButUsed(
>>SmallVectorImpl
>> );
>>
>> Modified: cfe/trunk/include/clang/Sema/SemaInternal.h
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/
>> Sema/SemaInternal.h?rev=313729=313728=313729=diff
>> 
>> ==
>> --- cfe/trunk/include/clang/Sema/SemaInternal.h (original)
>> +++ 

Re: r316268 - [Sema] Fixes for enum handling for tautological comparison diagnostics

[Alex L via cfe-commits]

Hi Roman,

This commit has caused a regression in LLVM 6 which now triggers
-Wsign-compare for typeof(enum) and typeof(enumConstant). I filed
https://bugs.llvm.org/show_bug.cgi?id=36008. Could you please take a look
at it?

Thanks,
Alex

On 21 October 2017 at 09:44, Roman Lebedev via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: lebedevri
> Date: Sat Oct 21 09:44:03 2017
> New Revision: 316268
>
> URL: http://llvm.org/viewvc/llvm-project?rev=316268=rev
> Log:
> [Sema] Fixes for enum handling for tautological comparison diagnostics
>
> Summary:
> As Mattias Eriksson has reported in PR35009, in C, for enums, the
> underlying type should
> be used when checking for the tautological comparison, unlike C++, where
> the enumerator
> values define the value range. So if not in CPlusPlus mode, use the enum
> underlying type.
>
> Also, i have discovered a problem (a crash) when evaluating
> tautological-ness of the following comparison:
> ```
> enum A { A_a = 0 };
> if (a < 0) // expected-warning {{comparison of unsigned enum expression <
> 0 is always false}}
> return 0;
> ```
> This affects both the C and C++, but after the first fix, only C++ code
> was affected.
> That was also fixed, while preserving (i think?) the proper diagnostic
> output.
>
> And while there, attempt to enhance the test coverage.
> Yes, some tests got moved around, sorry about that :)
>
> Fixes PR35009
>
> Reviewers: aaron.ballman, rsmith, rjmccall
>
> Reviewed By: aaron.ballman
>
> Subscribers: Rakete, efriedma, materi, cfe-commits
>
> Tags: #clang
>
> Differential Revision: https://reviews.llvm.org/D39122
>
> Added:
> cfe/trunk/test/Sema/outof-range-enum-constant-compare.c
> cfe/trunk/test/Sema/tautological-constant-enum-compare.c
> Modified:
> cfe/trunk/lib/Sema/SemaChecking.cpp
> cfe/trunk/test/Sema/tautological-unsigned-enum-zero-compare.c
> cfe/trunk/test/Sema/tautological-unsigned-enum-zero-compare.cpp
>
> Modified: cfe/trunk/lib/Sema/SemaChecking.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/
> SemaChecking.cpp?rev=316268=316267=316268=diff
> 
> ==
> --- cfe/trunk/lib/Sema/SemaChecking.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaChecking.cpp Sat Oct 21 09:44:03 2017
> @@ -8181,8 +8181,12 @@ struct IntRange {
>  if (const AtomicType *AT = dyn_cast(T))
>T = AT->getValueType().getTypePtr();
>
> -// For enum types, use the known bit width of the enumerators.
> -if (const EnumType *ET = dyn_cast(T)) {
> +if (!C.getLangOpts().CPlusPlus) {
> +  // For enum types in C code, use the underlying datatype.
> +  if (const EnumType *ET = dyn_cast(T))
> +T = ET->getDecl()->getIntegerType().getDesugaredType(C).
> getTypePtr();
> +} else if (const EnumType *ET = dyn_cast(T)) {
> +  // For enum types in C++, use the known bit width of the
> enumerators.
>EnumDecl *Enum = ET->getDecl();
>// In C++11, enums without definitions can have an explicitly
> specified
>// underlying type.  Use this type to compute the range.
> @@ -8584,8 +8588,10 @@ bool isNonBooleanUnsignedValue(Expr *E)
>  }
>
>  enum class LimitType {
> -  Max, // e.g. 32767 for short
> -  Min  // e.g. -32768 for short
> +  Max = 1U << 0U,  // e.g. 32767 for short
> +  Min = 1U << 1U,  // e.g. -32768 for short
> +  Both = Max | Min // When the value is both the Min and the Max limit at
> the
> +   // same time; e.g. in C++, A::a in enum A { a = 0 };
>  };
>
>  /// Checks whether Expr 'Constant' may be the
> @@ -8608,6 +8614,10 @@ llvm::Optional IsTypeLimit(Se
>
>IntRange OtherRange = IntRange::forValueOfType(S.Context, OtherT);
>
> +  // Special-case for C++ for enum with one enumerator with value of 0.
> +  if (OtherRange.Width == 0)
> +return Value == 0 ? LimitType::Both : llvm::Optional();
> +
>if (llvm::APSInt::isSameValue(
>llvm::APSInt::getMaxValue(OtherRange.Width,
>  OtherT->isUnsignedIntegerType()),
> @@ -8620,7 +8630,7 @@ llvm::Optional IsTypeLimit(Se
>Value))
>  return LimitType::Min;
>
> -  return llvm::Optional();
> +  return llvm::None;
>  }
>
>  bool HasEnumType(Expr *E) {
> @@ -8655,9 +8665,12 @@ bool CheckTautologicalComparison(Sema 
>
>bool ConstIsLowerBound = (Op == BO_LT || Op == BO_LE) ^ RhsConstant;
>bool ResultWhenConstEqualsOther = (Op == BO_LE || Op == BO_GE);
> -  bool ResultWhenConstNeOther =
> -  ConstIsLowerBound ^ (ValueType == LimitType::Max);
> -  if (ResultWhenConstEqualsOther != ResultWhenConstNeOther)
> +  if (ValueType != LimitType::Both) {
> +bool ResultWhenConstNeOther =
> +ConstIsLowerBound ^ (ValueType == LimitType::Max);
> +if (ResultWhenConstEqualsOther != ResultWhenConstNeOther)
> +  return false; // The comparison is not tautological.
> +  } else if (ResultWhenConstEqualsOther == ConstIsLowerBound)
>  return false; 

Re: r321099 - [driver][darwin] Take the OS version specified in "-target" as the target

[Alex L via cfe-commits]

I committed the patch that allows -m-version-min to specify the OS
version when -target doesn't specify in r321559. Let me know if it works
for you!

Thanks,
Alex

On 21 December 2017 at 12:34, James Y Knight  wrote:

> I totally agree with moving towards eliminating the -m-version-min
> flags, it's much better to put it in the target, and will clean up a lot of
> cruft in the driver, eventually.
>
> Now -- we (or anyone else who runs into this) can simply start specifying
> the version in both locations ("-target x86_64-apple-ios10
> -mios-simulator-version-min=10"), so as to work with both new and old
> clang, and be closer to the ultimate goal of having only -target. That's an
> overall nicer workaround to suggest than switching to -darwin. But, yea,
> there's no need for *temporary* patch to fix things just for us.
>
> However, I do not understand why you're against committing the patch you
> mention as option #2 -- that seems like it'd be best for all users, by
> preserving compatibility with existing command-lines. So, I'd still like
> that change to be committed, permanently, not temporarily. I'm sure we
> can't be the only ones running clang like "-target x86_64-apple-ios
> -mios-simulator-version-min=10", and it seems unfortunate and unnecessary
> to break that, even if it can be worked around.
>
> In the future, I'd hope the -m-version-min arguments can be deprecated
> more and more -- warning whenever you use them to modify the platform or
> version at all, rather just on specification conflict; then, warn anytime
> you use them at all; then, remove them. But in the meantime, it seems
> strictly better to preserve compatibility, don't you think?
>
>
>
> On Dec 21, 2017 2:11 PM, "Alex L"  wrote:
>
> Thanks for raising your concerns.
>
> We decided to avoid -m-version-min flag in favor of -target to
> simplify the driver logic and to encourage the adoption of -target. Now
> after r321145 we only warn about -m-version-min flag when the OS
> version specified in it is different to the OS version specified in target,
> or when target has no OS version.
>
> There are two possible solutions here:
> 1) You can still use -target with -mios-simulator-version-min as before
> but you'd have to use '-target=x86_64-apple-darwin' to ensure that the iOS
> version specified by  '-mios-simulator-version-min' is used.
> 2) I also do have a patch that implements the logic that you propose (use
> the OS version in -m-version-min flag if target has none). If you
> believe that the first solution is not suitable for your code then I can
> commit it. At the same time I believe that we would rather not use this
> patch, but if it's urgent for your projects then maybe I can land it now
> and then we can establish some sort of timeline for when it can be reverted?
>
> Thanks,
> Alex
>
>
> On 21 December 2017 at 08:00, James Y Knight  wrote:
>
>> I think if a version number isn't explicitly specified in the -target
>> value, the value from -m-version-min ought to still be used, as
>> it was before.
>>
>> Currently, clang will ignore the -m-version-min version number
>> if the target has a particular OS specified, even if it has no version
>> number as part of it.
>>
>> (We should be able to workaround this change backwards-compatibly by
>> specifying in both the -target argument and in the -m-version-min
>> arguments, but I do think the behavior should be fixed.)
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r315984 - [CodeGen] EmitPointerWithAlignment() to generate TBAA info along with LValue base info

[Alex L via cfe-commits]

Hi,

This commit has caused a new regression in LLVM 6. I filed the following
PR: https://bugs.llvm.org/show_bug.cgi?id=35724 .
Could you please take a look?

Thanks,
Alex

On 17 October 2017 at 02:12, Ivan A. Kosarev via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: kosarev
> Date: Tue Oct 17 02:12:13 2017
> New Revision: 315984
>
> URL: http://llvm.org/viewvc/llvm-project?rev=315984=rev
> Log:
> [CodeGen] EmitPointerWithAlignment() to generate TBAA info along with
> LValue base info
>
> Differential Revision: https://reviews.llvm.org/D38796
>
> Added:
> cfe/trunk/test/CodeGen/tbaa-cast.cpp
> Modified:
> cfe/trunk/lib/CodeGen/CGExpr.cpp
> cfe/trunk/lib/CodeGen/CodeGenFunction.cpp
> cfe/trunk/lib/CodeGen/CodeGenFunction.h
> cfe/trunk/lib/CodeGen/CodeGenModule.cpp
> cfe/trunk/lib/CodeGen/CodeGenModule.h
> cfe/trunk/lib/CodeGen/CodeGenTBAA.cpp
> cfe/trunk/lib/CodeGen/CodeGenTBAA.h
>
> Modified: cfe/trunk/lib/CodeGen/CGExpr.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/
> CGExpr.cpp?rev=315984=315983=315984=diff
> 
> ==
> --- cfe/trunk/lib/CodeGen/CGExpr.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGExpr.cpp Tue Oct 17 02:12:13 2017
> @@ -916,7 +916,8 @@ void CodeGenModule::EmitExplicitCastExpr
>  /// EmitPointerWithAlignment - Given an expression of pointer type, try to
>  /// derive a more accurate bound on the alignment of the pointer.
>  Address CodeGenFunction::EmitPointerWithAlignment(const Expr *E,
> -  LValueBaseInfo
> *BaseInfo) {
> +  LValueBaseInfo
> *BaseInfo,
> +  TBAAAccessInfo
> *TBAAInfo) {
>// We allow this with ObjC object pointers because of fragile ABIs.
>assert(E->getType()->isPointerType() ||
>   E->getType()->isObjCObjectPointerType());
> @@ -936,20 +937,30 @@ Address CodeGenFunction::EmitPointerWith
>  if (PtrTy->getPointeeType()->isVoidType())
>break;
>
> -LValueBaseInfo InnerInfo;
> -Address Addr = EmitPointerWithAlignment(CE->getSubExpr(),
> );
> -if (BaseInfo) *BaseInfo = InnerInfo;
> -
> -// If this is an explicit bitcast, and the source l-value is
> -// opaque, honor the alignment of the casted-to type.
> -if (isa(CE) &&
> -InnerInfo.getAlignmentSource() != AlignmentSource::Decl) {
> -  LValueBaseInfo ExpInfo;
> +LValueBaseInfo InnerBaseInfo;
> +TBAAAccessInfo InnerTBAAInfo;
> +Address Addr = EmitPointerWithAlignment(CE->getSubExpr(),
> +,
> +);
> +if (BaseInfo) *BaseInfo = InnerBaseInfo;
> +if (TBAAInfo) *TBAAInfo = InnerTBAAInfo;
> +
> +if (isa(CE)) {
> +  LValueBaseInfo TargetTypeBaseInfo;
> +  TBAAAccessInfo TargetTypeTBAAInfo;
>CharUnits Align = getNaturalPointeeTypeAlignment(E->getType(),
> -   );
> -  if (BaseInfo)
> -BaseInfo->mergeForCast(ExpInfo);
> -  Addr = Address(Addr.getPointer(), Align);
> +
>  ,
> +
>  );
> +  if (TBAAInfo)
> +*TBAAInfo = CGM.mergeTBAAInfoForCast(*TBAAInfo,
> + TargetTypeTBAAInfo);
> +  // If the source l-value is opaque, honor the alignment of the
> +  // casted-to type.
> +  if (InnerBaseInfo.getAlignmentSource() !=
> AlignmentSource::Decl) {
> +if (BaseInfo)
> +  BaseInfo->mergeForCast(TargetTypeBaseInfo);
> +Addr = Address(Addr.getPointer(), Align);
> +  }
>  }
>
>  if (SanOpts.has(SanitizerKind::CFIUnrelatedCast) &&
> @@ -969,12 +980,13 @@ Address CodeGenFunction::EmitPointerWith
>
>  // Array-to-pointer decay.
>  case CK_ArrayToPointerDecay:
> -  return EmitArrayToPointerDecay(CE->getSubExpr(), BaseInfo);
> +  return EmitArrayToPointerDecay(CE->getSubExpr(), BaseInfo,
> TBAAInfo);
>
>  // Derived-to-base conversions.
>  case CK_UncheckedDerivedToBase:
>  case CK_DerivedToBase: {
> -  Address Addr = EmitPointerWithAlignment(CE->getSubExpr(),
> BaseInfo);
> +  Address Addr = EmitPointerWithAlignment(CE->getSubExpr(), BaseInfo,
> +  TBAAInfo);
>auto Derived = CE->getSubExpr()->getType()->
> getPointeeCXXRecordDecl();
>return GetAddressOfBaseClass(Addr, Derived,
> CE->path_begin(), CE->path_end(),
> @@ -994,6 +1006,7 @@ Address CodeGenFunction::EmitPointerWith
>  if (UO->getOpcode() == UO_AddrOf) {
>LValue LV = EmitLValue(UO->getSubExpr());
>if (BaseInfo) *BaseInfo = LV.getBaseInfo();
> +  if (TBAAInfo) 

Re: r321099 - [driver][darwin] Take the OS version specified in "-target" as the target

[Alex L via cfe-commits]

On 21 December 2017 at 12:34, James Y Knight  wrote:

> I totally agree with moving towards eliminating the -m-version-min
> flags, it's much better to put it in the target, and will clean up a lot of
> cruft in the driver, eventually.
>
> Now -- we (or anyone else who runs into this) can simply start specifying
> the version in both locations ("-target x86_64-apple-ios10
> -mios-simulator-version-min=10"), so as to work with both new and old
> clang, and be closer to the ultimate goal of having only -target. That's an
> overall nicer workaround to suggest than switching to -darwin. But, yea,
> there's no need for *temporary* patch to fix things just for us.
>
> However, I do not understand why you're against committing the patch you
> mention as option #2 -- that seems like it'd be best for all users, by
> preserving compatibility with existing command-lines. So, I'd still like
> that change to be committed, permanently, not temporarily. I'm sure we
> can't be the only ones running clang like "-target x86_64-apple-ios
> -mios-simulator-version-min=10", and it seems unfortunate and unnecessary
> to break that, even if it can be worked around.
>
> In the future, I'd hope the -m-version-min arguments can be deprecated
> more and more -- warning whenever you use them to modify the platform or
> version at all, rather just on specification conflict; then, warn anytime
> you use them at all; then, remove them. But in the meantime, it seems
> strictly better to preserve compatibility, don't you think?
>

+ Duncan

Thanks, I think your argument is convincing. I think I will commit the
change that you're proposing in the near future if there are no further
objections.



>
>
>
> On Dec 21, 2017 2:11 PM, "Alex L"  wrote:
>
> Thanks for raising your concerns.
>
> We decided to avoid -m-version-min flag in favor of -target to
> simplify the driver logic and to encourage the adoption of -target. Now
> after r321145 we only warn about -m-version-min flag when the OS
> version specified in it is different to the OS version specified in target,
> or when target has no OS version.
>
> There are two possible solutions here:
> 1) You can still use -target with -mios-simulator-version-min as before
> but you'd have to use '-target=x86_64-apple-darwin' to ensure that the iOS
> version specified by  '-mios-simulator-version-min' is used.
> 2) I also do have a patch that implements the logic that you propose (use
> the OS version in -m-version-min flag if target has none). If you
> believe that the first solution is not suitable for your code then I can
> commit it. At the same time I believe that we would rather not use this
> patch, but if it's urgent for your projects then maybe I can land it now
> and then we can establish some sort of timeline for when it can be reverted?
>
> Thanks,
> Alex
>
>
> On 21 December 2017 at 08:00, James Y Knight  wrote:
>
>> I think if a version number isn't explicitly specified in the -target
>> value, the value from -m-version-min ought to still be used, as
>> it was before.
>>
>> Currently, clang will ignore the -m-version-min version number
>> if the target has a particular OS specified, even if it has no version
>> number as part of it.
>>
>> (We should be able to workaround this change backwards-compatibly by
>> specifying in both the -target argument and in the -m-version-min
>> arguments, but I do think the behavior should be fixed.)
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r321099 - [driver][darwin] Take the OS version specified in "-target" as the target

[Alex L via cfe-commits]

Thanks for raising your concerns.

We decided to avoid -m-version-min flag in favor of -target to simplify
the driver logic and to encourage the adoption of -target. Now after r321145
we only warn about -m-version-min flag when the OS version specified in
it is different to the OS version specified in target, or when target has
no OS version.

There are two possible solutions here:
1) You can still use -target with -mios-simulator-version-min as before but
you'd have to use '-target=x86_64-apple-darwin' to ensure that the iOS
version specified by  '-mios-simulator-version-min' is used.
2) I also do have a patch that implements the logic that you propose (use
the OS version in -m-version-min flag if target has none). If you
believe that the first solution is not suitable for your code then I can
commit it. At the same time I believe that we would rather not use this
patch, but if it's urgent for your projects then maybe I can land it now
and then we can establish some sort of timeline for when it can be reverted?

Thanks,
Alex


On 21 December 2017 at 08:00, James Y Knight  wrote:

> I think if a version number isn't explicitly specified in the -target
> value, the value from -m-version-min ought to still be used, as
> it was before.
>
> Currently, clang will ignore the -m-version-min version number
> if the target has a particular OS specified, even if it has no version
> number as part of it.
>
> (We should be able to workaround this change backwards-compatibly by
> specifying in both the -target argument and in the -m-version-min
> arguments, but I do think the behavior should be fixed.)
>
> On Thu, Dec 21, 2017 at 10:45 AM, Martin Böhme  wrote:
>
>> This is causing problems in some internal builds that specify both
>> -mios-simulator-version-min=9.0 and --target=x86_64-apple-ios
>>
>> My expectation would be for the code to take the minimum OS version
>> number from the -mios-simulator-version-min flag. In fact, however, the
>> code seems to be completely ignoring this flag.
>>
>> Is my expectation wrong or does the code need to be modified to take this
>> situation into account?
>>
>>
>> On 19 December 2017 at 20:05, Alex Lorenz via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: arphaman
>>> Date: Tue Dec 19 11:05:04 2017
>>> New Revision: 321099
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=321099=rev
>>> Log:
>>> [driver][darwin] Take the OS version specified in "-target" as the target
>>> OS instead of inferring it from SDK / environment
>>>
>>> The OS version is specified in -target should be used instead of the one
>>> in an
>>> environment variable / SDK name.
>>>
>>> rdar://35813850
>>>
>>> Differential Revision: https://reviews.llvm.org/D40998
>>>
>>> Modified:
>>> cfe/trunk/lib/Driver/ToolChains/Darwin.cpp
>>> cfe/trunk/test/Driver/darwin-version.c
>>> cfe/trunk/test/Driver/objc-weak.m
>>> cfe/trunk/test/Driver/pic.c
>>> cfe/trunk/test/Driver/unavailable_aligned_allocation.cpp
>>>
>>> Modified: cfe/trunk/lib/Driver/ToolChains/Darwin.cpp
>>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Too
>>> lChains/Darwin.cpp?rev=321099=321098=321099=diff
>>> 
>>> ==
>>> --- cfe/trunk/lib/Driver/ToolChains/Darwin.cpp (original)
>>> +++ cfe/trunk/lib/Driver/ToolChains/Darwin.cpp Tue Dec 19 11:05:04 2017
>>> @@ -1233,6 +1233,10 @@ struct DarwinPlatform {
>>>  llvm_unreachable("Unsupported Darwin Source Kind");
>>>}
>>>
>>> +  static DarwinPlatform createFromTarget(llvm::Triple::OSType OS,
>>> + StringRef OSVersion, Arg *A) {
>>> +return DarwinPlatform(TargetArg, getPlatformFromOS(OS), OSVersion,
>>> A);
>>> +  }
>>>static DarwinPlatform createOSVersionArg(DarwinPlatformKind Platform,
>>> Arg *A) {
>>>  return DarwinPlatform(OSVersionArg, Platform, A);
>>> @@ -1250,33 +1254,32 @@ struct DarwinPlatform {
>>>}
>>>static DarwinPlatform createFromArch(llvm::Triple::OSType OS,
>>> StringRef Value) {
>>> -DarwinPlatformKind Platform;
>>> +return DarwinPlatform(InferredFromArch, getPlatformFromOS(OS),
>>> Value);
>>> +  }
>>> +
>>> +private:
>>> +  DarwinPlatform(SourceKind Kind, DarwinPlatformKind Platform, Arg
>>> *Argument)
>>> +  : Kind(Kind), Platform(Platform), Argument(Argument) {}
>>> +  DarwinPlatform(SourceKind Kind, DarwinPlatformKind Platform,
>>> StringRef Value,
>>> + Arg *Argument = nullptr)
>>> +  : Kind(Kind), Platform(Platform), OSVersion(Value),
>>> Argument(Argument) {}
>>> +
>>> +  static DarwinPlatformKind getPlatformFromOS(llvm::Triple::OSType OS)
>>> {
>>>  switch (OS) {
>>>  case llvm::Triple::Darwin:
>>>  case llvm::Triple::MacOSX:
>>> -  Platform = DarwinPlatformKind::MacOS;
>>> -  break;
>>> +  return 

Re: r313729 - Implement C++ [basic.link]p8.

[Alex L via cfe-commits]

Hi Richard,

This commit has caused a new regression in Clang which causes an assertion
failure for extern "C" function definitions whose return type is a pointer
to a record. I filed https://bugs.llvm.org/show_bug.cgi?id=35697 which
contains the minimized test case for this issue. Do you mind taking a look
at it?

Cheers,
Alex

On 20 September 2017 at 00:22, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rsmith
> Date: Wed Sep 20 00:22:00 2017
> New Revision: 313729
>
> URL: http://llvm.org/viewvc/llvm-project?rev=313729=rev
> Log:
> Implement C++ [basic.link]p8.
>
> If a function or variable has a type with no linkage (and is not extern
> "C"),
> any use of it requires a definition within the same translation unit; the
> idea
> is that it is not possible to define the entity elsewhere, so any such use
> is
> necessarily an error.
>
> There is an exception, though: some types formally have no linkage but
> nonetheless can be referenced from other translation units (for example,
> this
> happens to anonymous structures defined within inline functions). For
> entities
> with those types, we suppress the diagnostic except under -pedantic.
>
> Added:
> cfe/trunk/test/CXX/basic/basic.link/p8.cpp
> Modified:
> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> cfe/trunk/include/clang/Sema/Sema.h
> cfe/trunk/include/clang/Sema/SemaInternal.h
> cfe/trunk/lib/AST/Decl.cpp
> cfe/trunk/lib/Sema/Sema.cpp
> cfe/trunk/lib/Sema/SemaDecl.cpp
> cfe/trunk/lib/Sema/SemaExpr.cpp
> cfe/trunk/test/Analysis/malloc.mm
> cfe/trunk/test/Analysis/reference.cpp
> cfe/trunk/test/CodeGenCXX/debug-info-method.cpp
> cfe/trunk/test/CodeGenCXX/mangle-ms-cxx11.cpp
> cfe/trunk/test/CodeGenCXX/mangle.cpp
> cfe/trunk/test/PCH/cxx11-lambdas.mm
> cfe/trunk/test/SemaCXX/warn-unreachable.cpp
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/
> DiagnosticSemaKinds.td?rev=313729=313728=313729=diff
> 
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Wed Sep 20
> 00:22:00 2017
> @@ -4707,6 +4707,14 @@ def note_deleted_assign_field : Note<
>  def warn_undefined_internal : Warning<
>"%select{function|variable}0 %q1 has internal linkage but is not
> defined">,
>InGroup>;
> +def err_undefined_internal_type : Error<
> +  "%select{function|variable}0 %q1 is used but not defined in this "
> +  "translation unit, and cannot be defined in any other translation unit "
> +  "because its type does not have linkage">;
> +def ext_undefined_internal_type : Extension<
> +  "ISO C++ requires a definition in this translation unit for "
> +  "%select{function|variable}0 %q1 because its type does not have
> linkage">,
> +  InGroup>;
>  def warn_undefined_inline : Warning<"inline function %q0 is not defined">,
>InGroup>;
>  def err_undefined_inline_var : Error<"inline variable %q0 is not
> defined">;
>
> Modified: cfe/trunk/include/clang/Sema/Sema.h
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/Sema/Sema.h?rev=313729=313728=313729=diff
> 
> ==
> --- cfe/trunk/include/clang/Sema/Sema.h (original)
> +++ cfe/trunk/include/clang/Sema/Sema.h Wed Sep 20 00:22:00 2017
> @@ -1086,6 +1086,11 @@ public:
>/// definition in this translation unit.
>llvm::MapVector UndefinedButUsed;
>
> +  /// Determine if VD, which must be a variable or function, is an
> external
> +  /// symbol that nonetheless can't be referenced from outside this
> translation
> +  /// unit because its type has no linkage and it's not extern "C".
> +  bool isExternalWithNoLinkageType(ValueDecl *VD);
> +
>/// Obtain a sorted list of functions that are undefined but ODR-used.
>void getUndefinedButUsed(
>SmallVectorImpl
> );
>
> Modified: cfe/trunk/include/clang/Sema/SemaInternal.h
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/Sema/SemaInternal.h?rev=313729=313728=313729=diff
> 
> ==
> --- cfe/trunk/include/clang/Sema/SemaInternal.h (original)
> +++ cfe/trunk/include/clang/Sema/SemaInternal.h Wed Sep 20 00:22:00 2017
> @@ -73,7 +73,8 @@ inline void MarkVarDeclODRUsed(VarDecl *
>// Keep track of used but undefined variables.
>// FIXME: We shouldn't suppress this warning for static data members.
>if (Var->hasDefinition(SemaRef.Context) == VarDecl::DeclarationOnly &&
> -  (!Var->isExternallyVisible() || Var->isInline()) &&
> +  (!Var->isExternallyVisible() || Var->isInline() ||
> +   

Re: r320734 - [Preprocessor] Implement __is_target_{arch|vendor|os|environment} function-like

[Alex L via cfe-commits]

Sorry, I forgot to add the tests in SVN. I committed them in 320735

On 14 December 2017 at 11:22, Alex Lorenz via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: arphaman
> Date: Thu Dec 14 11:22:02 2017
> New Revision: 320734
>
> URL: http://llvm.org/viewvc/llvm-project?rev=320734=rev
> Log:
> [Preprocessor] Implement __is_target_{arch|vendor|os|environment}
> function-like
> builtin macros
>
> This patch implements the __is_target_arch, __is_target_vendor,
> __is_target_os,
> and __is_target_environment Clang preprocessor extensions that were
> proposed by
> @compnerd in Bob's cfe-dev post:
> http://lists.llvm.org/pipermail/cfe-dev/2017-November/056166.html.
>
> These macros can be used to examine the components of the target triple at
> compile time. A has_builtin(is_target_???) preprocessor check can be used
> to
> check for their availability.
>
> __is_target_arch allows you to check if an arch is specified without
> worring
> about a specific subarch, e.g.
>
> __is_target_arch(arm) returns 1 for the target arch "armv7"
> __is_target_arch(armv7) returns 1 for the target arch "armv7"
> __is_target_arch(armv6) returns 0 for the target arch "armv7"
>
> __is_target_vendor and __is_target_environment match the specific vendor
> or environment. __is_target_os matches the specific OS, but
> __is_target_os(darwin) will match any Darwin-based OS. "Unknown" can be
> used
> to test if the triple's component is specified.
>
> rdar://35753116
>
> Differential Revision: https://reviews.llvm.org/D41087
>
> Modified:
> cfe/trunk/docs/ReleaseNotes.rst
> cfe/trunk/include/clang/Lex/Preprocessor.h
> cfe/trunk/lib/Lex/PPMacroExpansion.cpp
>
> Modified: cfe/trunk/docs/ReleaseNotes.rst
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/
> ReleaseNotes.rst?rev=320734=320733=320734=diff
> 
> ==
> --- cfe/trunk/docs/ReleaseNotes.rst (original)
> +++ cfe/trunk/docs/ReleaseNotes.rst Thu Dec 14 11:22:02 2017
> @@ -110,6 +110,10 @@ Non-comprehensive list of changes in thi
>If a gcc installation is found, it still prefers ``.ctors`` if the found
>gcc is older than 4.7.0.
>
> +- The new builtin preprocessor macros ``__is_target_arch``,
> +  ``__is_target_vendor``, ``__is_target_os``, and
> ``__is_target_environment``
> +  can be used to to examine the individual components of the target
> triple.
> +
>  New Compiler Flags
>  --
>
>
> Modified: cfe/trunk/include/clang/Lex/Preprocessor.h
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/Lex/Preprocessor.h?rev=320734=320733=320734=diff
> 
> ==
> --- cfe/trunk/include/clang/Lex/Preprocessor.h (original)
> +++ cfe/trunk/include/clang/Lex/Preprocessor.h Thu Dec 14 11:22:02 2017
> @@ -175,6 +175,10 @@ class Preprocessor {
>IdentifierInfo *Ident__has_cpp_attribute;// __has_cpp_attribute
>IdentifierInfo *Ident__has_c_attribute;  // __has_c_attribute
>IdentifierInfo *Ident__has_declspec; //
> __has_declspec_attribute
> +  IdentifierInfo *Ident__is_target_arch;   // __is_target_arch
> +  IdentifierInfo *Ident__is_target_vendor; // __is_target_vendor
> +  IdentifierInfo *Ident__is_target_os; // __is_target_os
> +  IdentifierInfo *Ident__is_target_environment;//
> __is_target_environment
>
>SourceLocation DATELoc, TIMELoc;
>
>
> Modified: cfe/trunk/lib/Lex/PPMacroExpansion.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/
> PPMacroExpansion.cpp?rev=320734=320733=320734=diff
> 
> ==
> --- cfe/trunk/lib/Lex/PPMacroExpansion.cpp (original)
> +++ cfe/trunk/lib/Lex/PPMacroExpansion.cpp Thu Dec 14 11:22:02 2017
> @@ -375,6 +375,11 @@ void Preprocessor::RegisterBuiltinMacros
>Ident__has_include_next = RegisterBuiltinMacro(*this,
> "__has_include_next");
>Ident__has_warning  = RegisterBuiltinMacro(*this, "__has_warning");
>Ident__is_identifier= RegisterBuiltinMacro(*this,
> "__is_identifier");
> +  Ident__is_target_arch   = RegisterBuiltinMacro(*this,
> "__is_target_arch");
> +  Ident__is_target_vendor = RegisterBuiltinMacro(*this,
> "__is_target_vendor");
> +  Ident__is_target_os = RegisterBuiltinMacro(*this, "__is_target_os");
> +  Ident__is_target_environment =
> +  RegisterBuiltinMacro(*this, "__is_target_environment");
>
>// Modules.
>Ident__building_module  = RegisterBuiltinMacro(*this,
> "__building_module");
> @@ -1593,6 +1598,57 @@ static IdentifierInfo *ExpectFeatureIden
>return nullptr;
>  }
>
> +/// Implements the __is_target_arch builtin macro.
> +static bool isTargetArch(const TargetInfo , const IdentifierInfo *II) {
> +  std::string ArchName = II->getName().lower() + "--";
> +  llvm::Triple Arch(ArchName);
> +  const llvm::Triple  = TI.getTriple();
> +  if 

Re: r320297 - Fix MSVC 'not all control paths return a value' warning

[Alex L via cfe-commits]

Thanks!

On 10 December 2017 at 03:05, Simon Pilgrim via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rksimon
> Date: Sun Dec 10 03:05:14 2017
> New Revision: 320297
>
> URL: http://llvm.org/viewvc/llvm-project?rev=320297=rev
> Log:
> Fix MSVC 'not all control paths return a value' warning
>
> Modified:
> cfe/trunk/lib/Driver/ToolChains/Darwin.cpp
>
> Modified: cfe/trunk/lib/Driver/ToolChains/Darwin.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/
> ToolChains/Darwin.cpp?rev=320297=320296=320297=diff
> 
> ==
> --- cfe/trunk/lib/Driver/ToolChains/Darwin.cpp (original)
> +++ cfe/trunk/lib/Driver/ToolChains/Darwin.cpp Sun Dec 10 03:05:14 2017
> @@ -1230,6 +1230,7 @@ struct DarwinPlatform {
>  case DeploymentTargetEnv:
>return (llvm::Twine(EnvVarName) + "=" + OSVersion).str();
>  }
> +llvm_unreachable("Unsupported Darwin Source Kind");
>}
>
>static DarwinPlatform createOSVersionArg(DarwinPlatformKind Platform,
>
>
> ___
> 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: r319848 - Fix another record-parsing-invocation.c test issue on Windows

[Alex L via cfe-commits]

I missed that one, thanks!
Sorry about the breakages.

On 5 December 2017 at 15:04, Douglas Yung via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: dyung
> Date: Tue Dec  5 15:04:12 2017
> New Revision: 319848
>
> URL: http://llvm.org/viewvc/llvm-project?rev=319848=rev
> Log:
> Fix another record-parsing-invocation.c test issue on Windows
>
> Lit's env should be used before not. (Another case missed by the previous
> commit)
>
>
> Modified:
> cfe/trunk/test/Index/record-parsing-invocation.c
>
> Modified: cfe/trunk/test/Index/record-parsing-invocation.c
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Index/
> record-parsing-invocation.c?rev=319848=319847=319848=diff
> 
> ==
> --- cfe/trunk/test/Index/record-parsing-invocation.c (original)
> +++ cfe/trunk/test/Index/record-parsing-invocation.c Tue Dec  5 15:04:12
> 2017
> @@ -1,6 +1,6 @@
>  // RUN: rm -rf %t
>  // RUN: mkdir %t
> -// RUN: not env CINDEXTEST_INVOCATION_EMISSION_PATH=%t c-index-test
> -test-load-source all %s
> +// RUN: env CINDEXTEST_INVOCATION_EMISSION_PATH=%t not c-index-test
> -test-load-source all %s
>  // RUN: cat %t/libclang-* | FileCheck %s
>
>  // RUN: rm -rf %t
>
>
> ___
> 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: r319715 - Fix record-parsing-invocation.c test on Windows

[Alex L via cfe-commits]

I committed the fix in r319836.

On 5 December 2017 at 12:49, Alex L  wrote:

> Thanks, I will take a look at it right now. I believe your solution is the
> right fix.
>
> On 5 December 2017 at 07:09, Sean Eveson  wrote:
>
>> Hi,
>>
>> It looks like the test is still failing on one of the Windows build bots:
>> http://lab.llvm.org:8011/builders/clang-x86-windows-msvc2015
>>
>> From looking at the test locally it seems the problem is when you do `//
>> RUN: not env...`. The env command doesn't get handled by llvm-lit.py,
>> because it gets passed through to `not.exe`.
>>
>> In terms of fixing this test, changing from `not env X=Y COMMAND` to `env
>> X=Y not COMMAND` works on my machine. Otherwise maybe llvm-lit could be
>> changed to make the handling of env (and other utilities) consistent when
>> used after a not?
>>
>> Thanks,
>>
>> Sean Eveson
>> SN Systems - Sony Interactive Entertainment
>>
>> On Mon, Dec 4, 2017 at 11:21 PM, Alex Lorenz via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: arphaman
>>> Date: Mon Dec  4 15:21:07 2017
>>> New Revision: 319715
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=319715=rev
>>> Log:
>>> Fix record-parsing-invocation.c test on Windows
>>>
>>> We should not check for the forward slash '/'
>>>
>>> Modified:
>>> cfe/trunk/test/Index/record-parsing-invocation.c
>>>
>>> Modified: cfe/trunk/test/Index/record-parsing-invocation.c
>>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Index/rec
>>> ord-parsing-invocation.c?rev=319715=319714=319715=diff
>>> 
>>> ==
>>> --- cfe/trunk/test/Index/record-parsing-invocation.c (original)
>>> +++ cfe/trunk/test/Index/record-parsing-invocation.c Mon Dec  4
>>> 15:21:07 2017
>>> @@ -18,4 +18,4 @@
>>>  #  pragma clang __debug parser_crash
>>>  #endif
>>>
>>> -// CHECK: {"toolchain":"{{.*}}","libclang.operation":"parse","libclang
>>> .opts":1,"args":["clang","-fno-spell-checking","{{.*}}/recor
>>> d-parsing-invocation.c","-Xclang","-detailed-preprocessi
>>> ng-record","-fallow-editor-placeholders"]}
>>> +// CHECK: {"toolchain":"{{.*}}","libclang.operation":"parse","libclang
>>> .opts":1,"args":["clang","-fno-spell-checking","{{.*}}record
>>> -parsing-invocation.c","-Xclang","-detailed-preprocessi
>>> ng-record","-fallow-editor-placeholders"]}
>>>
>>>
>>> ___
>>> 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: r319715 - Fix record-parsing-invocation.c test on Windows

[Alex L via cfe-commits]

Thanks, I will take a look at it right now. I believe your solution is the
right fix.

On 5 December 2017 at 07:09, Sean Eveson  wrote:

> Hi,
>
> It looks like the test is still failing on one of the Windows build bots:
> http://lab.llvm.org:8011/builders/clang-x86-windows-msvc2015
>
> From looking at the test locally it seems the problem is when you do `//
> RUN: not env...`. The env command doesn't get handled by llvm-lit.py,
> because it gets passed through to `not.exe`.
>
> In terms of fixing this test, changing from `not env X=Y COMMAND` to `env
> X=Y not COMMAND` works on my machine. Otherwise maybe llvm-lit could be
> changed to make the handling of env (and other utilities) consistent when
> used after a not?
>
> Thanks,
>
> Sean Eveson
> SN Systems - Sony Interactive Entertainment
>
> On Mon, Dec 4, 2017 at 11:21 PM, Alex Lorenz via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: arphaman
>> Date: Mon Dec  4 15:21:07 2017
>> New Revision: 319715
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=319715=rev
>> Log:
>> Fix record-parsing-invocation.c test on Windows
>>
>> We should not check for the forward slash '/'
>>
>> Modified:
>> cfe/trunk/test/Index/record-parsing-invocation.c
>>
>> Modified: cfe/trunk/test/Index/record-parsing-invocation.c
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Index/rec
>> ord-parsing-invocation.c?rev=319715=319714=319715=diff
>> 
>> ==
>> --- cfe/trunk/test/Index/record-parsing-invocation.c (original)
>> +++ cfe/trunk/test/Index/record-parsing-invocation.c Mon Dec  4 15:21:07
>> 2017
>> @@ -18,4 +18,4 @@
>>  #  pragma clang __debug parser_crash
>>  #endif
>>
>> -// CHECK: {"toolchain":"{{.*}}","libclang.operation":"parse","libclang
>> .opts":1,"args":["clang","-fno-spell-checking","{{.*}}/
>> record-parsing-invocation.c","-Xclang","-detailed-
>> preprocessing-record","-fallow-editor-placeholders"]}
>> +// CHECK: {"toolchain":"{{.*}}","libclang.operation":"parse","libclang
>> .opts":1,"args":["clang","-fno-spell-checking","{{.*}}
>> record-parsing-invocation.c","-Xclang","-detailed-
>> preprocessing-record","-fallow-editor-placeholders"]}
>>
>>
>> ___
>> 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: [clang-tools-extra] r318327 - [clangd] Try to unbreak tests on PS4 by targeting PC explicitly

[Alex L via cfe-commits]

This doesn't seem like a good permanent solution (as Paul pointed out -std
will change in the future). Will you be able to avoid this in the future?

On 15 November 2017 at 11:38, Sam McCall via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: sammccall
> Date: Wed Nov 15 11:38:09 2017
> New Revision: 318327
>
> URL: http://llvm.org/viewvc/llvm-project?rev=318327=rev
> Log:
> [clangd] Try to unbreak tests on PS4 by targeting PC explicitly
>
> Modified:
> clang-tools-extra/trunk/clangd/GlobalCompilationDatabase.cpp
>
> Modified: clang-tools-extra/trunk/clangd/GlobalCompilationDatabase.cpp
> URL: http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/
> GlobalCompilationDatabase.cpp?rev=318327=318326=318327=diff
> 
> ==
> --- clang-tools-extra/trunk/clangd/GlobalCompilationDatabase.cpp
> (original)
> +++ clang-tools-extra/trunk/clangd/GlobalCompilationDatabase.cpp Wed Nov
> 15 11:38:09 2017
> @@ -31,7 +31,11 @@ static void addExtraFlags(tooling::Compi
>  }
>
>  tooling::CompileCommand getDefaultCompileCommand(PathRef File) {
> -  std::vector CommandLine{"clang", "-fsyntax-only",
> File.str()};
> +  // We don't specify --std because we want to infer it from the filename.
> +  // We force PC because PS4 will change --std from under us.
> +  // FIXME: there must be a more principled way to do this!
> +  std::vector CommandLine{
> +  "clang", "-fsyntax-only", "-triple=unknown-pc-unknown", File.str()};
>return tooling::CompileCommand(llvm::sys::path::parent_path(File),
>   llvm::sys::path::filename(File),
> CommandLine,
>   /*Output=*/"");
>
>
> ___
> 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: r316152 - Fix a few nits in RenamingAction.

[Alex L via cfe-commits]

Thanks!

On 19 October 2017 at 01:20, Haojian Wu via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: hokein
> Date: Thu Oct 19 01:20:55 2017
> New Revision: 316152
>
> URL: http://llvm.org/viewvc/llvm-project?rev=316152=rev
> Log:
> Fix a few nits in RenamingAction.
>
> * Add missing override keyword.
> * avoid unnecessary copy of std::string.
>
> Modified:
> cfe/trunk/lib/Tooling/Refactoring/Rename/RenamingAction.cpp
>
> Modified: cfe/trunk/lib/Tooling/Refactoring/Rename/RenamingAction.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Tooling/
> Refactoring/Rename/RenamingAction.cpp?rev=316152&
> r1=316151=316152=diff
> 
> ==
> --- cfe/trunk/lib/Tooling/Refactoring/Rename/RenamingAction.cpp (original)
> +++ cfe/trunk/lib/Tooling/Refactoring/Rename/RenamingAction.cpp Thu Oct
> 19 01:20:55 2017
> @@ -77,10 +77,10 @@ private:
>  class RenameOccurrences final : public SourceChangeRefactoringRule {
>  public:
>RenameOccurrences(const NamedDecl *ND, std::string NewName)
> -  : Finder(ND), NewName(NewName) {}
> +  : Finder(ND), NewName(std::move(NewName)) {}
>
>Expected
> -  createSourceReplacements(RefactoringRuleContext ) {
> +  createSourceReplacements(RefactoringRuleContext ) override {
>  Expected Occurrences =
>  Finder.findSymbolOccurrences(Context);
>  if (!Occurrences)
>
>
> ___
> 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: r315755 - Fix -Woverloaded-virtual warning in clang-refactor

[Alex L via cfe-commits]

That's a good idea! I'll commit an llvm_unreachable fix for this override
then.

On 16 October 2017 at 10:32, David Blaikie  wrote:

> Generally it's preferably to avoid adding dead code (partly for this
> reason - it's hard to track when it gets used and ensure it's appropriately
> tested) could the member function's body be replaced with llvm_unreachable
> for now, then?
>
> On Mon, Oct 16, 2017 at 10:27 AM Alex L  wrote:
>
>> At the moment this method override is not used by the clang-refactor
>> tool, so I don't think I can add a test for it.
>>
>> On 16 October 2017 at 10:11, David Blaikie  wrote:
>>
>>> Is there a test that could be added to cover this new code?
>>>
>>> On Fri, Oct 13, 2017 at 2:15 PM Alex Lorenz via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 Author: arphaman
 Date: Fri Oct 13 14:15:25 2017
 New Revision: 315755

 URL: http://llvm.org/viewvc/llvm-project?rev=315755=rev
 Log:
 Fix -Woverloaded-virtual warning in clang-refactor

 Modified:
 cfe/trunk/tools/clang-refactor/ClangRefactor.cpp

 Modified: cfe/trunk/tools/clang-refactor/ClangRefactor.cpp
 URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-
 refactor/ClangRefactor.cpp?rev=315755=315754=315755=diff
 
 ==
 --- cfe/trunk/tools/clang-refactor/ClangRefactor.cpp (original)
 +++ cfe/trunk/tools/clang-refactor/ClangRefactor.cpp Fri Oct 13
 14:15:25 2017
 @@ -314,6 +314,10 @@ public:
  SourceChanges.insert(SourceChanges.begin(), Changes.begin(),
 Changes.end());
}

 +  void handle(SymbolOccurrences Occurrences) override {
 +RefactoringResultConsumer::handle(std::move(Occurrences));
 +  }
 +
const AtomicChanges () const { return
 SourceChanges; }

  private:


 ___
 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: r315755 - Fix -Woverloaded-virtual warning in clang-refactor

[Alex L via cfe-commits]

At the moment this method override is not used by the clang-refactor tool,
so I don't think I can add a test for it.

On 16 October 2017 at 10:11, David Blaikie  wrote:

> Is there a test that could be added to cover this new code?
>
> On Fri, Oct 13, 2017 at 2:15 PM Alex Lorenz via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: arphaman
>> Date: Fri Oct 13 14:15:25 2017
>> New Revision: 315755
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=315755=rev
>> Log:
>> Fix -Woverloaded-virtual warning in clang-refactor
>>
>> Modified:
>> cfe/trunk/tools/clang-refactor/ClangRefactor.cpp
>>
>> Modified: cfe/trunk/tools/clang-refactor/ClangRefactor.cpp
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-
>> refactor/ClangRefactor.cpp?rev=315755=315754=315755=diff
>> 
>> ==
>> --- cfe/trunk/tools/clang-refactor/ClangRefactor.cpp (original)
>> +++ cfe/trunk/tools/clang-refactor/ClangRefactor.cpp Fri Oct 13 14:15:25
>> 2017
>> @@ -314,6 +314,10 @@ public:
>>  SourceChanges.insert(SourceChanges.begin(), Changes.begin(),
>> Changes.end());
>>}
>>
>> +  void handle(SymbolOccurrences Occurrences) override {
>> +RefactoringResultConsumer::handle(std::move(Occurrences));
>> +  }
>> +
>>const AtomicChanges () const { return SourceChanges; }
>>
>>  private:
>>
>>
>> ___
>> 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: r309386 - Recommit r308327 3rd time: Add a warning for missing

[Alex L via cfe-commits]

Are the pshpack1.h/poppack.h headers included from other headers in the SDK
or are they intended for end-users? If they're only used in the SDK then
the SDK headers should probably be system headers, so the warning should be
silenced.

Apart from that there's no real good solution for this issue unfortunately
apart from turning off the warning with a command-line flag or a pragma. I
don't think this particular pattern warrants some sort of special treatment
in Clang.

On 26 September 2017 at 17:02, Nico Weber  wrote:

> Another bit of feedback: The Microsoft SDK has pragma adjustment headers
> that are used like so:
>
> #include 
> // Define structs with alignment 1 here
> #include 
>
> This warning fires on that. I haven't seen these headers in active use
> recently, but I remember seeing them quite a bit maybe 10 years ago. (It
> took me until today to remember their names.) Any ideas on how to deal with
> that?
>
> On Fri, Jul 28, 2017 at 2:41 PM, Alex Lorenz via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: arphaman
>> Date: Fri Jul 28 07:41:21 2017
>> New Revision: 309386
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=309386=rev
>> Log:
>> Recommit r308327 3rd time: Add a warning for missing
>> '#pragma pack (pop)' and suspicious uses of '#pragma pack' in included
>> files
>>
>> The second recommit (r309106) was reverted because the "non-default
>> #pragma
>> pack value chages the alignment of struct or union members in the
>> included file"
>> warning proved to be too aggressive for external projects like Chromium
>> (https://bugs.chromium.org/p/chromium/issues/detail?id=749197). This
>> recommit
>> makes the problematic warning a non-default one, and gives it the
>> -Wpragma-pack-suspicious-include warning option.
>>
>> The first recommit (r308441) caused a "non-default #pragma pack value
>> might
>> change the alignment of struct or union members in the included file"
>> warning
>> in LLVM itself. This recommit tweaks the added warning to avoid warnings
>> for
>> #includes that don't have any records that are affected by the non-default
>> alignment. This tweak avoids the previously emitted warning in LLVM.
>>
>> Original message:
>>
>> This commit adds a new -Wpragma-pack warning. It warns in the following
>> cases:
>>
>> - When a translation unit is missing terminating #pragma pack (pop)
>> directives.
>> - When entering an included file if the current alignment value as
>> determined
>>   by '#pragma pack' directives is different from the default alignment
>> value.
>> - When leaving an included file that changed the state of the current
>> alignment
>>   value.
>>
>> rdar://10184173
>>
>> Differential Revision: https://reviews.llvm.org/D35484
>>
>> Added:
>> cfe/trunk/test/PCH/suspicious-pragma-pack.c
>> cfe/trunk/test/Sema/Inputs/pragma-pack1.h
>> cfe/trunk/test/Sema/Inputs/pragma-pack2.h
>> cfe/trunk/test/Sema/suspicious-pragma-pack.c
>> cfe/trunk/test/SemaObjC/Inputs/empty.h
>> cfe/trunk/test/SemaObjC/suspicious-pragma-pack.m
>> Modified:
>> cfe/trunk/include/clang/Basic/DiagnosticGroups.td
>> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
>> cfe/trunk/include/clang/Lex/PPCallbacks.h
>> cfe/trunk/include/clang/Sema/Sema.h
>> cfe/trunk/include/clang/Serialization/ASTReader.h
>> cfe/trunk/lib/Parse/ParsePragma.cpp
>> cfe/trunk/lib/Sema/Sema.cpp
>> cfe/trunk/lib/Sema/SemaAttr.cpp
>> cfe/trunk/lib/Serialization/ASTReader.cpp
>> cfe/trunk/lib/Serialization/ASTWriter.cpp
>> cfe/trunk/test/OpenMP/declare_simd_messages.cpp
>> cfe/trunk/test/PCH/pragma-pack.c
>> cfe/trunk/test/Parser/pragma-options.c
>> cfe/trunk/test/Parser/pragma-options.cpp
>> cfe/trunk/test/Parser/pragma-pack.c
>> cfe/trunk/test/Sema/pragma-pack.c
>>
>> Modified: cfe/trunk/include/clang/Basic/DiagnosticGroups.td
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/
>> Basic/DiagnosticGroups.td?rev=309386=309385=309386=diff
>> 
>> ==
>> --- cfe/trunk/include/clang/Basic/DiagnosticGroups.td (original)
>> +++ cfe/trunk/include/clang/Basic/DiagnosticGroups.td Fri Jul 28
>> 07:41:21 2017
>> @@ -471,8 +471,10 @@ def IgnoredPragmaIntrinsic : DiagGroup<"
>>  def UnknownPragmas : DiagGroup<"unknown-pragmas">;
>>  def IgnoredPragmas : DiagGroup<"ignored-pragmas",
>> [IgnoredPragmaIntrinsic]>;
>>  def PragmaClangAttribute : DiagGroup<"pragma-clang-attribute">;
>> +def PragmaPackSuspiciousInclude : DiagGroup<"pragma-pack-suspici
>> ous-include">;
>> +def PragmaPack : DiagGroup<"pragma-pack", [PragmaPackSuspiciousInclude]>
>> ;
>>  def Pragmas : DiagGroup<"pragmas", [UnknownPragmas, IgnoredPragmas,
>> -PragmaClangAttribute]>;
>> +PragmaClangAttribute, PragmaPack]>;
>>  def UnknownWarningOption : DiagGroup<"unknown-warning-option">;
>>  def 

Re: [clang-tools-extra] r313754 - [clangd] Serialize onDiagnosticsReady callbacks for the same file.

[Alex L via cfe-commits]

Perfect, thanks!

On 20 September 2017 at 20:33, Ilya Biryukov  wrote:

> Fixed by r313801.
> Sorry for all the trouble.
>
> On Wed, Sep 20, 2017 at 9:22 PM, Ilya Biryukov 
> wrote:
>
>> I think I know what's wrong. I've already seen those failures. std::mutex
>> gets destroyed before threads waiting on it are joined.
>> Will submit a fix shortly.
>>
>> On Wed, Sep 20, 2017 at 8:22 PM, Alex L  wrote:
>>
>>> This commit causes the formatting.test to fail on macOS with an uncaught
>>> exception:
>>>
>>> libc++abi.dylib: terminating with uncaught exception of type
>>> std::__1::system_error: mutex lock failed: Invalid argument
>>> http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA
>>> _check/35642/
>>>
>>> I'm still looking into it. It doesn't look like the sanitizers are
>>> reporting anything suspicious. Do you by any chance know what went wrong?
>>> If it will turn out to be a macOS only thing it might make sense to
>>> XFAIL formatting.test until the issue is resolved.
>>>
>>> Thanks,
>>> Alex
>>>
>>> On 20 September 2017 at 13:58, Ilya Biryukov via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 Author: ibiryukov
 Date: Wed Sep 20 05:58:55 2017
 New Revision: 313754

 URL: http://llvm.org/viewvc/llvm-project?rev=313754=rev
 Log:
 [clangd] Serialize onDiagnosticsReady callbacks for the same file.

 Summary:
 Calls to onDiagnosticsReady were done concurrently before. This
 sometimes
 led to older versions of diagnostics being reported to the user after
 the newer versions.

 Reviewers: klimek, bkramer, krasimir

 Reviewed By: klimek

 Subscribers: cfe-commits

 Differential Revision: https://reviews.llvm.org/D38032

 Modified:
 clang-tools-extra/trunk/clangd/ClangdServer.cpp
 clang-tools-extra/trunk/clangd/ClangdServer.h
 clang-tools-extra/trunk/clangd/DraftStore.h
 clang-tools-extra/trunk/unittests/clangd/ClangdTests.cpp

 Modified: clang-tools-extra/trunk/clangd/ClangdServer.cpp
 URL: http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/
 clangd/ClangdServer.cpp?rev=313754=313753=313754=diff
 
 ==
 --- clang-tools-extra/trunk/clangd/ClangdServer.cpp (original)
 +++ clang-tools-extra/trunk/clangd/ClangdServer.cpp Wed Sep 20
 05:58:55 2017
 @@ -315,6 +315,19 @@ std::future ClangdServer::schedule
  auto Diags = DeferredRebuild.get();
  if (!Diags)
return; // A new reparse was requested before this one completed.
 +
 +// We need to serialize access to resulting diagnostics to avoid
 calling
 +// `onDiagnosticsReady` in the wrong order.
 +std::lock_guard DiagsLock(DiagnosticsMutex);
 +DocVersion  =
 ReportedDiagnosticVersions[FileStr];
 +// FIXME(ibiryukov): get rid of '<' comparison here. In the current
 +// implementation diagnostics will not be reported after version
 counters'
 +// overflow. This should not happen in practice, since DocVersion
 is a
 +// 64-bit unsigned integer.
 +if (Version < LastReportedDiagsVersion)
 +  return;
 +LastReportedDiagsVersion = Version;
 +
  DiagConsumer.onDiagnosticsReady(FileStr,
  make_tagged(std::move(*Diags),
 Tag));
};

 Modified: clang-tools-extra/trunk/clangd/ClangdServer.h
 URL: http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/
 clangd/ClangdServer.h?rev=313754=313753=313754=diff
 
 ==
 --- clang-tools-extra/trunk/clangd/ClangdServer.h (original)
 +++ clang-tools-extra/trunk/clangd/ClangdServer.h Wed Sep 20 05:58:55
 2017
 @@ -284,6 +284,13 @@ private:
// ClangdServer
ClangdScheduler WorkScheduler;
bool SnippetCompletions;
 +
 +  /// Used to serialize diagnostic callbacks.
 +  /// FIXME(ibiryukov): get rid of an extra map and put all version
 counters
 +  /// into CppFile.
 +  std::mutex DiagnosticsMutex;
 +  /// Maps from a filename to the latest version of reported
 diagnostics.
 +  llvm::StringMap ReportedDiagnosticVersions;
  };

  } // namespace clangd

 Modified: clang-tools-extra/trunk/clangd/DraftStore.h
 URL: http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/
 clangd/DraftStore.h?rev=313754=313753=313754=diff
 
 ==
 --- clang-tools-extra/trunk/clangd/DraftStore.h (original)
 +++ clang-tools-extra/trunk/clangd/DraftStore.h Wed Sep 20 05:58:55
 2017
 @@ -13,6 +13,7 @@
  #include "Path.h"
  #include 

Re: [clang-tools-extra] r313754 - [clangd] Serialize onDiagnosticsReady callbacks for the same file.

[Alex L via cfe-commits]

This commit causes the formatting.test to fail on macOS with an uncaught
exception:

libc++abi.dylib: terminating with uncaught exception of type
std::__1::system_error: mutex lock failed: Invalid argument
http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA_check/35642/

I'm still looking into it. It doesn't look like the sanitizers are
reporting anything suspicious. Do you by any chance know what went wrong?
If it will turn out to be a macOS only thing it might make sense to XFAIL
formatting.test until the issue is resolved.

Thanks,
Alex

On 20 September 2017 at 13:58, Ilya Biryukov via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: ibiryukov
> Date: Wed Sep 20 05:58:55 2017
> New Revision: 313754
>
> URL: http://llvm.org/viewvc/llvm-project?rev=313754=rev
> Log:
> [clangd] Serialize onDiagnosticsReady callbacks for the same file.
>
> Summary:
> Calls to onDiagnosticsReady were done concurrently before. This sometimes
> led to older versions of diagnostics being reported to the user after
> the newer versions.
>
> Reviewers: klimek, bkramer, krasimir
>
> Reviewed By: klimek
>
> Subscribers: cfe-commits
>
> Differential Revision: https://reviews.llvm.org/D38032
>
> Modified:
> clang-tools-extra/trunk/clangd/ClangdServer.cpp
> clang-tools-extra/trunk/clangd/ClangdServer.h
> clang-tools-extra/trunk/clangd/DraftStore.h
> clang-tools-extra/trunk/unittests/clangd/ClangdTests.cpp
>
> Modified: clang-tools-extra/trunk/clangd/ClangdServer.cpp
> URL: http://llvm.org/viewvc/llvm-project/clang-tools-extra/
> trunk/clangd/ClangdServer.cpp?rev=313754=313753=313754=diff
> 
> ==
> --- clang-tools-extra/trunk/clangd/ClangdServer.cpp (original)
> +++ clang-tools-extra/trunk/clangd/ClangdServer.cpp Wed Sep 20 05:58:55
> 2017
> @@ -315,6 +315,19 @@ std::future ClangdServer::schedule
>  auto Diags = DeferredRebuild.get();
>  if (!Diags)
>return; // A new reparse was requested before this one completed.
> +
> +// We need to serialize access to resulting diagnostics to avoid
> calling
> +// `onDiagnosticsReady` in the wrong order.
> +std::lock_guard DiagsLock(DiagnosticsMutex);
> +DocVersion  = ReportedDiagnosticVersions[
> FileStr];
> +// FIXME(ibiryukov): get rid of '<' comparison here. In the current
> +// implementation diagnostics will not be reported after version
> counters'
> +// overflow. This should not happen in practice, since DocVersion is a
> +// 64-bit unsigned integer.
> +if (Version < LastReportedDiagsVersion)
> +  return;
> +LastReportedDiagsVersion = Version;
> +
>  DiagConsumer.onDiagnosticsReady(FileStr,
>  make_tagged(std::move(*Diags), Tag));
>};
>
> Modified: clang-tools-extra/trunk/clangd/ClangdServer.h
> URL: http://llvm.org/viewvc/llvm-project/clang-tools-extra/
> trunk/clangd/ClangdServer.h?rev=313754=313753=313754=diff
> 
> ==
> --- clang-tools-extra/trunk/clangd/ClangdServer.h (original)
> +++ clang-tools-extra/trunk/clangd/ClangdServer.h Wed Sep 20 05:58:55 2017
> @@ -284,6 +284,13 @@ private:
>// ClangdServer
>ClangdScheduler WorkScheduler;
>bool SnippetCompletions;
> +
> +  /// Used to serialize diagnostic callbacks.
> +  /// FIXME(ibiryukov): get rid of an extra map and put all version
> counters
> +  /// into CppFile.
> +  std::mutex DiagnosticsMutex;
> +  /// Maps from a filename to the latest version of reported diagnostics.
> +  llvm::StringMap ReportedDiagnosticVersions;
>  };
>
>  } // namespace clangd
>
> Modified: clang-tools-extra/trunk/clangd/DraftStore.h
> URL: http://llvm.org/viewvc/llvm-project/clang-tools-extra/
> trunk/clangd/DraftStore.h?rev=313754=313753=313754=diff
> 
> ==
> --- clang-tools-extra/trunk/clangd/DraftStore.h (original)
> +++ clang-tools-extra/trunk/clangd/DraftStore.h Wed Sep 20 05:58:55 2017
> @@ -13,6 +13,7 @@
>  #include "Path.h"
>  #include "clang/Basic/LLVM.h"
>  #include "llvm/ADT/StringMap.h"
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -20,8 +21,8 @@
>  namespace clang {
>  namespace clangd {
>
> -/// Using 'unsigned' here to avoid undefined behaviour on overflow.
> -typedef unsigned DocVersion;
> +/// Using unsigned int type here to avoid undefined behaviour on overflow.
> +typedef uint64_t DocVersion;
>
>  /// Document draft with a version of this draft.
>  struct VersionedDraft {
>
> Modified: clang-tools-extra/trunk/unittests/clangd/ClangdTests.cpp
> URL: http://llvm.org/viewvc/llvm-project/clang-tools-extra/
> trunk/unittests/clangd/ClangdTests.cpp?rev=313754=
> 313753=313754=diff
> 
> ==
> --- clang-tools-extra/trunk/unittests/clangd/ClangdTests.cpp (original)
> +++ 

Re: r310983 - PR19668, PR23034: Fix handling of move constructors and deleted copy

[Alex L via cfe-commits]

On 16 August 2017 at 02:49, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rsmith
> Date: Tue Aug 15 18:49:53 2017
> New Revision: 310983
>
> URL: http://llvm.org/viewvc/llvm-project?rev=310983=rev
> Log:
> PR19668, PR23034: Fix handling of move constructors and deleted copy
> constructors when deciding whether classes should be passed indirectly.
>
> This fixes ABI differences between Clang and GCC:
>
>  * Previously, Clang ignored the move constructor when making this
>determination. It now takes the move constructor into account, per
>https://github.com/itanium-cxx-abi/cxx-abi/pull/17 (this change may
>seem recent, but the ABI change was agreed on the Itanium C++ ABI
>list a long time ago).
>
>  * Previously, Clang's behavior when the copy constructor was deleted
>was unstable -- depending on whether the lazy declaration of the
>copy constructor had been triggered, you might get different behavior.
>We now eagerly declare the copy constructor whenever its deletedness
>is unclear, and ignore deleted copy/move constructors when looking for
>a trivial such constructor.
>
> This also fixes an ABI difference between Clang and MSVC:
>
>  * If the copy constructor would be implicitly deleted (but has not been
>lazily declared yet), for instance because the class has an rvalue
>reference member, we would pass it directly. We now pass such a class
>indirectly, matching MSVC.
>
> Based on a patch by Vassil Vassilev, which was based on a patch by Bernd
> Schmidt, which was based on a patch by Reid Kleckner!
>
> This is a re-commit of r310401, which was reverted in r310464 due to ARM
> failures (which should now be fixed).
>
> Modified:
> cfe/trunk/include/clang/AST/DeclCXX.h
> cfe/trunk/lib/AST/ASTImporter.cpp
> cfe/trunk/lib/AST/DeclCXX.cpp
> cfe/trunk/lib/CodeGen/CGCXXABI.cpp
> cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
> cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp
> cfe/trunk/lib/Sema/SemaDeclCXX.cpp
> cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
> cfe/trunk/lib/Serialization/ASTWriter.cpp
> cfe/trunk/test/CodeGenCXX/uncopyable-args.cpp
> cfe/trunk/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp
>
> Modified: cfe/trunk/include/clang/AST/DeclCXX.h
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/AST/DeclCXX.h?rev=310983=310982=310983=diff
> 
> ==
> --- cfe/trunk/include/clang/AST/DeclCXX.h (original)
> +++ cfe/trunk/include/clang/AST/DeclCXX.h Tue Aug 15 18:49:53 2017
> @@ -374,6 +374,7 @@ class CXXRecordDecl : public RecordDecl
>  /// \brief These flags are \c true if a defaulted corresponding
> special
>  /// member can't be fully analyzed without performing overload
> resolution.
>  /// @{
> +unsigned NeedOverloadResolutionForCopyConstructor : 1;
>  unsigned NeedOverloadResolutionForMoveConstructor : 1;
>  unsigned NeedOverloadResolutionForMoveAssignment : 1;
>  unsigned NeedOverloadResolutionForDestructor : 1;
> @@ -382,6 +383,7 @@ class CXXRecordDecl : public RecordDecl
>  /// \brief These flags are \c true if an implicit defaulted
> corresponding
>  /// special member would be defined as deleted.
>  /// @{
> +unsigned DefaultedCopyConstructorIsDeleted : 1;
>  unsigned DefaultedMoveConstructorIsDeleted : 1;
>  unsigned DefaultedMoveAssignmentIsDeleted : 1;
>  unsigned DefaultedDestructorIsDeleted : 1;
> @@ -414,6 +416,12 @@ class CXXRecordDecl : public RecordDecl
>  /// constructor.
>  unsigned HasDefaultedDefaultConstructor : 1;
>
> +/// \brief True if this class can be passed in a
> non-address-preserving
> +/// fashion (such as in registers) according to the C++ language
> rules.
> +/// This does not imply anything about how the ABI in use will
> actually
> +/// pass an object of this class.
> +unsigned CanPassInRegisters : 1;
> +
>  /// \brief True if a defaulted default constructor for this class
> would
>  /// be constexpr.
>  unsigned DefaultedDefaultConstructorIsConstexpr : 1;
> @@ -810,18 +818,50 @@ public:
>  return data().FirstFriend.isValid();
>}
>
> +  /// \brief \c true if a defaulted copy constructor for this class would
> be
> +  /// deleted.
> +  bool defaultedCopyConstructorIsDeleted() const {
> +assert((!needsOverloadResolutionForCopyConstructor() ||
> +(data().DeclaredSpecialMembers & SMF_CopyConstructor)) &&
> +   "this property has not yet been computed by Sema");
> +return data().DefaultedCopyConstructorIsDeleted;
> +  }
> +
> +  /// \brief \c true if a defaulted move constructor for this class would
> be
> +  /// deleted.
> +  bool defaultedMoveConstructorIsDeleted() const {
> +assert((!needsOverloadResolutionForMoveConstructor() ||
> +(data().DeclaredSpecialMembers & SMF_MoveConstructor)) &&
> +   "this property 

Re: r312633 - [AST] Traverse CXXOperatorCallExpr in LexicallyOrderedRecursiveASTVisitor

[Alex L via cfe-commits]

It's a good idea to merge the two. I'll work on moving the ObjC traversal
change when I get the time.

Thanks for the quick patches Johannes!

On 9 September 2017 at 12:03, Johannes Altmanninger 
wrote:

> Richard Smith  writes:
>
> > I am extremely uncomfortable about the direction this patch series is
> going.
> >
> > We have had two different RecursiveASTVisitors before
> (RecursiveASTVisitor
> > and DataRecursiveASTVisitor), and it was a maintenance nightmare:
> > frequently changes would be made to one of them and missed in the other
> > one, resulting in hard to track down bugs, as well as redundant
> development
> > effort making changes to both.
> >
> > Back when this was simply deriving from RecursiveASTVisitor and not
> > changing much, LexicallyOrderedRecursiveASTVisitor seemed like it
> wouldn't
> > suffer from the same problem, but it's becoming increasingly clear that
> > that simply isn't going to be the case long-term. And worse, there seems
> to
> > be absolutely no purpose in having two different visitors here -- the
> > existing users of RecursiveASTVisitor generally don't care about
> visitation
> > order.
> >
> > Also, we can play the "what if two people did this" game -- adding RAV
> > functionality in derived classes doesn't compose well. (If post-order
> > traversal were a derived class, you couldn't request a lexically-ordered
> > post-order traversal, and so on.)
> >
> > Therefore, I'd like to suggest that you stop making changes to
> > LexicallyOrderedRecursiveASTVisitor and instead start to fold its
> > functionality back into RecursiveASTVisitor, as follows:
> >
> >  * in cases where there is no reason for RAV to visit in non-lexical
> order,
> > change it to visit in lexical order
> >  * if there are any cases where there *is* a reason for non-lexical
> > visitation, add a bool function to it so the derived class can request
> > lexical / non-lexical order (like the existing shouldTraversePostOrder /
> > shouldVisitImplicitCode / ... functions).
>
> Ok, makes sense.
>
> +Alex so you are aware.
>
> I have created two revisions to move my changes to RecursiveASTVisitor,
> this should not break anything. I left the tests in
> LexicallyOrderedRecursiveASTVisitorTest for now because it saves some
> code duplication, but let's see, if we merge all the changes into
> RecursiveASTVisitor, then the tests will naturally follow.
>
> https://reviews.llvm.org/D37662
> https://reviews.llvm.org/D37663
>
> >
> > On 6 September 2017 at 06:12, Johannes Altmanninger via cfe-commits <
> > cfe-commits@lists.llvm.org> wrote:
> >
> >> Author: krobelus
> >> Date: Wed Sep  6 06:12:11 2017
> >> New Revision: 312633
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=312633=rev
> >> Log:
> >> [AST] Traverse CXXOperatorCallExpr in LexicallyOrderedRecursiveASTVi
> sitor
> >>
> >> Summary:
> >> This affects overloaded operators, which are represented by a
> >> CXXOperatorCallExpr whose first child is always a DeclRefExpr referring
> to
> >> the
> >> operator. For infix, postfix and call operators we want the first
> argument
> >> to be traversed before the operator.
> >>
> >> Reviewers: arphaman
> >>
> >> Subscribers: klimek, cfe-commits
> >>
> >> Differential Revision: https://reviews.llvm.org/D37200
> >>
> >> Modified:
> >> cfe/trunk/include/clang/AST/LexicallyOrderedRecursiveASTVisitor.h
> >> cfe/trunk/include/clang/AST/RecursiveASTVisitor.h
> >> cfe/trunk/unittests/Tooling/LexicallyOrderedRecursiveASTVi
> >> sitorTest.cpp
> >>
> >> Modified: cfe/trunk/include/clang/AST/LexicallyOrderedRecursiveASTVi
> >> sitor.h
> >> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/
> >> LexicallyOrderedRecursiveASTVisitor.h?rev=312633=312632&
> >> r2=312633=diff
> >> 
> >> ==
> >> --- cfe/trunk/include/clang/AST/LexicallyOrderedRecursiveASTVisitor.h
> >> (original)
> >> +++ cfe/trunk/include/clang/AST/LexicallyOrderedRecursiveASTVisitor.h
> Wed
> >> Sep  6 06:12:11 2017
> >> @@ -113,6 +113,33 @@ public:
> >>
> >>bool shouldTraverseTemplateArgumentsBeforeDecl() const { return
> true; }
> >>
> >> +  Stmt::child_range getStmtChildren(Stmt *S) { return S->children(); }
> >> +
> >> +  SmallVector getStmtChildren(CXXOperatorCallExpr *CE) {
> >> +SmallVector Children(CE->children());
> >> +bool Swap;
> >> +// Switch the operator and the first operand for all infix and
> postfix
> >> +// operations.
> >> +switch (CE->getOperator()) {
> >> +case OO_Arrow:
> >> +case OO_Call:
> >> +case OO_Subscript:
> >> +  Swap = true;
> >> +  break;
> >> +case OO_PlusPlus:
> >> +case OO_MinusMinus:
> >> +  // These are postfix unless there is exactly one argument.
> >> +  Swap = Children.size() != 2;
> >> +  break;
> >> +default:
> >> +  Swap = CE->isInfixBinaryOp();
> >> +  break;
> >> +}
> >> +if (Swap && 

Re: r284549 - DR1330: instantiate exception-specifications when "needed". We previously did

[Alex L via cfe-commits]

Hi Richard,

It looks like this commit caused PR34298 (https://bugs.llvm.org/show_bu
g.cgi?id=34298). Now Clang fails to compile a libc++ std::function member
variable with an incomplete return type. Libstdc++ works though, so I
assume that the right way to fix this is to change libc++?

Cheers,
Alex

On 19 October 2016 at 00:39, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rsmith
> Date: Tue Oct 18 18:39:12 2016
> New Revision: 284549
>
> URL: http://llvm.org/viewvc/llvm-project?rev=284549=rev
> Log:
> DR1330: instantiate exception-specifications when "needed". We previously
> did
> not instantiate exception specifications of functions if they were only
> used in
> unevaluated contexts (other than 'noexcept' expressions).
>
> In C++17 onwards, this becomes essential since the exception specification
> is
> now part of the function's type.
>
> Note that this means that constructs like the following no longer work:
>
>   struct A {
> static T f() noexcept(...);
> decltype(f()) *p;
>   };
>
> ... because the decltype expression now needs the exception specification
> of
> 'f', which has not yet been parsed.
>
> Modified:
> cfe/trunk/lib/Sema/SemaExpr.cpp
> cfe/trunk/lib/Sema/SemaOverload.cpp
> cfe/trunk/test/CXX/drs/dr13xx.cpp
> cfe/trunk/test/SemaCXX/constant-expression-cxx1z.cpp
> cfe/trunk/test/SemaCXX/cxx0x-defaulted-functions.cpp
> cfe/trunk/test/SemaCXX/libstdcxx_pair_swap_hack.cpp
> cfe/trunk/test/SemaTemplate/instantiate-exception-spec-cxx11.cpp
> cfe/trunk/www/cxx_dr_status.html
>
> Modified: cfe/trunk/lib/Sema/SemaExpr.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/
> SemaExpr.cpp?rev=284549=284548=284549=diff
> 
> ==
> --- cfe/trunk/lib/Sema/SemaExpr.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaExpr.cpp Tue Oct 18 18:39:12 2016
> @@ -2889,6 +2889,14 @@ ExprResult Sema::BuildDeclarationNameExp
>
>{
>  QualType type = VD->getType();
> +if (auto *FPT = type->getAs()) {
> +  // C++ [except.spec]p17:
> +  //   An exception-specification is considered to be needed when:
> +  //   - in an expression, the function is the unique lookup result or
> +  // the selected member of a set of overloaded functions.
> +  ResolveExceptionSpec(Loc, FPT);
> +  type = VD->getType();
> +}
>  ExprValueKind valueKind = VK_RValue;
>
>  switch (D->getKind()) {
> @@ -13138,6 +13146,19 @@ void Sema::MarkFunctionReferenced(Source
> Func->getMemberSpecializationInfo()))
>  checkSpecializationVisibility(Loc, Func);
>
> +  // C++14 [except.spec]p17:
> +  //   An exception-specification is considered to be needed when:
> +  //   - the function is odr-used or, if it appears in an unevaluated
> operand,
> +  // would be odr-used if the expression were potentially-evaluated;
> +  //
> +  // Note, we do this even if MightBeOdrUse is false. That indicates that
> the
> +  // function is a pure virtual function we're calling, and in that case
> the
> +  // function was selected by overload resolution and we need to resolve
> its
> +  // exception specification for a different reason.
> +  const FunctionProtoType *FPT = Func->getType()->getAs<
> FunctionProtoType>();
> +  if (FPT && isUnresolvedExceptionSpec(FPT->getExceptionSpecType()))
> +ResolveExceptionSpec(Loc, FPT);
> +
>// If we don't need to mark the function as used, and we don't need to
>// try to provide a definition, there's nothing more to do.
>if ((Func->isUsed(/*CheckUsedAttr=*/false) || !OdrUse) &&
> @@ -13196,12 +13217,6 @@ void Sema::MarkFunctionReferenced(Source
>// FIXME: Is this really right?
>if (CurContext == Func) return;
>
> -  // Resolve the exception specification for any function which is
> -  // used: CodeGen will need it.
> -  const FunctionProtoType *FPT = Func->getType()->getAs<
> FunctionProtoType>();
> -  if (FPT && isUnresolvedExceptionSpec(FPT->getExceptionSpecType()))
> -ResolveExceptionSpec(Loc, FPT);
> -
>// Implicit instantiation of function templates and member functions of
>// class templates.
>if (Func->isImplicitlyInstantiable()) {
>
> Modified: cfe/trunk/lib/Sema/SemaOverload.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/
> SemaOverload.cpp?rev=284549=284548=284549=diff
> 
> ==
> --- cfe/trunk/lib/Sema/SemaOverload.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaOverload.cpp Tue Oct 18 18:39:12 2016
> @@ -13166,6 +13166,13 @@ Expr *Sema::FixOverloadedFunctionReferen
> UnOp->getOperatorLoc());
>}
>
> +  // C++ [except.spec]p17:
> +  //   An exception-specification is considered to be needed when:
> +  //   - in an expression the function is the unique lookup result or the
> +  // selected member of a set of overloaded functions
> +  if 

Re: r311443 - [ObjC] Check written attributes only when synthesizing ambiguous property

[Alex L via cfe-commits]

Hi Hans,

Can you please merge this into LLVM 5? It fixes a rather serious
Objective-C bug that I introduced just a couple of weeks before the branch.

Cheers,
Alex

On 22 August 2017 at 11:38, Alex Lorenz via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: arphaman
> Date: Tue Aug 22 03:38:07 2017
> New Revision: 311443
>
> URL: http://llvm.org/viewvc/llvm-project?rev=311443=rev
> Log:
> [ObjC] Check written attributes only when synthesizing ambiguous property
>
> This commit fixes a bug introduced in r307903. The attribute ambiguity
> checker
> that was introduced in r307903 checked all property attributes, which
> caused
> errors for source-compatible properties, like:
>
> @property (nonatomic, readonly) NSObject *prop;
> @property (nonatomic, readwrite) NSObject *prop;
>
> because the readwrite property would get implicit 'strong' attribute. The
> ambiguity checker should be concerned about explicitly specified attributes
> only.
>
> rdar://33748089
>
> Modified:
> cfe/trunk/lib/Sema/SemaObjCProperty.cpp
> cfe/trunk/test/SemaObjC/arc-property-decl-attrs.m
>
> Modified: cfe/trunk/lib/Sema/SemaObjCProperty.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaO
> bjCProperty.cpp?rev=311443=311442=311443=diff
> 
> ==
> --- cfe/trunk/lib/Sema/SemaObjCProperty.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaObjCProperty.cpp Tue Aug 22 03:38:07 2017
> @@ -872,7 +872,7 @@ SelectPropertyForSynthesisFromProtocols(
>}
>
>QualType RHSType = S.Context.getCanonicalType(Property->getType());
> -  unsigned OriginalAttributes = Property->getPropertyAttributes();
> +  unsigned OriginalAttributes = Property->getPropertyAttribute
> sAsWritten();
>enum MismatchKind {
>  IncompatibleType = 0,
>  HasNoExpectedAttribute,
> @@ -890,7 +890,7 @@ SelectPropertyForSynthesisFromProtocols(
>SmallVector Mismatches;
>for (ObjCPropertyDecl *Prop : Properties) {
>  // Verify the property attributes.
> -unsigned Attr = Prop->getPropertyAttributes();
> +unsigned Attr = Prop->getPropertyAttributesAsWritten();
>  if (Attr != OriginalAttributes) {
>auto Diag = [&](bool OriginalHasAttribute, StringRef AttributeName)
> {
>  MismatchKind Kind = OriginalHasAttribute ? HasNoExpectedAttribute
>
> Modified: cfe/trunk/test/SemaObjC/arc-property-decl-attrs.m
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaObjC/
> arc-property-decl-attrs.m?rev=311443=311442=311443=diff
> 
> ==
> --- cfe/trunk/test/SemaObjC/arc-property-decl-attrs.m (original)
> +++ cfe/trunk/test/SemaObjC/arc-property-decl-attrs.m Tue Aug 22 03:38:07
> 2017
> @@ -225,3 +225,30 @@ __attribute__((objc_root_class))
>  @implementation TypeVsSetter
>  @synthesize prop; // expected-note {{property synthesized here}}
>  @end
> +
> +@protocol AutoStrongProp
> +
> +@property (nonatomic, readonly) NSObject *prop;
> +
> +@end
> +
> +@protocol AutoStrongProp_Internal 
> +
> +// This property gets the 'strong' attribute automatically.
> +@property (nonatomic, readwrite) NSObject *prop;
> +
> +@end
> +
> +@interface SynthesizeWithImplicitStrongNoError : NSObject
> 
> +@end
> +
> +@interface SynthesizeWithImplicitStrongNoError ()
> 
> +
> +@end
> +
> +@implementation SynthesizeWithImplicitStrongNoError
> +
> +// no error, 'strong' is implicit in the 'readwrite' property.
> +@synthesize prop = _prop;
> +
> +@end
>
>
> ___
> 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: r310853 - [rename] Introduce symbol occurrences

[Alex L via cfe-commits]

It's an NFC, thus untested.

On 14 August 2017 at 17:19, Alex Lorenz via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: arphaman
> Date: Mon Aug 14 09:19:24 2017
> New Revision: 310853
>
> URL: http://llvm.org/viewvc/llvm-project?rev=310853=rev
> Log:
> [rename] Introduce symbol occurrences
>
> Symbol occurrences store the results of local rename and will also be used
> for
> the global, indexed rename results. Their kind is used to determine
> whether they
> should be renamed automatically or not. They can be converted to a set of
> AtomicChanges as well.
>
> Differential Revision: https://reviews.llvm.org/D36156
>
> Added:
> cfe/trunk/include/clang/Tooling/Refactoring/Rename/SymbolName.h
> cfe/trunk/include/clang/Tooling/Refactoring/Rename/SymbolOccurrences.h
> cfe/trunk/lib/Tooling/Refactoring/Rename/SymbolOccurrences.cpp
> Modified:
> cfe/trunk/include/clang/Tooling/Refactoring/Rename/RenamingAction.h
> cfe/trunk/include/clang/Tooling/Refactoring/Rename/USRLocFinder.h
> cfe/trunk/lib/Tooling/Refactoring/CMakeLists.txt
> cfe/trunk/lib/Tooling/Refactoring/Rename/RenamingAction.cpp
> cfe/trunk/lib/Tooling/Refactoring/Rename/USRLocFinder.cpp
>
> Modified: cfe/trunk/include/clang/Tooling/Refactoring/Rename/
> RenamingAction.h
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/Tooling/Refactoring/Rename/RenamingAction.h?rev=
> 310853=310852=310853=diff
> 
> ==
> --- cfe/trunk/include/clang/Tooling/Refactoring/Rename/RenamingAction.h
> (original)
> +++ cfe/trunk/include/clang/Tooling/Refactoring/Rename/RenamingAction.h
> Mon Aug 14 09:19:24 2017
> @@ -16,6 +16,9 @@
>  #define LLVM_CLANG_TOOLING_REFACTOR_RENAME_RENAMING_ACTION_H
>
>  #include "clang/Tooling/Refactoring.h"
> +#include "clang/Tooling/Refactoring/AtomicChange.h"
> +#include "clang/Tooling/Refactoring/Rename/SymbolOccurrences.h"
> +#include "llvm/Support/Error.h"
>
>  namespace clang {
>  class ASTConsumer;
> @@ -42,6 +45,13 @@ private:
>bool PrintLocations;
>  };
>
> +/// Returns source replacements that correspond to the rename of the given
> +/// symbol occurrences.
> +llvm::Expected
> +createRenameReplacements(const SymbolOccurrences ,
> + const SourceManager ,
> + ArrayRef NewNameStrings);
> +
>  /// Rename all symbols identified by the given USRs.
>  class QualifiedRenamingAction {
>  public:
>
> Added: cfe/trunk/include/clang/Tooling/Refactoring/Rename/SymbolName.h
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/Tooling/Refactoring/Rename/SymbolName.h?rev=310853=auto
> 
> ==
> --- cfe/trunk/include/clang/Tooling/Refactoring/Rename/SymbolName.h
> (added)
> +++ cfe/trunk/include/clang/Tooling/Refactoring/Rename/SymbolName.h Mon
> Aug 14 09:19:24 2017
> @@ -0,0 +1,49 @@
> +//===--- SymbolName.h - Clang refactoring library
> -===//
> +//
> +// The LLVM Compiler Infrastructure
> +//
> +// This file is distributed under the University of Illinois Open Source
> +// License. See LICENSE.TXT for details.
> +//
> +//===--
> ===//
> +
> +#ifndef LLVM_CLANG_TOOLING_REFACTOR_RENAME_SYMBOL_NAME_H
> +#define LLVM_CLANG_TOOLING_REFACTOR_RENAME_SYMBOL_NAME_H
> +
> +#include "clang/Basic/LLVM.h"
> +#include "llvm/ADT/ArrayRef.h"
> +#include "llvm/ADT/SmallVector.h"
> +#include "llvm/ADT/StringRef.h"
> +
> +namespace clang {
> +namespace tooling {
> +
> +/// A name of a symbol.
> +///
> +/// Symbol's name can be composed of multiple strings. For example,
> Objective-C
> +/// methods can contain multiple argument lables:
> +///
> +/// \code
> +/// - (void) myMethodNamePiece: (int)x anotherNamePieces:(int)y;
> +/// //   ^~ string 0 ~ ^~ string 1 ~
> +/// \endcode
> +class SymbolName {
> +public:
> +  SymbolName(StringRef Name) {
> +// While empty symbol names are valid (Objective-C selectors can have
> empty
> +// name pieces), occurrences Objective-C selectors are created using
> an
> +// array of strings instead of just one string.
> +assert(!Name.empty() && "Invalid symbol name!");
> +this->Name.push_back(Name.str());
> +  }
> +
> +  ArrayRef getNamePieces() const { return Name; }
> +
> +private:
> +  llvm::SmallVector Name;
> +};
> +
> +} // end namespace tooling
> +} // end namespace clang
> +
> +#endif // LLVM_CLANG_TOOLING_REFACTOR_RENAME_SYMBOL_NAME_H
>
> Added: cfe/trunk/include/clang/Tooling/Refactoring/Rename/
> SymbolOccurrences.h
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/Tooling/Refactoring/Rename/SymbolOccurrences.h?rev=310853=auto
> 
> ==
> --- 

Re: r310706 - [modules] Set the lexical DC for dummy tag decls that refer to hidden

[Alex L via cfe-commits]

Sure, I committed r310829 which moves the lexical decl adjustment.

Hans, can you please merge r310706 with r310829.

Cheers,
Alex

On 12 August 2017 at 01:29, Richard Smith  wrote:

> On 11 August 2017 at 17:20, Bruno Cardoso Lopes via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Hi Alex,
>>
>> On Fri, Aug 11, 2017 at 9:06 AM, Alex Lorenz via cfe-commits
>>  wrote:
>> > Author: arphaman
>> > Date: Fri Aug 11 05:06:52 2017
>> > New Revision: 310706
>> >
>> > URL: http://llvm.org/viewvc/llvm-project?rev=310706=rev
>> > Log:
>> > [modules] Set the lexical DC for dummy tag decls that refer to hidden
>> > declarations that are made visible after the dummy is parsed and ODR
>> verified
>> >
>> > Prior to this commit the
>> > "(getContainingDC(DC) == CurContext && "The next DeclContext should be
>> lexically contained in the current one."),"
>> > assertion failure was triggered during semantic analysis of the dummy
>> > tag declaration that was declared in another tag declaration because its
>> > lexical context did not point to the outer tag decl.
>> >
>> > rdar://32292196
>> >
>> > Added:
>> > cfe/trunk/test/Modules/Inputs/innerstructredef.h
>> > cfe/trunk/test/Modules/inner-struct-redefines-invisible.m
>> > Modified:
>> > cfe/trunk/lib/Sema/SemaDecl.cpp
>> > cfe/trunk/test/Modules/Inputs/module.map
>> >
>> > Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
>> > URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaD
>> ecl.cpp?rev=310706=310705=310706=diff
>> > 
>> ==
>> > --- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
>> > +++ cfe/trunk/lib/Sema/SemaDecl.cpp Fri Aug 11 05:06:52 2017
>> > @@ -13722,6 +13722,7 @@ Decl *Sema::ActOnTag(Scope *S, unsigned
>> >// comparison.
>> >SkipBody->CheckSameAsPrevious = true;
>> >SkipBody->New = createTagFromNewDecl();
>> > +  SkipBody->New->setLexicalDeclContext(CurContext);
>>
>> I think it would be cleaner to do this inside "createTagFromNewDecl" than
>> here.
>
>
> I agree. Either before or after that change, this seems sufficiently
> isolated and low-risk that it makes sense to take it for Clang 5.
>
>
>> >SkipBody->Previous = Hidden;
>> >  } else {
>> >SkipBody->ShouldSkip = true;
>> >
>> > Added: cfe/trunk/test/Modules/Inputs/innerstructredef.h
>> > URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/
>> Inputs/innerstructredef.h?rev=310706=auto
>> > 
>> ==
>> > --- cfe/trunk/test/Modules/Inputs/innerstructredef.h (added)
>> > +++ cfe/trunk/test/Modules/Inputs/innerstructredef.h Fri Aug 11
>> 05:06:52 2017
>> > @@ -0,0 +1,6 @@
>> > +struct Outer {
>> > +// This definition is actually hidden since only submodule 'one' is
>> imported.
>> > +struct Inner {
>> > +  int x;
>> > +} field;
>> > +};
>> >
>> > Modified: cfe/trunk/test/Modules/Inputs/module.map
>> > URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/
>> Inputs/module.map?rev=310706=310705=310706=diff
>> > 
>> ==
>> > --- cfe/trunk/test/Modules/Inputs/module.map (original)
>> > +++ cfe/trunk/test/Modules/Inputs/module.map Fri Aug 11 05:06:52 2017
>> > @@ -451,3 +451,12 @@ module DebugNestedB {
>> >  module objcAtKeywordMissingEnd {
>> >header "objcAtKeywordMissingEnd.h"
>> >  }
>> > +
>> > +module innerstructredef {
>> > +  module one {
>> > +header "empty.h"
>> > +  }
>> > +  module two {
>> > +   header "innerstructredef.h"
>> > +  }
>> > +}
>> >
>> > Added: cfe/trunk/test/Modules/inner-struct-redefines-invisible.m
>> > URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/
>> inner-struct-redefines-invisible.m?rev=310706=auto
>> > 
>> ==
>> > --- cfe/trunk/test/Modules/inner-struct-redefines-invisible.m (added)
>> > +++ cfe/trunk/test/Modules/inner-struct-redefines-invisible.m Fri Aug
>> 11 05:06:52 2017
>> > @@ -0,0 +1,12 @@
>> > +// RUN: rm -rf %t
>> > +// RUN: %clang_cc1 -fsyntax-only -I%S/Inputs -fmodules
>> -fimplicit-module-maps -fmodules-cache-path=%t -verify %s
>> > +// expected-no-diagnostics
>> > +
>> > +@import innerstructredef.one;
>> > +
>> > +struct Outer {
>> > +// Should set lexical context when parsing 'Inner' here, otherwise
>> there's a crash:
>> > +struct Inner {
>> > +  int x;
>> > +} field;
>> > +};
>> >
>> >
>> > ___
>> > cfe-commits mailing list
>> > cfe-commits@lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>>
>>
>> --
>> Bruno Cardoso Lopes
>> http://www.brunocardoso.cc
>> ___
>> cfe-commits mailing list
>> 

Re: r310706 - [modules] Set the lexical DC for dummy tag decls that refer to hidden

[Alex L via cfe-commits]

Hi Hans & Richard,

Is it possible to get this merged into LLVM 5.0?

Cheers,
Alex

On 11 August 2017 at 13:06, Alex Lorenz via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: arphaman
> Date: Fri Aug 11 05:06:52 2017
> New Revision: 310706
>
> URL: http://llvm.org/viewvc/llvm-project?rev=310706=rev
> Log:
> [modules] Set the lexical DC for dummy tag decls that refer to hidden
> declarations that are made visible after the dummy is parsed and ODR
> verified
>
> Prior to this commit the
> "(getContainingDC(DC) == CurContext && "The next DeclContext should be
> lexically contained in the current one."),"
> assertion failure was triggered during semantic analysis of the dummy
> tag declaration that was declared in another tag declaration because its
> lexical context did not point to the outer tag decl.
>
> rdar://32292196
>
> Added:
> cfe/trunk/test/Modules/Inputs/innerstructredef.h
> cfe/trunk/test/Modules/inner-struct-redefines-invisible.m
> Modified:
> cfe/trunk/lib/Sema/SemaDecl.cpp
> cfe/trunk/test/Modules/Inputs/module.map
>
> Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/
> SemaDecl.cpp?rev=310706=310705=310706=diff
> 
> ==
> --- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaDecl.cpp Fri Aug 11 05:06:52 2017
> @@ -13722,6 +13722,7 @@ Decl *Sema::ActOnTag(Scope *S, unsigned
>// comparison.
>SkipBody->CheckSameAsPrevious = true;
>SkipBody->New = createTagFromNewDecl();
> +  SkipBody->New->setLexicalDeclContext(CurContext);
>SkipBody->Previous = Hidden;
>  } else {
>SkipBody->ShouldSkip = true;
>
> Added: cfe/trunk/test/Modules/Inputs/innerstructredef.h
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/
> innerstructredef.h?rev=310706=auto
> 
> ==
> --- cfe/trunk/test/Modules/Inputs/innerstructredef.h (added)
> +++ cfe/trunk/test/Modules/Inputs/innerstructredef.h Fri Aug 11 05:06:52
> 2017
> @@ -0,0 +1,6 @@
> +struct Outer {
> +// This definition is actually hidden since only submodule 'one' is
> imported.
> +struct Inner {
> +  int x;
> +} field;
> +};
>
> Modified: cfe/trunk/test/Modules/Inputs/module.map
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/
> Modules/Inputs/module.map?rev=310706=310705=310706=diff
> 
> ==
> --- cfe/trunk/test/Modules/Inputs/module.map (original)
> +++ cfe/trunk/test/Modules/Inputs/module.map Fri Aug 11 05:06:52 2017
> @@ -451,3 +451,12 @@ module DebugNestedB {
>  module objcAtKeywordMissingEnd {
>header "objcAtKeywordMissingEnd.h"
>  }
> +
> +module innerstructredef {
> +  module one {
> +header "empty.h"
> +  }
> +  module two {
> +   header "innerstructredef.h"
> +  }
> +}
>
> Added: cfe/trunk/test/Modules/inner-struct-redefines-invisible.m
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/
> Modules/inner-struct-redefines-invisible.m?rev=310706=auto
> 
> ==
> --- cfe/trunk/test/Modules/inner-struct-redefines-invisible.m (added)
> +++ cfe/trunk/test/Modules/inner-struct-redefines-invisible.m Fri Aug 11
> 05:06:52 2017
> @@ -0,0 +1,12 @@
> +// RUN: rm -rf %t
> +// RUN: %clang_cc1 -fsyntax-only -I%S/Inputs -fmodules
> -fimplicit-module-maps -fmodules-cache-path=%t -verify %s
> +// expected-no-diagnostics
> +
> +@import innerstructredef.one;
> +
> +struct Outer {
> +// Should set lexical context when parsing 'Inner' here, otherwise
> there's a crash:
> +struct Inner {
> +  int x;
> +} field;
> +};
>
>
> ___
> 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: r308722 - Fixed failing assert in code completion.

[Alex L via cfe-commits]

Ping?

On 21 July 2017 at 10:44, Alex L  wrote:

> Hans, can you please merge this to the LLVM 5.0 branch?
>
> AFAIK It's a recent regression that should get fixed in LLVM 5.0.
>
> Cheers,
> Alex
>
>
> On 21 July 2017 at 10:24, Ilya Biryukov via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: ibiryukov
>> Date: Fri Jul 21 02:24:00 2017
>> New Revision: 308722
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=308722=rev
>> Log:
>> Fixed failing assert in code completion.
>>
>> Summary:
>> The code was accessing uninstantiated default argument.
>> This resulted in failing assertion at ParmVarDecl::getDefaultArg().
>>
>> Reviewers: erikjv, klimek, bkramer, krasimir
>>
>> Reviewed By: krasimir
>>
>> Subscribers: cfe-commits
>>
>> Differential Revision: https://reviews.llvm.org/D35682
>>
>> Added:
>> cfe/trunk/test/CodeCompletion/uninstantiated_params.cpp
>> Modified:
>> cfe/trunk/lib/Sema/SemaCodeComplete.cpp
>>
>> Modified: cfe/trunk/lib/Sema/SemaCodeComplete.cpp
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaC
>> odeComplete.cpp?rev=308722=308721=308722=diff
>> 
>> ==
>> --- cfe/trunk/lib/Sema/SemaCodeComplete.cpp (original)
>> +++ cfe/trunk/lib/Sema/SemaCodeComplete.cpp Fri Jul 21 02:24:00 2017
>> @@ -2401,10 +2401,7 @@ formatBlockPlaceholder(const PrintingPol
>>  static std::string GetDefaultValueString(const ParmVarDecl *Param,
>>   const SourceManager ,
>>   const LangOptions ) {
>> -  const Expr *defaultArg = Param->getDefaultArg();
>> -  if (!defaultArg)
>> -return "";
>> -  const SourceRange SrcRange = defaultArg->getSourceRange();
>> +  const SourceRange SrcRange = Param->getDefaultArgRange();
>>CharSourceRange CharSrcRange = CharSourceRange::getTokenRange
>> (SrcRange);
>>bool Invalid = CharSrcRange.isInvalid();
>>if (Invalid)
>>
>> Added: cfe/trunk/test/CodeCompletion/uninstantiated_params.cpp
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeCompl
>> etion/uninstantiated_params.cpp?rev=308722=auto
>> 
>> ==
>> --- cfe/trunk/test/CodeCompletion/uninstantiated_params.cpp (added)
>> +++ cfe/trunk/test/CodeCompletion/uninstantiated_params.cpp Fri Jul 21
>> 02:24:00 2017
>> @@ -0,0 +1,13 @@
>> +template 
>> +struct unique_ptr {
>> +  typedef T* pointer;
>> +
>> +  void reset(pointer ptr = pointer());
>> +};
>> +
>> +void test() {
>> +  unique_ptr x;
>> +  x.
>> +  // RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:10:5 %s -o - |
>> FileCheck -check-prefix=CHECK-CC1 %s
>> +  // CHECK-CC1: [#void#]reset({#<#unique_ptr::pointer ptr =
>> pointer()#>#})
>> +}
>>
>>
>> ___
>> 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: r309386 - Recommit r308327 3rd time: Add a warning for missing

[Alex L via cfe-commits]

Add a note with a fixit in r309559.

On 31 July 2017 at 10:50, Alex L  wrote:

> That's an interesting case. I'll tweak the warning to diagnose this
> scenario better today.
>
> On 29 July 2017 at 00:56, Hans Wennborg  wrote:
>
>> On Fri, Jul 28, 2017 at 7:41 AM, Alex Lorenz via cfe-commits
>>  wrote:
>> > Author: arphaman
>> > Date: Fri Jul 28 07:41:21 2017
>> > New Revision: 309386
>> >
>> > URL: http://llvm.org/viewvc/llvm-project?rev=309386=rev
>> > Log:
>> > Recommit r308327 3rd time: Add a warning for missing
>> > '#pragma pack (pop)' and suspicious uses of '#pragma pack' in included
>> files
>> >
>> > The second recommit (r309106) was reverted because the "non-default
>> #pragma
>> > pack value chages the alignment of struct or union members in the
>> included file"
>> > warning proved to be too aggressive for external projects like Chromium
>> > (https://bugs.chromium.org/p/chromium/issues/detail?id=749197). This
>> recommit
>> > makes the problematic warning a non-default one, and gives it the
>> > -Wpragma-pack-suspicious-include warning option.
>> >
>> > The first recommit (r308441) caused a "non-default #pragma pack value
>> might
>> > change the alignment of struct or union members in the included file"
>> warning
>> > in LLVM itself. This recommit tweaks the added warning to avoid
>> warnings for
>> > #includes that don't have any records that are affected by the
>> non-default
>> > alignment. This tweak avoids the previously emitted warning in LLVM.
>> >
>> > Original message:
>> >
>> > This commit adds a new -Wpragma-pack warning. It warns in the following
>> cases:
>> >
>> > - When a translation unit is missing terminating #pragma pack (pop)
>> directives.
>> > - When entering an included file if the current alignment value as
>> determined
>> >   by '#pragma pack' directives is different from the default alignment
>> value.
>> > - When leaving an included file that changed the state of the current
>> alignment
>> >   value.
>> >
>> > rdar://10184173
>> >
>> > Differential Revision: https://reviews.llvm.org/D35484
>>
>> We did get warnings with this version too, but this time it looks like
>> a real bug :-)
>>
>> C:\b\c\builder\ClangToTWin_dll_\src\third_party\usrsctp\usrs
>> ctplib\usrsctplib\netinet\sctp.h(51,9):
>>  error: unterminated '#pragma pack (push, ...)' at end of file
>> [-Werror,-Wpragma-pack]
>>
>> The interesting thing is that the file does reset the alignment, but
>> it does it with a "#pragma pack()" which doesn't pop the stack, but
>> just resets to the default value.
>>
>> It might be worth tweaking the warning to give a better message for
>> this. A "#pragma pack(push, ..)" followed by "#pragma pack()" seems
>> pretty dodgy since there's no point in pushing if the code isn't going
>> to pop.
>>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r309386 - Recommit r308327 3rd time: Add a warning for missing

[Alex L via cfe-commits]

That's an interesting case. I'll tweak the warning to diagnose this
scenario better today.

On 29 July 2017 at 00:56, Hans Wennborg  wrote:

> On Fri, Jul 28, 2017 at 7:41 AM, Alex Lorenz via cfe-commits
>  wrote:
> > Author: arphaman
> > Date: Fri Jul 28 07:41:21 2017
> > New Revision: 309386
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=309386=rev
> > Log:
> > Recommit r308327 3rd time: Add a warning for missing
> > '#pragma pack (pop)' and suspicious uses of '#pragma pack' in included
> files
> >
> > The second recommit (r309106) was reverted because the "non-default
> #pragma
> > pack value chages the alignment of struct or union members in the
> included file"
> > warning proved to be too aggressive for external projects like Chromium
> > (https://bugs.chromium.org/p/chromium/issues/detail?id=749197). This
> recommit
> > makes the problematic warning a non-default one, and gives it the
> > -Wpragma-pack-suspicious-include warning option.
> >
> > The first recommit (r308441) caused a "non-default #pragma pack value
> might
> > change the alignment of struct or union members in the included file"
> warning
> > in LLVM itself. This recommit tweaks the added warning to avoid warnings
> for
> > #includes that don't have any records that are affected by the
> non-default
> > alignment. This tweak avoids the previously emitted warning in LLVM.
> >
> > Original message:
> >
> > This commit adds a new -Wpragma-pack warning. It warns in the following
> cases:
> >
> > - When a translation unit is missing terminating #pragma pack (pop)
> directives.
> > - When entering an included file if the current alignment value as
> determined
> >   by '#pragma pack' directives is different from the default alignment
> value.
> > - When leaving an included file that changed the state of the current
> alignment
> >   value.
> >
> > rdar://10184173
> >
> > Differential Revision: https://reviews.llvm.org/D35484
>
> We did get warnings with this version too, but this time it looks like
> a real bug :-)
>
> C:\b\c\builder\ClangToTWin_dll_\src\third_party\usrsctp\
> usrsctplib\usrsctplib\netinet\sctp.h(51,9):
>  error: unterminated '#pragma pack (push, ...)' at end of file
> [-Werror,-Wpragma-pack]
>
> The interesting thing is that the file does reset the alignment, but
> it does it with a "#pragma pack()" which doesn't pop the stack, but
> just resets to the default value.
>
> It might be worth tweaking the warning to give a better message for
> this. A "#pragma pack(push, ..)" followed by "#pragma pack()" seems
> pretty dodgy since there's no point in pushing if the code isn't going
> to pop.
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r309106 - Recommit r308327 2nd time: Add a warning for missing

[Alex L via cfe-commits]

Thanks, I recommitted it in r309386.

On 27 July 2017 at 15:53, Hans Wennborg  wrote:

> On Thu, Jul 27, 2017 at 3:41 AM, Alex L  wrote:
> >
> >
> > On 26 July 2017 at 22:32, Hans Wennborg  wrote:
> >>
> >> On Wed, Jul 26, 2017 at 11:27 AM, Hans Wennborg 
> wrote:
> >> > On Wed, Jul 26, 2017 at 5:20 AM, Alex Lorenz via cfe-commits
> >> >  wrote:
> >> >> Author: arphaman
> >> >> Date: Wed Jul 26 05:20:57 2017
> >> >> New Revision: 309106
> >> >>
> >> >> URL: http://llvm.org/viewvc/llvm-project?rev=309106=rev
> >> >> Log:
> >> >> Recommit r308327 2nd time: Add a warning for missing
> >> >> '#pragma pack (pop)' and suspicious uses of '#pragma pack' in
> included
> >> >> files
> >> >>
> >> >> The first recommit (r308441) caused a "non-default #pragma pack value
> >> >> might
> >> >> change the alignment of struct or union members in the included file"
> >> >> warning
> >> >> in LLVM itself. This recommit tweaks the added warning to avoid
> >> >> warnings for
> >> >> #includes that don't have any records that are affected by the
> >> >> non-default
> >> >> alignment. This tweak avoids the previously emitted warning in LLVM.
> >> >>
> >> >> Original message:
> >> >>
> >> >> This commit adds a new -Wpragma-pack warning. It warns in the
> following
> >> >> cases:
> >> >>
> >> >> - When a translation unit is missing terminating #pragma pack (pop)
> >> >> directives.
> >> >> - When entering an included file if the current alignment value as
> >> >> determined
> >> >>   by '#pragma pack' directives is different from the default
> alignment
> >> >> value.
> >> >> - When leaving an included file that changed the state of the current
> >> >> alignment
> >> >>   value.
> >> >>
> >> >> rdar://10184173
> >> >>
> >> >> Differential Revision: https://reviews.llvm.org/D35484
> >> >
> >> > We have code in Chromium that does exactly this:
> >> >
> >> > gles2_cmd_format.h does #pragma pack(push, 4) and then #includes a
> >> > file with some generated structs, with the intention that the pragma
> >> > applies to them.
> >> >
> >> > What's the best way to pacify the warning in this case?
> >> >
> >> > (We're tracking this in
> >> > https://bugs.chromium.org/p/chromium/issues/detail?id=749197)
> >>
> >> I agree that cases 1) and 3) from your patch description make sense to
> >> warn for, but I'm not sure that's the case for 2). Do you have
> >> examples where this catches any bugs? In our case #pragma packing an
> >> included file is intentional, and I suspect it might be a bit of a
> >> pattern.
> >
> >
> > I see, thanks for your input.
> >
> > 2) is generally designed for times when #pragma pack pop was accidentally
> > used too late (after some #includes that unintentionally receive the
> > alignment). I can see how some projects use this pattern heavily, and I
> > don't think there's a good way to pacify this warning in that case.
> >
> > I think that for us it would be reasonable to turn 2) off by default, and
> > allow users to enable it explicitly using a stronger flag (something like
> > -Wpragma-pack-suspicious-include?). I think that I will leave 2) out of
> this
> > commit, recommit it without 2) and then commit 2) as a non-default
> warning
> > that uses a separate flag.
>
> That sounds reasonable. You can probably still do it with the same
> commit, just moving 2) behind a separate flag.
>
> Thanks,
> Hans
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r309106 - Recommit r308327 2nd time: Add a warning for missing

[Alex L via cfe-commits]

On 26 July 2017 at 22:32, Hans Wennborg  wrote:

> On Wed, Jul 26, 2017 at 11:27 AM, Hans Wennborg  wrote:
> > On Wed, Jul 26, 2017 at 5:20 AM, Alex Lorenz via cfe-commits
> >  wrote:
> >> Author: arphaman
> >> Date: Wed Jul 26 05:20:57 2017
> >> New Revision: 309106
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=309106=rev
> >> Log:
> >> Recommit r308327 2nd time: Add a warning for missing
> >> '#pragma pack (pop)' and suspicious uses of '#pragma pack' in included
> files
> >>
> >> The first recommit (r308441) caused a "non-default #pragma pack value
> might
> >> change the alignment of struct or union members in the included file"
> warning
> >> in LLVM itself. This recommit tweaks the added warning to avoid
> warnings for
> >> #includes that don't have any records that are affected by the
> non-default
> >> alignment. This tweak avoids the previously emitted warning in LLVM.
> >>
> >> Original message:
> >>
> >> This commit adds a new -Wpragma-pack warning. It warns in the following
> cases:
> >>
> >> - When a translation unit is missing terminating #pragma pack (pop)
> directives.
> >> - When entering an included file if the current alignment value as
> determined
> >>   by '#pragma pack' directives is different from the default alignment
> value.
> >> - When leaving an included file that changed the state of the current
> alignment
> >>   value.
> >>
> >> rdar://10184173
> >>
> >> Differential Revision: https://reviews.llvm.org/D35484
> >
> > We have code in Chromium that does exactly this:
> >
> > gles2_cmd_format.h does #pragma pack(push, 4) and then #includes a
> > file with some generated structs, with the intention that the pragma
> > applies to them.
> >
> > What's the best way to pacify the warning in this case?
> >
> > (We're tracking this in
> > https://bugs.chromium.org/p/chromium/issues/detail?id=749197)
>
> I agree that cases 1) and 3) from your patch description make sense to
> warn for, but I'm not sure that's the case for 2). Do you have
> examples where this catches any bugs? In our case #pragma packing an
> included file is intentional, and I suspect it might be a bit of a
> pattern.
>

I see, thanks for your input.

2) is generally designed for times when #pragma pack pop was accidentally
used too late (after some #includes that unintentionally receive the
alignment). I can see how some projects use this pattern heavily, and I
don't think there's a good way to pacify this warning in that case.

I think that for us it would be reasonable to turn 2) off by default, and
allow users to enable it explicitly using a stronger flag (something like
-Wpragma-pack-suspicious-include?). I think that I will leave 2) out of
this commit, recommit it without 2) and then commit 2) as a non-default
warning that uses a separate flag.


> Wouldn't cases 1) and 3) catch most situations where this happens
> unintentionally? E.g. when one #includes a file that forgets to
> #pragma pop, and then includes a new file afterwards?
>
> I've reverted in r309186 in the meantime.
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r308722 - Fixed failing assert in code completion.

[Alex L via cfe-commits]

Hans, can you please merge this to the LLVM 5.0 branch?

AFAIK It's a recent regression that should get fixed in LLVM 5.0.

Cheers,
Alex

On 21 July 2017 at 10:24, Ilya Biryukov via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: ibiryukov
> Date: Fri Jul 21 02:24:00 2017
> New Revision: 308722
>
> URL: http://llvm.org/viewvc/llvm-project?rev=308722=rev
> Log:
> Fixed failing assert in code completion.
>
> Summary:
> The code was accessing uninstantiated default argument.
> This resulted in failing assertion at ParmVarDecl::getDefaultArg().
>
> Reviewers: erikjv, klimek, bkramer, krasimir
>
> Reviewed By: krasimir
>
> Subscribers: cfe-commits
>
> Differential Revision: https://reviews.llvm.org/D35682
>
> Added:
> cfe/trunk/test/CodeCompletion/uninstantiated_params.cpp
> Modified:
> cfe/trunk/lib/Sema/SemaCodeComplete.cpp
>
> Modified: cfe/trunk/lib/Sema/SemaCodeComplete.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaC
> odeComplete.cpp?rev=308722=308721=308722=diff
> 
> ==
> --- cfe/trunk/lib/Sema/SemaCodeComplete.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaCodeComplete.cpp Fri Jul 21 02:24:00 2017
> @@ -2401,10 +2401,7 @@ formatBlockPlaceholder(const PrintingPol
>  static std::string GetDefaultValueString(const ParmVarDecl *Param,
>   const SourceManager ,
>   const LangOptions ) {
> -  const Expr *defaultArg = Param->getDefaultArg();
> -  if (!defaultArg)
> -return "";
> -  const SourceRange SrcRange = defaultArg->getSourceRange();
> +  const SourceRange SrcRange = Param->getDefaultArgRange();
>CharSourceRange CharSrcRange = CharSourceRange::getTokenRange
> (SrcRange);
>bool Invalid = CharSrcRange.isInvalid();
>if (Invalid)
>
> Added: cfe/trunk/test/CodeCompletion/uninstantiated_params.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeCompl
> etion/uninstantiated_params.cpp?rev=308722=auto
> 
> ==
> --- cfe/trunk/test/CodeCompletion/uninstantiated_params.cpp (added)
> +++ cfe/trunk/test/CodeCompletion/uninstantiated_params.cpp Fri Jul 21
> 02:24:00 2017
> @@ -0,0 +1,13 @@
> +template 
> +struct unique_ptr {
> +  typedef T* pointer;
> +
> +  void reset(pointer ptr = pointer());
> +};
> +
> +void test() {
> +  unique_ptr x;
> +  x.
> +  // RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:10:5 %s -o - |
> FileCheck -check-prefix=CHECK-CC1 %s
> +  // CHECK-CC1: [#void#]reset({#<#unique_ptr::pointer ptr =
> pointer()#>#})
> +}
>
>
> ___
> 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: r308441 - Recommit r308327: Add a warning for missing '#pragma pack (pop)'

[Alex L via cfe-commits]

Thanks, I'll take a look.

On 19 July 2017 at 13:31, Hans Wennborg  wrote:

> On Wed, Jul 19, 2017 at 2:26 PM, Hans Wennborg  wrote:
> > On Wed, Jul 19, 2017 at 1:30 PM, Alex Lorenz via cfe-commits
> >  wrote:
> >> Author: arphaman
> >> Date: Wed Jul 19 04:30:41 2017
> >> New Revision: 308441
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=308441=rev
> >> Log:
> >> Recommit r308327: Add a warning for missing '#pragma pack (pop)'
> >> and suspicious uses of '#pragma pack' in included files
> >>
> >> This commit adds a new -Wpragma-pack warning. It warns in the following
> cases:
> >>
> >> - When a translation unit is missing terminating #pragma pack (pop)
> directives.
> >> - When entering an included file if the current alignment value as
> determined
> >>   by '#pragma pack' directives is different from the default alignment
> value.
> >> - When leaving an included file that changed the state of the current
> alignment
> >>   value.
> >>
> >> rdar://10184173
> >>
> >> Differential Revision: https://reviews.llvm.org/D35484
> >
> > This buildbot is unhappy:
> > http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/2963
> >
> > From the build log:
> >
> > [ 67%] Building CXX object
> > lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o
> > In file included from
> > /mnt/b/sanitizer-buildbot1/sanitizer-x86_64-linux/build/
> llvm/lib/ProfileData/Coverage/CoverageMappingWriter.cpp:15:
> > In file included from
> > /mnt/b/sanitizer-buildbot1/sanitizer-x86_64-linux/build/
> llvm/include/llvm/ProfileData/Coverage/CoverageMappingWriter.h:20:
> > /mnt/b/sanitizer-buildbot1/sanitizer-x86_64-linux/build/
> llvm/include/llvm/ProfileData/Coverage/CoverageMapping.h:517:10:
> > error: non-default #pragma pack value might change the alignment of
> > struct or union members in the included file [-Werror,-Wpragma-pack]
> > #include "llvm/ProfileData/InstrProfData.inc"
> >  ^
> > /mnt/b/sanitizer-buildbot1/sanitizer-x86_64-linux/build/
> llvm/include/llvm/ProfileData/Coverage/CoverageMapping.h:513:1:
> > note: previous '#pragma pack' directive that modifies alignment is
> > here
> > LLVM_PACKED_START
> > ^
> > /mnt/b/sanitizer-buildbot1/sanitizer-x86_64-linux/build/
> llvm/include/llvm/Support/Compiler.h:349:28:
> > note: expanded from macro 'LLVM_PACKED_START'
> > # define LLVM_PACKED_START _Pragma("pack(push, 1)")
> >^
> > :14:2: note: expanded from here
> >  pack(push, 1)
> >  ^
>
> I've reverted in r308455 in the meantime.
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r306844 - Attempt to fix the linkage error caused by r306840 on the mingw-RA-on-linux bot

[Alex L via cfe-commits]

It worked!

On 30 June 2017 at 18:15, Alex Lorenz via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: arphaman
> Date: Fri Jun 30 10:15:48 2017
> New Revision: 306844
>
> URL: http://llvm.org/viewvc/llvm-project?rev=306844=rev
> Log:
> Attempt to fix the linkage error caused by r306840 on the
> mingw-RA-on-linux bot
>
> Modified:
> cfe/trunk/tools/clang-rename/CMakeLists.txt
>
> Modified: cfe/trunk/tools/clang-rename/CMakeLists.txt
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-
> rename/CMakeLists.txt?rev=306844=306843=306844=diff
> 
> ==
> --- cfe/trunk/tools/clang-rename/CMakeLists.txt (original)
> +++ cfe/trunk/tools/clang-rename/CMakeLists.txt Fri Jun 30 10:15:48 2017
> @@ -1,3 +1,8 @@
> +set(LLVM_LINK_COMPONENTS
> +  Option
> +  Support
> +  )
> +
>  add_clang_executable(clang-rename ClangRename.cpp)
>
>  target_link_libraries(clang-rename
>
>
> ___
> 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: r305719 - [Parser][ObjC] Use an artificial EOF token while parsing lexed ObjC methods

[Alex L via cfe-commits]

On 20 June 2017 at 16:53, Duncan P. N. Exon Smith 
wrote:

>
> On Jun 19, 2017, at 10:53, Alex Lorenz via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
> Author: arphaman
> Date: Mon Jun 19 12:53:21 2017
> New Revision: 305719
>
> URL: http://llvm.org/viewvc/llvm-project?rev=305719=rev
> Log:
> [Parser][ObjC] Use an artificial EOF token while parsing lexed ObjC methods
>
> This change avoid a crash that occurred when skipping to EOF while parsing
> an
> ObjC interface/implementation.
>
> rdar://31963299
>
> Differential Revision: https://reviews.llvm.org/D34185
>
> Added:
>cfe/trunk/test/Parser/objc-at-implementation-eof-crash.m
>cfe/trunk/test/Parser/objc-at-interface-eof-crash.m
> Modified:
>cfe/trunk/lib/Parse/ParseObjc.cpp
>
> Modified: cfe/trunk/lib/Parse/ParseObjc.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/
> ParseObjc.cpp?rev=305719=305718=305719=diff
> 
> ==
> --- cfe/trunk/lib/Parse/ParseObjc.cpp (original)
> +++ cfe/trunk/lib/Parse/ParseObjc.cpp Mon Jun 19 12:53:21 2017
> @@ -3627,6 +3627,14 @@ void Parser::ParseLexedObjCMethodDefs(Le
>   SourceLocation OrigLoc = Tok.getLocation();
>
>   assert(!LM.Toks.empty() && "ParseLexedObjCMethodDef - Empty body!");
> +  // Store an artificial EOF token to ensure that we don't run off the
> end of
> +  // the method's body when we come to parse it.
> +  Token Eof;
> +  Eof.startToken();
> +  Eof.setKind(tok::eof);
> +  Eof.setEofData(MCDecl);
> +  Eof.setLocation(OrigLoc);
> +  LM.Toks.push_back(Eof);
>   // Append the current token at the end of the new token stream so that it
>   // doesn't get lost.
>   LM.Toks.push_back(Tok);
> @@ -3658,7 +3666,7 @@ void Parser::ParseLexedObjCMethodDefs(Le
>   Actions.ActOnDefaultCtorInitializers(MCDecl);
> ParseFunctionStatementBody(MCDecl, BodyScope);
>   }
> -
> +
>   if (Tok.getLocation() != OrigLoc) {
> // Due to parsing error, we either went over the cached tokens or
> // there are still cached tokens left. If it's the latter case skip the
> @@ -3670,4 +3678,6 @@ void Parser::ParseLexedObjCMethodDefs(Le
>   while (Tok.getLocation() != OrigLoc && Tok.isNot(tok::eof))
> ConsumeAnyToken();
>   }
> +  // Clean up the remaining EOF token.
> +  ConsumeAnyToken();
> }
>
> Added: cfe/trunk/test/Parser/objc-at-implementation-eof-crash.m
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Parser/
> objc-at-implementation-eof-crash.m?rev=305719=auto
> 
> ==
> --- cfe/trunk/test/Parser/objc-at-implementation-eof-crash.m (added)
> +++ cfe/trunk/test/Parser/objc-at-implementation-eof-crash.m Mon Jun 19
> 12:53:21 2017
> @@ -0,0 +1,21 @@
> +// RUN: %clang_cc1 -verify -Wno-objc-root-class %s
> +
> +@interface ClassA
> +
> +- (void)fileExistsAtPath:(int)x;
> +
> +@end
> +
> +@interface ClassB
> +
> +@end
> +
> +@implementation ClassB // expected-note {{implementation started here}}
> +
> +- (void) method:(ClassA *)mgr { // expected-note {{to match this '{'}}
> +  mgr fileExistsAtPath:0
> +} // expected-error {{expected ']'}}
> +
> +@implementation ClassC // expected-error {{missing '@end'}} //
> expected-error {{expected '}'}} // expected-warning {{cannot find interface
> declaration for 'ClassC'}}
>
>
> I believe you can split these expectations over multiple lines.  Something
> like this seems more readable:
>
> @implementation ClassC \
>   // expected-error {{missing '@end'}} \
>   // expected-error {{expected '}'}}   \
>   // expected-warning {{cannot find interface declaration for 'ClassC'}}
>
>
Thanks, addressed in r305803!


>
> +
> +@end
>
> Added: cfe/trunk/test/Parser/objc-at-interface-eof-crash.m
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Parser/
> objc-at-interface-eof-crash.m?rev=305719=auto
> 
> ==
> --- cfe/trunk/test/Parser/objc-at-interface-eof-crash.m (added)
> +++ cfe/trunk/test/Parser/objc-at-interface-eof-crash.m Mon Jun 19
> 12:53:21 2017
> @@ -0,0 +1,21 @@
> +// RUN: %clang_cc1 -verify -Wno-objc-root-class %s
> +
> +@interface ClassA
> +
> +- (void)fileExistsAtPath:(int)x;
> +
> +@end
> +
> +@interface ClassB
> +
> +@end
> +
> +@implementation ClassB // expected-note {{implementation started here}}
> +
> +- (void) method:(ClassA *)mgr { // expected-note {{to match this '{'}}
> +  mgr fileExistsAtPath:0
> +} // expected-error {{expected ']'}}
> +
> +@interface ClassC // expected-error {{missing '@end'}} // expected-error
> {{expected '}'}}
>
>
> Same recommendation as above.
>
> +
> +@end
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
>
___
cfe-commits mailing list

Re: r302677 - [libclang] Introduce clang_Cursor_isExternalSymbol that provides info about decls marked with external_source_symbol attribute

[Alex L via cfe-commits]

On 10 May 2017 at 16:10, Argyrios Kyrtzidis via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: akirtzidis
> Date: Wed May 10 10:10:36 2017
> New Revision: 302677
>
> URL: http://llvm.org/viewvc/llvm-project?rev=302677=rev
> Log:
> [libclang] Introduce clang_Cursor_isExternalSymbol that provides info
> about decls marked with external_source_symbol attribute
>
> Modified:
> cfe/trunk/include/clang-c/Index.h
> cfe/trunk/test/Index/get-cursor.m
> cfe/trunk/tools/c-index-test/c-index-test.c
> cfe/trunk/tools/libclang/CIndex.cpp
> cfe/trunk/tools/libclang/libclang.exports
>
> Modified: cfe/trunk/include/clang-c/Index.h
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang-c/Index.h?rev=302677=302676=302677=diff
> 
> ==
> --- cfe/trunk/include/clang-c/Index.h (original)
> +++ cfe/trunk/include/clang-c/Index.h Wed May 10 10:10:36 2017
> @@ -32,7 +32,7 @@
>   * compatible, thus CINDEX_VERSION_MAJOR is expected to remain stable.
>   */
>  #define CINDEX_VERSION_MAJOR 0
> -#define CINDEX_VERSION_MINOR 38
> +#define CINDEX_VERSION_MINOR 39
>
>  #define CINDEX_VERSION_ENCODE(major, minor) ( \
>((major) * 1)   \
> @@ -4081,6 +4081,23 @@ CINDEX_LINKAGE unsigned clang_Cursor_isO
>  CINDEX_LINKAGE unsigned clang_Cursor_isVariadic(CXCursor C);
>
>  /**
> + * \brief Returns non-zero if the given cursor points to a symbol marked
> with
> + * external_source_symbol attribute.
> + *
> + * \param language If non-NULL, and the attribute is present, will be set
> to
> + * the 'language' string from the attribute.
> + *
> + * \param definedIn If non-NULL, and the attribute is present, will be
> set to
> + * the 'definedIn' string from the attribute.
> + *
> + * \param isGenerated If non-NULL, and the attribute is present, will be
> set to
> + * non-zero is the 'generated_declaration' is set in the attribute.
> + */
> +CINDEX_LINKAGE unsigned clang_Cursor_isExternalSymbol(CXCursor C,
> +   CXString *language, CXString
> *definedIn,
> +   unsigned *isGenerated);
> +
> +/**
>   * \brief Given a cursor that represents a declaration, return the
> associated
>   * comment's source range.  The range may include multiple consecutive
> comments
>   * with whitespace in between.
>
> Modified: cfe/trunk/test/Index/get-cursor.m
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Index/
> get-cursor.m?rev=302677=302676=302677=diff
> 
> ==
> --- cfe/trunk/test/Index/get-cursor.m (original)
> +++ cfe/trunk/test/Index/get-cursor.m Wed May 10 10:10:36 2017
> @@ -154,6 +154,12 @@ SomeT someVar;
>  typedef MY_TYPE2(SomeT2) { int x; };
>  SomeT2 someVar2;
>
> +#define GEN_DECL(mod_name) __attribute__((external_
> source_symbol(language="Swift", defined_in=mod_name,
> generated_declaration)))
> +
> +GEN_DECL("some_module")
> +@interface ExtCls
> +-(void)method;
> +@end
>
>  // RUN: c-index-test -cursor-at=%s:4:28 -cursor-at=%s:5:28 %s | FileCheck
> -check-prefix=CHECK-PROP %s
>  // CHECK-PROP: ObjCPropertyDecl=foo1:4:26
> @@ -226,3 +232,8 @@ SomeT2 someVar2;
>  // CHECK-TRANSPARENT: 147:1 TypeRef=TokenPaste_t:144:9 Extent=[147:1 -
> 147:13] Spelling=TokenPaste_t ([147:1 - 147:13])
>  // CHECK-TRANSPARENT: 151:1 TypeRef=SomeT:150:17 (Transparent: struct
> SomeT) Extent=[151:1 - 151:6] Spelling=SomeT ([151:1 - 151:6])
>  // CHECK-TRANSPARENT: 155:1 TypeRef=SomeT2:154:18 Extent=[155:1 - 155:7]
> Spelling=SomeT2 ([155:1 - 155:7])
> +
> +// RUN: c-index-test -cursor-at=%s:160:12 -cursor-at=%s:161:8 %s |
> FileCheck -check-prefix=CHECK-EXTERNAL %s
> +// CHECK-EXTERNAL: 160:12 ObjCInterfaceDecl=ExtCls:160:12 (external
> lang: Swift, defined: some_module, gen: 1)
> +// CHECK-EXTERNAL: 161:8 ObjCInstanceMethodDecl=method:161:8 (external
> lang: Swift, defined: some_module, gen: 1)
> +C
> \ No newline at end of file
>
> Modified: cfe/trunk/tools/c-index-test/c-index-test.c
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/c-
> index-test/c-index-test.c?rev=302677=302676=302677=diff
> 
> ==
> --- cfe/trunk/tools/c-index-test/c-index-test.c (original)
> +++ cfe/trunk/tools/c-index-test/c-index-test.c Wed May 10 10:10:36 2017
> @@ -809,6 +809,19 @@ static void PrintCursor(CXCursor Cursor,
>  if (clang_Cursor_isObjCOptional(Cursor))
>printf(" (@optional)");
>
> +{
> +  CXString language;
> +  CXString definedIn;
> +  unsigned generated;
> +  if (clang_Cursor_isExternalSymbol(Cursor, , ,
> +)) {
> +printf(" (external lang: %s, defined: %s, gen: %d)",
> +clang_getCString(language), clang_getCString(definedIn),
> generated);
> +clang_disposeString(language);
> +

Re: r301992 - [modules] Round-trip -Werror flag through explicit module build.

[Alex L via cfe-commits]

On 4 May 2017 at 12:52, Alex L  wrote:

>
>
> On 4 May 2017 at 12:43, Alex L  wrote:
>
>>
>>
>> On 3 May 2017 at 22:23, Richard Smith  wrote:
>>
>>> On 3 May 2017 at 07:29, Alex L  wrote:
>>>
 Hi Richard,

 This commit has caused an infinite loop in one of our internal libclang
 based tooling tests. It keeps repeating the following frames:

 frame #33528: 0x000109db2edf libclang.dylib`clang::Diagnost
 icsEngine::ReportDelayed(this=0x00011c002c00) at Diagnostic.cpp:149
 frame #33529: 0x000109db5a36 libclang.dylib`clang::Diagnost
 icsEngine::EmitCurrentDiagnostic(this=0x00011c002c00, Force=false)
 at Diagnostic.cpp:428
 frame #33530: 0x00010a33f93c libclang.dylib`clang::Diagnost
 icBuilder::Emit(this=0x78d4bfd8) at Diagnostic.h:1013
 frame #33531: 0x00010a33f8e5 libclang.dylib`clang::Diagnost
 icBuilder::~DiagnosticBuilder(this=0x78d4bfd8) at
 Diagnostic.h:1036
 frame #33532: 0x00010a335015 libclang.dylib`clang::Diagnost
 icBuilder::~DiagnosticBuilder(this=0x78d4bfd8) at
 Diagnostic.h:1035

 It doesn't really look like a regression though, it seems that this has
 just uncovered a bug in Clang: DiagnosticsEngine::ReportDelayed is
 clearing DelayedDiagID *after* reporting the issue which causes the
 infinite recursion, when it should clear it before. Is that right?

>>>
>>> EmitCurrentDiagnostic checks "DelayedDiagID != DiagID" before making the
>>> recursive call, which should be preventing the infinite recursion.
>>>
>>> It looks like the immediate bug is that EmitCurrentDiagnostic grabs
>>> CurDiagID *after* calling EmitDiag / ProcessDiag, which clear CurDiagID
>>> when they succeed in emitting the diagnostic. But I agree, the right thing
>>> to do is clear DelayedDiagID before emitting the delayed diagnostic, not
>>> after. You should also be able to delete the incorrect recursion check in
>>> EmitCurrentDiagnostic too.
>>>
>>
>> Thanks, that makes sense.
>>
>> Unfortunately I had to revert my fix as it uncovered two issues in
>> Misc/error-limit-multiple-notes.cpp and Misc/error-limit.c . It looks
>> like your commit caused the infinite recursion in both of them, but the
>> bots didn't catch that because they invoked not clang, and emitted the
>> diagnostics that were checked (using FileCheck) before crashing, so they
>> "passed". However, my fix causes the tests to fail, seemingly because now
>> Clang doesn't suppress multiple notes after reaching the error limit (it
>> suppresses just the first note). It looks like this is a regression
>> introduced in this commit.
>>
>> Sorry, I was wrong in my analysis. It's not a regression introduced by
> your commit, it's just a problem with my fix.
>

I figured out what was wrong, turns out there was another subtle bug -
Clang was actually reporting `fatal_too_many_errors` twice (recursively),
and the second invocation set `FatalErrorOccurred`, and thus prevented the
notes from the diagnostic that caused `fatal_too_many_errors` to get
emitted. But my fix fixed that subtle bug as well, so I had to explicitly
set `FatalErrorOccurred` when reporting `fatal_too_many_errors`. It should
be fixed now in r302151.


>
>
>>
>>
>>>
>>>
 I will commit a fix for this now.

>>>
>>> Thank you!
>>>
>>>
 Alex


 On 3 May 2017 at 01:28, Richard Smith via cfe-commits <
 cfe-commits@lists.llvm.org> wrote:

> Author: rsmith
> Date: Tue May  2 19:28:49 2017
> New Revision: 301992
>
> URL: http://llvm.org/viewvc/llvm-project?rev=301992=rev
> Log:
> [modules] Round-trip -Werror flag through explicit module build.
>
> The intent for an explicit module build is that the diagnostics
> produced within
> the module are those that were configured when the module was built,
> not those
> that are enabled within a user of the module. This includes
> diagnostics that
> don't actually show up until the module is used (for instance,
> diagnostics
> produced during template instantiation and weird cases like -Wpadded).
>
> We serialized and restored the diagnostic state for individual warning
> groups,
> but previously did not track the state for flags like -Werror and
> -Weverything,
> which are implemented as separate bits rather than as part of the
> diagnostics
> mapping information.
>
> Modified:
> cfe/trunk/include/clang/Basic/Diagnostic.h
> cfe/trunk/include/clang/Basic/DiagnosticIDs.h
> cfe/trunk/lib/Basic/Diagnostic.cpp
> cfe/trunk/lib/Basic/DiagnosticIDs.cpp
> cfe/trunk/lib/Serialization/ASTReader.cpp
> cfe/trunk/lib/Serialization/ASTWriter.cpp
> cfe/trunk/test/Index/keep-going.cpp
> cfe/trunk/test/Modules/diag-flags.cpp
> 

Re: r301992 - [modules] Round-trip -Werror flag through explicit module build.

[Alex L via cfe-commits]

On 4 May 2017 at 12:43, Alex L  wrote:

>
>
> On 3 May 2017 at 22:23, Richard Smith  wrote:
>
>> On 3 May 2017 at 07:29, Alex L  wrote:
>>
>>> Hi Richard,
>>>
>>> This commit has caused an infinite loop in one of our internal libclang
>>> based tooling tests. It keeps repeating the following frames:
>>>
>>> frame #33528: 0x000109db2edf libclang.dylib`clang::Diagnost
>>> icsEngine::ReportDelayed(this=0x00011c002c00) at Diagnostic.cpp:149
>>> frame #33529: 0x000109db5a36 libclang.dylib`clang::Diagnost
>>> icsEngine::EmitCurrentDiagnostic(this=0x00011c002c00, Force=false)
>>> at Diagnostic.cpp:428
>>> frame #33530: 0x00010a33f93c libclang.dylib`clang::Diagnost
>>> icBuilder::Emit(this=0x78d4bfd8) at Diagnostic.h:1013
>>> frame #33531: 0x00010a33f8e5 libclang.dylib`clang::Diagnost
>>> icBuilder::~DiagnosticBuilder(this=0x78d4bfd8) at
>>> Diagnostic.h:1036
>>> frame #33532: 0x00010a335015 libclang.dylib`clang::Diagnost
>>> icBuilder::~DiagnosticBuilder(this=0x78d4bfd8) at
>>> Diagnostic.h:1035
>>>
>>> It doesn't really look like a regression though, it seems that this has
>>> just uncovered a bug in Clang: DiagnosticsEngine::ReportDelayed is
>>> clearing DelayedDiagID *after* reporting the issue which causes the
>>> infinite recursion, when it should clear it before. Is that right?
>>>
>>
>> EmitCurrentDiagnostic checks "DelayedDiagID != DiagID" before making the
>> recursive call, which should be preventing the infinite recursion.
>>
>> It looks like the immediate bug is that EmitCurrentDiagnostic grabs
>> CurDiagID *after* calling EmitDiag / ProcessDiag, which clear CurDiagID
>> when they succeed in emitting the diagnostic. But I agree, the right thing
>> to do is clear DelayedDiagID before emitting the delayed diagnostic, not
>> after. You should also be able to delete the incorrect recursion check in
>> EmitCurrentDiagnostic too.
>>
>
> Thanks, that makes sense.
>
> Unfortunately I had to revert my fix as it uncovered two issues in
> Misc/error-limit-multiple-notes.cpp and Misc/error-limit.c . It looks
> like your commit caused the infinite recursion in both of them, but the
> bots didn't catch that because they invoked not clang, and emitted the
> diagnostics that were checked (using FileCheck) before crashing, so they
> "passed". However, my fix causes the tests to fail, seemingly because now
> Clang doesn't suppress multiple notes after reaching the error limit (it
> suppresses just the first note). It looks like this is a regression
> introduced in this commit.
>
> Sorry, I was wrong in my analysis. It's not a regression introduced by
your commit, it's just a problem with my fix.


>
>
>>
>>
>>> I will commit a fix for this now.
>>>
>>
>> Thank you!
>>
>>
>>> Alex
>>>
>>>
>>> On 3 May 2017 at 01:28, Richard Smith via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 Author: rsmith
 Date: Tue May  2 19:28:49 2017
 New Revision: 301992

 URL: http://llvm.org/viewvc/llvm-project?rev=301992=rev
 Log:
 [modules] Round-trip -Werror flag through explicit module build.

 The intent for an explicit module build is that the diagnostics
 produced within
 the module are those that were configured when the module was built,
 not those
 that are enabled within a user of the module. This includes diagnostics
 that
 don't actually show up until the module is used (for instance,
 diagnostics
 produced during template instantiation and weird cases like -Wpadded).

 We serialized and restored the diagnostic state for individual warning
 groups,
 but previously did not track the state for flags like -Werror and
 -Weverything,
 which are implemented as separate bits rather than as part of the
 diagnostics
 mapping information.

 Modified:
 cfe/trunk/include/clang/Basic/Diagnostic.h
 cfe/trunk/include/clang/Basic/DiagnosticIDs.h
 cfe/trunk/lib/Basic/Diagnostic.cpp
 cfe/trunk/lib/Basic/DiagnosticIDs.cpp
 cfe/trunk/lib/Serialization/ASTReader.cpp
 cfe/trunk/lib/Serialization/ASTWriter.cpp
 cfe/trunk/test/Index/keep-going.cpp
 cfe/trunk/test/Modules/diag-flags.cpp
 cfe/trunk/tools/libclang/CIndex.cpp
 cfe/trunk/unittests/Basic/DiagnosticTest.cpp

 Modified: cfe/trunk/include/clang/Basic/Diagnostic.h
 URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/
 Basic/Diagnostic.h?rev=301992=301991=301992=diff
 
 ==
 --- cfe/trunk/include/clang/Basic/Diagnostic.h (original)
 +++ cfe/trunk/include/clang/Basic/Diagnostic.h Tue May  2 19:28:49 2017
 @@ -178,12 +178,7 @@ public:

  private:
unsigned char AllExtensionsSilenced; // Used by __extension__
 -  bool 

Re: r301992 - [modules] Round-trip -Werror flag through explicit module build.

[Alex L via cfe-commits]

On 3 May 2017 at 22:23, Richard Smith  wrote:

> On 3 May 2017 at 07:29, Alex L  wrote:
>
>> Hi Richard,
>>
>> This commit has caused an infinite loop in one of our internal libclang
>> based tooling tests. It keeps repeating the following frames:
>>
>> frame #33528: 0x000109db2edf libclang.dylib`clang::Diagnost
>> icsEngine::ReportDelayed(this=0x00011c002c00) at Diagnostic.cpp:149
>> frame #33529: 0x000109db5a36 libclang.dylib`clang::Diagnost
>> icsEngine::EmitCurrentDiagnostic(this=0x00011c002c00, Force=false)
>> at Diagnostic.cpp:428
>> frame #33530: 0x00010a33f93c libclang.dylib`clang::Diagnost
>> icBuilder::Emit(this=0x78d4bfd8) at Diagnostic.h:1013
>> frame #33531: 0x00010a33f8e5 libclang.dylib`clang::Diagnost
>> icBuilder::~DiagnosticBuilder(this=0x78d4bfd8) at
>> Diagnostic.h:1036
>> frame #33532: 0x00010a335015 libclang.dylib`clang::Diagnost
>> icBuilder::~DiagnosticBuilder(this=0x78d4bfd8) at
>> Diagnostic.h:1035
>>
>> It doesn't really look like a regression though, it seems that this has
>> just uncovered a bug in Clang: DiagnosticsEngine::ReportDelayed is
>> clearing DelayedDiagID *after* reporting the issue which causes the
>> infinite recursion, when it should clear it before. Is that right?
>>
>
> EmitCurrentDiagnostic checks "DelayedDiagID != DiagID" before making the
> recursive call, which should be preventing the infinite recursion.
>
> It looks like the immediate bug is that EmitCurrentDiagnostic grabs
> CurDiagID *after* calling EmitDiag / ProcessDiag, which clear CurDiagID
> when they succeed in emitting the diagnostic. But I agree, the right thing
> to do is clear DelayedDiagID before emitting the delayed diagnostic, not
> after. You should also be able to delete the incorrect recursion check in
> EmitCurrentDiagnostic too.
>

Thanks, that makes sense.

Unfortunately I had to revert my fix as it uncovered two issues in
Misc/error-limit-multiple-notes.cpp and Misc/error-limit.c . It looks like
your commit caused the infinite recursion in both of them, but the bots
didn't catch that because they invoked not clang, and emitted the
diagnostics that were checked (using FileCheck) before crashing, so they
"passed". However, my fix causes the tests to fail, seemingly because now
Clang doesn't suppress multiple notes after reaching the error limit (it
suppresses just the first note). It looks like this is a regression
introduced in this commit.



>
>
>> I will commit a fix for this now.
>>
>
> Thank you!
>
>
>> Alex
>>
>>
>> On 3 May 2017 at 01:28, Richard Smith via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: rsmith
>>> Date: Tue May  2 19:28:49 2017
>>> New Revision: 301992
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=301992=rev
>>> Log:
>>> [modules] Round-trip -Werror flag through explicit module build.
>>>
>>> The intent for an explicit module build is that the diagnostics produced
>>> within
>>> the module are those that were configured when the module was built, not
>>> those
>>> that are enabled within a user of the module. This includes diagnostics
>>> that
>>> don't actually show up until the module is used (for instance,
>>> diagnostics
>>> produced during template instantiation and weird cases like -Wpadded).
>>>
>>> We serialized and restored the diagnostic state for individual warning
>>> groups,
>>> but previously did not track the state for flags like -Werror and
>>> -Weverything,
>>> which are implemented as separate bits rather than as part of the
>>> diagnostics
>>> mapping information.
>>>
>>> Modified:
>>> cfe/trunk/include/clang/Basic/Diagnostic.h
>>> cfe/trunk/include/clang/Basic/DiagnosticIDs.h
>>> cfe/trunk/lib/Basic/Diagnostic.cpp
>>> cfe/trunk/lib/Basic/DiagnosticIDs.cpp
>>> cfe/trunk/lib/Serialization/ASTReader.cpp
>>> cfe/trunk/lib/Serialization/ASTWriter.cpp
>>> cfe/trunk/test/Index/keep-going.cpp
>>> cfe/trunk/test/Modules/diag-flags.cpp
>>> cfe/trunk/tools/libclang/CIndex.cpp
>>> cfe/trunk/unittests/Basic/DiagnosticTest.cpp
>>>
>>> Modified: cfe/trunk/include/clang/Basic/Diagnostic.h
>>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/
>>> Basic/Diagnostic.h?rev=301992=301991=301992=diff
>>> 
>>> ==
>>> --- cfe/trunk/include/clang/Basic/Diagnostic.h (original)
>>> +++ cfe/trunk/include/clang/Basic/Diagnostic.h Tue May  2 19:28:49 2017
>>> @@ -178,12 +178,7 @@ public:
>>>
>>>  private:
>>>unsigned char AllExtensionsSilenced; // Used by __extension__
>>> -  bool IgnoreAllWarnings;// Ignore all warnings: -w
>>> -  bool WarningsAsErrors; // Treat warnings like errors.
>>> -  bool EnableAllWarnings;// Enable all warnings.
>>> -  bool ErrorsAsFatal;// Treat errors like fatal errors.
>>> -  bool FatalsAsError; // Treat fatal errors like 

Re: r301992 - [modules] Round-trip -Werror flag through explicit module build.

[Alex L via cfe-commits]

Hi Richard,

This commit has caused an infinite loop in one of our internal libclang
based tooling tests. It keeps repeating the following frames:

frame #33528: 0x000109db2edf
libclang.dylib`clang::DiagnosticsEngine::ReportDelayed(this=0x00011c002c00)
at Diagnostic.cpp:149
frame #33529: 0x000109db5a36
libclang.dylib`clang::DiagnosticsEngine::EmitCurrentDiagnostic(this=0x00011c002c00,
Force=false) at Diagnostic.cpp:428
frame #33530: 0x00010a33f93c
libclang.dylib`clang::DiagnosticBuilder::Emit(this=0x78d4bfd8) at
Diagnostic.h:1013
frame #33531: 0x00010a33f8e5
libclang.dylib`clang::DiagnosticBuilder::~DiagnosticBuilder(this=0x78d4bfd8)
at Diagnostic.h:1036
frame #33532: 0x00010a335015
libclang.dylib`clang::DiagnosticBuilder::~DiagnosticBuilder(this=0x78d4bfd8)
at Diagnostic.h:1035

It doesn't really look like a regression though, it seems that this has
just uncovered a bug in Clang: DiagnosticsEngine::ReportDelayed is
clearing DelayedDiagID *after* reporting the issue which causes the
infinite recursion, when it should clear it before. Is that right? I will
commit a fix for this now.

Alex


On 3 May 2017 at 01:28, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rsmith
> Date: Tue May  2 19:28:49 2017
> New Revision: 301992
>
> URL: http://llvm.org/viewvc/llvm-project?rev=301992=rev
> Log:
> [modules] Round-trip -Werror flag through explicit module build.
>
> The intent for an explicit module build is that the diagnostics produced
> within
> the module are those that were configured when the module was built, not
> those
> that are enabled within a user of the module. This includes diagnostics
> that
> don't actually show up until the module is used (for instance, diagnostics
> produced during template instantiation and weird cases like -Wpadded).
>
> We serialized and restored the diagnostic state for individual warning
> groups,
> but previously did not track the state for flags like -Werror and
> -Weverything,
> which are implemented as separate bits rather than as part of the
> diagnostics
> mapping information.
>
> Modified:
> cfe/trunk/include/clang/Basic/Diagnostic.h
> cfe/trunk/include/clang/Basic/DiagnosticIDs.h
> cfe/trunk/lib/Basic/Diagnostic.cpp
> cfe/trunk/lib/Basic/DiagnosticIDs.cpp
> cfe/trunk/lib/Serialization/ASTReader.cpp
> cfe/trunk/lib/Serialization/ASTWriter.cpp
> cfe/trunk/test/Index/keep-going.cpp
> cfe/trunk/test/Modules/diag-flags.cpp
> cfe/trunk/tools/libclang/CIndex.cpp
> cfe/trunk/unittests/Basic/DiagnosticTest.cpp
>
> Modified: cfe/trunk/include/clang/Basic/Diagnostic.h
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/Basic/Diagnostic.h?rev=301992=301991=301992=diff
> 
> ==
> --- cfe/trunk/include/clang/Basic/Diagnostic.h (original)
> +++ cfe/trunk/include/clang/Basic/Diagnostic.h Tue May  2 19:28:49 2017
> @@ -178,12 +178,7 @@ public:
>
>  private:
>unsigned char AllExtensionsSilenced; // Used by __extension__
> -  bool IgnoreAllWarnings;// Ignore all warnings: -w
> -  bool WarningsAsErrors; // Treat warnings like errors.
> -  bool EnableAllWarnings;// Enable all warnings.
> -  bool ErrorsAsFatal;// Treat errors like fatal errors.
> -  bool FatalsAsError; // Treat fatal errors like errors.
> -  bool SuppressSystemWarnings;   // Suppress warnings in system headers.
> +  bool SuppressAfterFatalError;  // Suppress diagnostics after a fatal
> error?
>bool SuppressAllDiagnostics;   // Suppress all diagnostics.
>bool ElideType;// Elide common types of templates.
>bool PrintTemplateTree;// Print a tree when comparing templates.
> @@ -194,7 +189,6 @@ private:
> // 0 -> no limit.
>unsigned ConstexprBacktraceLimit; // Cap on depth of constexpr
> evaluation
>  // backtrace stack, 0 -> no limit.
> -  diag::Severity ExtBehavior;   // Map extensions to warnings or
> errors?
>IntrusiveRefCntPtr Diags;
>IntrusiveRefCntPtr DiagOpts;
>DiagnosticConsumer *Client;
> @@ -216,6 +210,19 @@ private:
>  llvm::DenseMap DiagMap;
>
>public:
> +// "Global" configuration state that can actually vary between
> modules.
> +unsigned IgnoreAllWarnings : 1;  // Ignore all warnings: -w
> +unsigned EnableAllWarnings : 1;  // Enable all warnings.
> +unsigned WarningsAsErrors : 1;   // Treat warnings like errors.
> +unsigned ErrorsAsFatal : 1;  // Treat errors like fatal
> errors.
> +unsigned SuppressSystemWarnings : 1; // Suppress warnings in system
> headers.
> +diag::Severity ExtBehavior : 4; // Map extensions to warnings or
> errors?
> +
> +DiagState()
> +: IgnoreAllWarnings(false), 

Re: [PATCH] [libclang] Check for a record declaration before a template specialization.

[Alex L via cfe-commits]

Hi,

On 21 April 2017 at 12:55, Emilio Cobos Álvarez via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> This allows us to get the default template parameters too.
>
> This patch was submitted also as https://reviews.llvm.org/D31732, but I
> see no
> reference to it in cfe-commits or llvm-commits, so I guess it got lost?
>

You have to add cfe-commits as subscribers to the Phabricator patch,
otherwise it won't show up in the mailing list. I would recommend you to
close the old one revision and create a new one on Phabricator, this way
we'll get the entire patch history on cfe-commits.

Alex


>
> This fixes bug 32539.
>
> Signed-off-by: Emilio Cobos Álvarez 
> ---
>  clang/test/Index/print-type.cpp | 8 +++-
>  clang/tools/libclang/CXType.cpp | 6 +++---
>  2 files changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/clang/test/Index/print-type.cpp
> b/clang/test/Index/print-type.cpp
> index 108ba53c80b..ff150f7dd61 100644
> --- a/clang/test/Index/print-type.cpp
> +++ b/clang/test/Index/print-type.cpp
> @@ -71,6 +71,11 @@ struct Specialization;
>  Specialization templRefParam;
>  auto autoTemplRefParam = templRefParam;
>
> +template
> +struct DefaultedTypeExample {};
> +
> +typedef DefaultedTypeExample DefaultedTypeAlias;
> +
>  // RUN: c-index-test -test-print-type %s -std=c++14 | FileCheck %s
>  // CHECK: Namespace=outer:1:11 (Definition) [type=] [typekind=Invalid]
> [isPOD=0]
>  // CHECK: ClassTemplate=Foo:4:8 (Definition) [type=] [typekind=Invalid]
> [isPOD=0]
> @@ -115,7 +120,7 @@ auto autoTemplRefParam = templRefParam;
>  // CHECK: TemplateRef=Baz:9:8 [type=] [typekind=Invalid] [isPOD=0]
>  // CHECK: IntegerLiteral= [type=int] [typekind=Int] [isPOD=1]
>  // CHECK: TemplateRef=Foo:4:8 [type=] [typekind=Invalid] [isPOD=0]
> -// CHECK: FieldDecl=qux:29:38 (Definition) [type=Qux Foo, outer::inner::Bar::FooType>] [typekind=Unexposed]
> [templateargs/4= [type=int] [typekind=Int] [type=char *] [typekind=Pointer]
> [type=Foo] [typekind=Unexposed] [type=outer::inner::Bar::FooType]
> [typekind=Typedef]] [canonicaltype=outer::Qux int>] [canonicaltypekind=Record] [canonicaltemplateargs/4= [type=int]
> [typekind=Int] [type=char *] [typekind=Pointer] [type=outer::Foo]
> [typekind=Record] [type=int] [typekind=Int]] [isPOD=1]
> +// CHECK: FieldDecl=qux:29:38 (Definition) [type=Qux Foo, outer::inner::Bar::FooType>] [typekind=Unexposed]
> [templateargs/4= [type=int] [typekind=Int] [type=char *] [typekind=Pointer]
> [type=outer::Foo] [typekind=Record] [type=int] [typekind=Int]]
> [canonicaltype=outer::Qux]
> [canonicaltypekind=Record] [canonicaltemplateargs/4= [type=int]
> [typekind=Int] [type=char *] [typekind=Pointer] [type=outer::Foo]
> [typekind=Record] [type=int] [typekind=Int]] [isPOD=1]
>  // CHECK: TemplateRef=Qux:12:8 [type=] [typekind=Invalid] [isPOD=0]
>  // CHECK: TemplateRef=Foo:4:8 [type=] [typekind=Invalid] [isPOD=0]
>  // CHECK: FunctionTemplate=tbar:36:3 [type=T (int)]
> [typekind=FunctionProto] [canonicaltype=type-parameter-0-0 (int)]
> [canonicaltypekind=FunctionProto] [resulttype=T]
> [resulttypekind=Unexposed] [isPOD=0]
> @@ -177,3 +182,4 @@ auto autoTemplRefParam = templRefParam;
>  // CHECK: VarDecl=autoTemplRefParam:72:6 (Definition)
> [type=Specialization] [typekind=Auto]
> [templateargs/1= [type=Specialization &] [typekind=LValueReference]]
> [canonicaltype=Specialization]
> [canonicaltypekind=Record] [canonicaltemplateargs/1=
> [type=Specialization &] [typekind=LValueReference]] [isPOD=1]
>  // CHECK: UnexposedExpr=templRefParam:71:40 [type=const
> Specialization] [typekind=Unexposed] const
> [templateargs/1= [type=Specialization &] [typekind=LValueReference]]
> [canonicaltype=const Specialization]
> [canonicaltypekind=Record] [canonicaltemplateargs/1=
> [type=Specialization &] [typekind=LValueReference]] [isPOD=1]
>  // CHECK: DeclRefExpr=templRefParam:71:40 
> [type=Specialization &>] [typekind=Unexposed] [templateargs/1= [type=Specialization &]
> [typekind=LValueReference]] [canonicaltype=Specialization &>] [canonicaltypekind=Record] [canonicaltemplateargs/1=
> [type=Specialization &] [typekind=LValueReference]] [isPOD=1]
> +// CHECK: TypedefDecl=DefaultedTypeAlias:77:35 (Definition)
> [type=DefaultedTypeAlias] [typekind=Typedef] [templateargs/2= [type=int]
> [typekind=Int] [type=int] [typekind=Int]] 
> [canonicaltype=DefaultedTypeExample int>] [canonicaltypekind=Record] [canonicaltemplateargs/2= [type=int]
> [typekind=Int] [type=int] [typekind=Int]] [isPOD=0]
> diff --git a/clang/tools/libclang/CXType.cpp
> b/clang/tools/libclang/CXType.cpp
> index 16e993e2ac0..fce7ef2c0d8 100644
> --- a/clang/tools/libclang/CXType.cpp
> +++ b/clang/tools/libclang/CXType.cpp
> @@ -147,9 +147,6 @@ static inline CXTranslationUnit GetTU(CXType CT) {
>  static 

Re: r300555 - Driver: Better detection of mingw-gcc

[Alex L via cfe-commits]

No problem, thanks for the quick update!

On 18 April 2017 at 15:56, Martell Malone  wrote:

> Yes I do :)
> I updated https://reviews.llvm.org/D15005 with a comment incase anyone
> goes there.
> I also updated https://reviews.llvm.org/D15006 (the correct link) to
> point to the commit revision.
>
> Thanks for pointing that out Alex
>
> On Tue, Apr 18, 2017 at 3:49 PM, Alex L  wrote:
>
>> I think you've got the wrong Phabricator link in the commit log.
>>
>> On 18 April 2017 at 15:27, Martell Malone via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: martell
>>> Date: Tue Apr 18 09:27:36 2017
>>> New Revision: 300555
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=300555=rev
>>> Log:
>>> Driver: Better detection of mingw-gcc
>>>
>>> Stop blindly searching for "gcc.exe" on windows.
>>> Stop assuming "/usr" on unix, fixes cross compiling.
>>>
>>> Reviewers: mati865, yaron.keren
>>>
>>> Subscribers: ismail, rnk
>>>
>>> Differential revision: https://reviews.llvm.org/D15005
>>>
>>> Modified:
>>> cfe/trunk/lib/Driver/ToolChains/MinGW.cpp
>>> cfe/trunk/lib/Driver/ToolChains/MinGW.h
>>>
>>> Modified: cfe/trunk/lib/Driver/ToolChains/MinGW.cpp
>>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Too
>>> lChains/MinGW.cpp?rev=300555=300554=300555=diff
>>> 
>>> ==
>>> --- cfe/trunk/lib/Driver/ToolChains/MinGW.cpp (original)
>>> +++ cfe/trunk/lib/Driver/ToolChains/MinGW.cpp Tue Apr 18 09:27:36 2017
>>> @@ -285,28 +285,30 @@ void toolchains::MinGW::findGccLibDir()
>>>}
>>>  }
>>>
>>> +llvm::ErrorOr toolchains::MinGW::findGcc() {
>>> +  llvm::SmallVector, 2> Gccs;
>>> +  Gccs.emplace_back(getTriple().getArchName());
>>> +  Gccs[0] += "-w64-mingw32-gcc";
>>> +  Gccs.emplace_back("mingw32-gcc");
>>> +  // Please do not add "gcc" here
>>> +  for (StringRef CandidateGcc : Gccs)
>>> +if (llvm::ErrorOr GPPName =
>>> llvm::sys::findProgramByName(CandidateGcc))
>>> +  return GPPName;
>>> +  return make_error_code(std::errc::no_such_file_or_directory);
>>> +}
>>> +
>>>  toolchains::MinGW::MinGW(const Driver , const llvm::Triple ,
>>>   const ArgList )
>>>  : ToolChain(D, Triple, Args), CudaInstallation(D, Triple, Args) {
>>>getProgramPaths().push_back(getDriver().getInstalledDir());
>>>
>>> -// In Windows there aren't any standard install locations, we search
>>> -// for gcc on the PATH. In Linux the base is always /usr.
>>> -#ifdef LLVM_ON_WIN32
>>>if (getDriver().SysRoot.size())
>>>  Base = getDriver().SysRoot;
>>> -  else if (llvm::ErrorOr GPPName =
>>> -   llvm::sys::findProgramByName("gcc"))
>>> +  else if (llvm::ErrorOr GPPName = findGcc())
>>>  Base = llvm::sys::path::parent_path(
>>>  llvm::sys::path::parent_path(GPPName.get()));
>>>else
>>>  Base = llvm::sys::path::parent_path(getDriver().getInstalledDir());
>>> -#else
>>> -  if (getDriver().SysRoot.size())
>>> -Base = getDriver().SysRoot;
>>> -  else
>>> -Base = "/usr";
>>> -#endif
>>>
>>>Base += llvm::sys::path::get_separator();
>>>findGccLibDir();
>>>
>>> Modified: cfe/trunk/lib/Driver/ToolChains/MinGW.h
>>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Too
>>> lChains/MinGW.h?rev=300555=300554=300555=diff
>>> 
>>> ==
>>> --- cfe/trunk/lib/Driver/ToolChains/MinGW.h (original)
>>> +++ cfe/trunk/lib/Driver/ToolChains/MinGW.h Tue Apr 18 09:27:36 2017
>>> @@ -93,6 +93,7 @@ private:
>>>mutable std::unique_ptr Preprocessor;
>>>mutable std::unique_ptr Compiler;
>>>void findGccLibDir();
>>> +  llvm::ErrorOr findGcc();
>>>  };
>>>
>>>  } // end namespace toolchains
>>>
>>>
>>> ___
>>> 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: r300555 - Driver: Better detection of mingw-gcc

[Alex L via cfe-commits]

I think you've got the wrong Phabricator link in the commit log.

On 18 April 2017 at 15:27, Martell Malone via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: martell
> Date: Tue Apr 18 09:27:36 2017
> New Revision: 300555
>
> URL: http://llvm.org/viewvc/llvm-project?rev=300555=rev
> Log:
> Driver: Better detection of mingw-gcc
>
> Stop blindly searching for "gcc.exe" on windows.
> Stop assuming "/usr" on unix, fixes cross compiling.
>
> Reviewers: mati865, yaron.keren
>
> Subscribers: ismail, rnk
>
> Differential revision: https://reviews.llvm.org/D15005
>
> Modified:
> cfe/trunk/lib/Driver/ToolChains/MinGW.cpp
> cfe/trunk/lib/Driver/ToolChains/MinGW.h
>
> Modified: cfe/trunk/lib/Driver/ToolChains/MinGW.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/
> ToolChains/MinGW.cpp?rev=300555=300554=300555=diff
> 
> ==
> --- cfe/trunk/lib/Driver/ToolChains/MinGW.cpp (original)
> +++ cfe/trunk/lib/Driver/ToolChains/MinGW.cpp Tue Apr 18 09:27:36 2017
> @@ -285,28 +285,30 @@ void toolchains::MinGW::findGccLibDir()
>}
>  }
>
> +llvm::ErrorOr toolchains::MinGW::findGcc() {
> +  llvm::SmallVector, 2> Gccs;
> +  Gccs.emplace_back(getTriple().getArchName());
> +  Gccs[0] += "-w64-mingw32-gcc";
> +  Gccs.emplace_back("mingw32-gcc");
> +  // Please do not add "gcc" here
> +  for (StringRef CandidateGcc : Gccs)
> +if (llvm::ErrorOr GPPName = llvm::sys::findProgramByName(
> CandidateGcc))
> +  return GPPName;
> +  return make_error_code(std::errc::no_such_file_or_directory);
> +}
> +
>  toolchains::MinGW::MinGW(const Driver , const llvm::Triple ,
>   const ArgList )
>  : ToolChain(D, Triple, Args), CudaInstallation(D, Triple, Args) {
>getProgramPaths().push_back(getDriver().getInstalledDir());
>
> -// In Windows there aren't any standard install locations, we search
> -// for gcc on the PATH. In Linux the base is always /usr.
> -#ifdef LLVM_ON_WIN32
>if (getDriver().SysRoot.size())
>  Base = getDriver().SysRoot;
> -  else if (llvm::ErrorOr GPPName =
> -   llvm::sys::findProgramByName("gcc"))
> +  else if (llvm::ErrorOr GPPName = findGcc())
>  Base = llvm::sys::path::parent_path(
>  llvm::sys::path::parent_path(GPPName.get()));
>else
>  Base = llvm::sys::path::parent_path(getDriver().getInstalledDir());
> -#else
> -  if (getDriver().SysRoot.size())
> -Base = getDriver().SysRoot;
> -  else
> -Base = "/usr";
> -#endif
>
>Base += llvm::sys::path::get_separator();
>findGccLibDir();
>
> Modified: cfe/trunk/lib/Driver/ToolChains/MinGW.h
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/
> ToolChains/MinGW.h?rev=300555=300554=300555=diff
> 
> ==
> --- cfe/trunk/lib/Driver/ToolChains/MinGW.h (original)
> +++ cfe/trunk/lib/Driver/ToolChains/MinGW.h Tue Apr 18 09:27:36 2017
> @@ -93,6 +93,7 @@ private:
>mutable std::unique_ptr Preprocessor;
>mutable std::unique_ptr Compiler;
>void findGccLibDir();
> +  llvm::ErrorOr findGcc();
>  };
>
>  } // end namespace toolchains
>
>
> ___
> 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: r299226 - [Modules][PCH] Serialize #pragma pack

[Alex L via cfe-commits]

Thanks Duncan!

On 15 April 2017 at 01:25, Duncan P. N. Exon Smith 
wrote:

> FYI, I reverted the modules side of this in r300380.  For details, see the
> commit message.  TL;DR: this didn't actually make modules builds closer to
> matching non-modules builds, thanks to how submodules work; on the
> contrary, it made them diverge.
>
> > On 2017-Mar-31, at 08:36, Alex Lorenz via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
> >
> > Author: arphaman
> > Date: Fri Mar 31 10:36:21 2017
> > New Revision: 299226
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=299226=rev
> > Log:
> > [Modules][PCH] Serialize #pragma pack
> >
> > This patch serializes the state of #pragma pack. It preserves the state
> of the
> > pragma from a PCH/from modules in a file that uses that PCH/those
> modules.
> >
>
> > rdar://21359084
> >
> > Differential Revision: https://reviews.llvm.org/D31241
> >
> > Added:
> >cfe/trunk/test/Modules/Inputs/pragma_pack_push.h
> >cfe/trunk/test/Modules/Inputs/pragma_pack_reset_push.h
> >cfe/trunk/test/Modules/Inputs/pragma_pack_set.h
> >cfe/trunk/test/Modules/pragma-pack.c
> >cfe/trunk/test/PCH/pragma-pack.c
> > Modified:
> >cfe/trunk/include/clang/Serialization/ASTBitCodes.h
> >cfe/trunk/include/clang/Serialization/ASTReader.h
> >cfe/trunk/include/clang/Serialization/ASTWriter.h
> >cfe/trunk/lib/Sema/SemaAttr.cpp
> >cfe/trunk/lib/Serialization/ASTReader.cpp
> >cfe/trunk/lib/Serialization/ASTWriter.cpp
> >cfe/trunk/test/Modules/Inputs/module.map
> >
> > Modified: cfe/trunk/include/clang/Serialization/ASTBitCodes.h
> > URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/Serialization/ASTBitCodes.h?rev=299226=299225=299226=diff
> > 
> ==
> > --- cfe/trunk/include/clang/Serialization/ASTBitCodes.h (original)
> > +++ cfe/trunk/include/clang/Serialization/ASTBitCodes.h Fri Mar 31
> 10:36:21 2017
> > @@ -604,6 +604,9 @@ namespace clang {
> >   OPENCL_EXTENSION_DECLS = 59,
> >
> >   MODULAR_CODEGEN_DECLS = 60,
> > +
> > +  /// \brief Record code for \#pragma pack options.
> > +  PACK_PRAGMA_OPTIONS = 61,
> > };
> >
> > /// \brief Record types used within a source manager block.
> >
> > Modified: cfe/trunk/include/clang/Serialization/ASTReader.h
> > URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/Serialization/ASTReader.h?rev=299226=299225=299226=diff
> > 
> ==
> > --- cfe/trunk/include/clang/Serialization/ASTReader.h (original)
> > +++ cfe/trunk/include/clang/Serialization/ASTReader.h Fri Mar 31
> 10:36:21 2017
> > @@ -811,6 +811,17 @@ private:
> >   int PragmaMSPointersToMembersState = -1;
> >   SourceLocation PointersToMembersPragmaLocation;
> >
> > +  /// \brief The pragma pack state.
> > +  Optional PragmaPackCurrentValue;
> > +  SourceLocation PragmaPackCurrentLocation;
> > +  struct PragmaPackStackEntry {
> > +unsigned Value;
> > +SourceLocation Location;
> > +StringRef SlotLabel;
> > +  };
> > +  llvm::SmallVector PragmaPackStack;
> > +  llvm::SmallVector PragmaPackStrings;
> > +
> >   /// \brief The OpenCL extension settings.
> >   OpenCLOptions OpenCLExtensions;
> >
> >
> > Modified: cfe/trunk/include/clang/Serialization/ASTWriter.h
> > URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/Serialization/ASTWriter.h?rev=299226=299225=299226=diff
> > 
> ==
> > --- cfe/trunk/include/clang/Serialization/ASTWriter.h (original)
> > +++ cfe/trunk/include/clang/Serialization/ASTWriter.h Fri Mar 31
> 10:36:21 2017
> > @@ -485,6 +485,7 @@ private:
> >   void WriteOptimizePragmaOptions(Sema );
> >   void WriteMSStructPragmaOptions(Sema );
> >   void WriteMSPointersToMembersPragmaOptions(Sema );
> > +  void WritePackPragmaOptions(Sema );
> >   void WriteModuleFileExtension(Sema ,
> > ModuleFileExtensionWriter );
> >
> >
> > Modified: cfe/trunk/lib/Sema/SemaAttr.cpp
> > URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/
> SemaAttr.cpp?rev=299226=299225=299226=diff
> > 
> ==
> > --- cfe/trunk/lib/Sema/SemaAttr.cpp (original)
> > +++ cfe/trunk/lib/Sema/SemaAttr.cpp Fri Mar 31 10:36:21 2017
> > @@ -215,6 +215,7 @@ void Sema::PragmaStack::Act(S
> >ValueType Value) {
> >   if (Action == PSK_Reset) {
> > CurrentValue = DefaultValue;
> > +CurrentPragmaLocation = PragmaLocation;
> > return;
> >   }
> >   if (Action & PSK_Push)
> >
> > Modified: cfe/trunk/lib/Serialization/ASTReader.cpp
> > URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/
> Serialization/ASTReader.cpp?rev=299226=299225=299226=diff
> > 

Re: [PATCH] D30009: Add support for '#pragma clang attribute'

[Alex L via cfe-commits]

On 5 April 2017 at 13:38, Duncan Exon Smith  wrote:

>
>
> > On Apr 5, 2017, at 05:13, Aaron Ballman via Phabricator <
> revi...@reviews.llvm.org> wrote:
> >
> > aaron.ballman added inline comments.
> >
> >
> > 
> > Comment at: lib/Sema/SemaAttr.cpp:578
> > +return;
> > +  Diag(PragmaAttributeStack.back().Loc, diag::warn_pragm_attribute_no_
> pop_eof);
> > +}
> > 
> > arphaman wrote:
> >> aaron.ballman wrote:
> >>> Perhaps adding a FixIt here would be a kindness?
> >> Where would the fix-it point to? I think only the user will know the
> location at which they meant to insert `#pragma clang attribute pop`.
> > Given that it's a warning rather than an error, and our recovery
> mechanism is to effectively pop the pragma at the end of the TU, I was
> thinking it could be added at the end of the TU. However, you are correct
> that it's probably not where the programmer needs it,
>
> What about at the end of the file the push is in?  This is likely to be
> used in header files, and it's probably unintentional if it extends past
> the end of the file of the push.
>

Then we'd have to take into account preprocessor directives, as we'd
obviously want to insert it before the '#endif'. Or if the user used
`#pragma once`  then the end of the file could probably work.
IMHO the improvement can be done as a follow-up that improves this and
other pragmas like #pragma pack.


> I think we should consider the same thing for #pragma pack (although
> that's a little off-topic).
>
> > so a FixIt likely isn't appropriate. Does that suggest the warning
> should be an error instead?
>
> Maybe it should be an error, but I still think a fixit would be nice if we
> can find a spot.
>
> >
> >
> > Repository:
> >  rL LLVM
> >
> > https://reviews.llvm.org/D30009
> >
> >
> >
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: FW: SemaAccess bug (protected members of derived)

[Alex L via cfe-commits]

Thanks,

It looks like your solution isn't quite right as it causes Clang to accept
invalid access to protected members, e.g. as tested by
"test/CXX/class.access/class.protected/p1.cpp".

Do you think there's an alternative solution that you could use?

Alex

On 21 March 2017 at 14:48, Dixon Ryan (ETAS/ERS-PD2) 
wrote:

> From path:
>
>
>
> URL: http://llvm.org/svn/llvm-project/cfe/trunk
>
> Relative URL: ^/cfe/trunk
>
>
>
> *From:* Alex L [mailto:arpha...@gmail.com]
> *Sent:* 21 March 2017 14:22
> *To:* Dixon Ryan (ETAS/ERS-PD2) 
> *Cc:* cfe-commits@lists.llvm.org
> *Subject:* Re: FW: SemaAccess bug (protected members of derived)
>
>
>
> Thanks, can you please attach a diff that includes both the code change
> and the new test?
>
>
>
> On 21 March 2017 at 14:18, Dixon Ryan (ETAS/ERS-PD2) via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
> Sending to mailing list.
>
>
>
> *From:* Dixon Ryan (ETAS/ERS-PD2)
> *Sent:* 21 March 2017 14:18
> *To:* 'Alex L' 
> *Subject:* RE: SemaAccess bug (protected members of derived)
>
>
>
> Hello, sorry this is the first time I have done this.
>
>
>
> The test case is attached. It should fail without the patch and then
> should pass with the patch.
>
>
>
>
>
> class cl
>
> {
>
> public:
>
>void myPublic(int x){ }
>
> protected:
>
>void myProtected(int y){ }
>
> };
>
>
>
> class clChild : public cl
>
> {
>
>void myPrivate(int z)
>
>{
>
>   this->
>
>  // RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:13:13 %s
> -o - | FileCheck -check-prefix=CHECK-CC1 %s
>
>  // CHECK: COMPLETION: myProtected : [#void#][#cl::#]myProtected(<#int
> y#>)
>
>}
>
> };
>
>
>
>
>
> *From:* Alex L [mailto:arpha...@gmail.com ]
> *Sent:* 21 March 2017 12:17
> *To:* Dixon Ryan (ETAS/ERS-PD2) 
> *Cc:* cfe-commits@lists.llvm.org
> *Subject:* Re: SemaAccess bug (protected members of derived)
>
>
>
> Hi,
>
>
>
> Can you please add a suitable test-case? Clang's code-completion tests are
> normally in test/CodeCompletion or test/Index.
>
>
>
> Cheers,
>
> Alex
>
>
>
> On 21 March 2017 at 12:05, Dixon Ryan (ETAS/ERS-PD2) via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
> There are a number of users of the clang static analyser back-end for
> intelligent code completion. Irony-Mode for emacs, for example. For a while
> people have been reporting an issue with not getting completions for
> protected members of parent classes and I believe this patch solves the
> bug: simply that the arguments to IsDerivedFromInclusive were the wrong way
> around.
>
>
>
> URL: http://llvm.org/svn/llvm-project/cfe/trunk/lib/Sema
>
> Relative URL: ^/cfe/trunk/lib/Sema
>
>
>
> Index: SemaAccess.cpp
>
> ===
>
> --- SemaAccess.cpp  (revision 297956)
>
> +++ SemaAccess.cpp   (working copy)
>
> @@ -823,7 +823,7 @@
>
>  continue;
>
>}
>
> -  switch (IsDerivedFromInclusive(InstanceContext, ECRecord)) {
>
> +  switch (IsDerivedFromInclusive(ECRecord, InstanceContext)) {
>
>case AR_accessible: return AR_accessible;
>
>case AR_inaccessible: continue;
>
>case AR_dependent: OnFailure = AR_dependent; continue;
>
>
>
> Thank you.
>
>
> ___
> 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: FW: SemaAccess bug (protected members of derived)

[Alex L via cfe-commits]

Thanks, can you please attach a diff that includes both the code change and
the new test?

On 21 March 2017 at 14:18, Dixon Ryan (ETAS/ERS-PD2) via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Sending to mailing list.
>
>
>
> *From:* Dixon Ryan (ETAS/ERS-PD2)
> *Sent:* 21 March 2017 14:18
> *To:* 'Alex L' 
> *Subject:* RE: SemaAccess bug (protected members of derived)
>
>
>
> Hello, sorry this is the first time I have done this.
>
>
>
> The test case is attached. It should fail without the patch and then
> should pass with the patch.
>
>
>
>
>
> class cl
>
> {
>
> public:
>
>void myPublic(int x){ }
>
> protected:
>
>void myProtected(int y){ }
>
> };
>
>
>
> class clChild : public cl
>
> {
>
>void myPrivate(int z)
>
>{
>
>   this->
>
>  // RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:13:13 %s
> -o - | FileCheck -check-prefix=CHECK-CC1 %s
>
>  // CHECK: COMPLETION: myProtected : [#void#][#cl::#]myProtected(<#int
> y#>)
>
>}
>
> };
>
>
>
>
>
> *From:* Alex L [mailto:arpha...@gmail.com ]
> *Sent:* 21 March 2017 12:17
> *To:* Dixon Ryan (ETAS/ERS-PD2) 
> *Cc:* cfe-commits@lists.llvm.org
> *Subject:* Re: SemaAccess bug (protected members of derived)
>
>
>
> Hi,
>
>
>
> Can you please add a suitable test-case? Clang's code-completion tests are
> normally in test/CodeCompletion or test/Index.
>
>
>
> Cheers,
>
> Alex
>
>
>
> On 21 March 2017 at 12:05, Dixon Ryan (ETAS/ERS-PD2) via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
> There are a number of users of the clang static analyser back-end for
> intelligent code completion. Irony-Mode for emacs, for example. For a while
> people have been reporting an issue with not getting completions for
> protected members of parent classes and I believe this patch solves the
> bug: simply that the arguments to IsDerivedFromInclusive were the wrong way
> around.
>
>
>
> URL: http://llvm.org/svn/llvm-project/cfe/trunk/lib/Sema
>
> Relative URL: ^/cfe/trunk/lib/Sema
>
>
>
> Index: SemaAccess.cpp
>
> ===
>
> --- SemaAccess.cpp  (revision 297956)
>
> +++ SemaAccess.cpp   (working copy)
>
> @@ -823,7 +823,7 @@
>
>  continue;
>
>}
>
> -  switch (IsDerivedFromInclusive(InstanceContext, ECRecord)) {
>
> +  switch (IsDerivedFromInclusive(ECRecord, InstanceContext)) {
>
>case AR_accessible: return AR_accessible;
>
>case AR_inaccessible: continue;
>
>case AR_dependent: OnFailure = AR_dependent; continue;
>
>
>
> Thank you.
>
>
> ___
> 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: SemaAccess bug (protected members of derived)

[Alex L via cfe-commits]

Hi,

Can you please add a suitable test-case? Clang's code-completion tests are
normally in test/CodeCompletion or test/Index.

Cheers,
Alex

On 21 March 2017 at 12:05, Dixon Ryan (ETAS/ERS-PD2) via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> There are a number of users of the clang static analyser back-end for
> intelligent code completion. Irony-Mode for emacs, for example. For a while
> people have been reporting an issue with not getting completions for
> protected members of parent classes and I believe this patch solves the
> bug: simply that the arguments to IsDerivedFromInclusive were the wrong way
> around.
>
>
>
> URL: http://llvm.org/svn/llvm-project/cfe/trunk/lib/Sema
>
> Relative URL: ^/cfe/trunk/lib/Sema
>
>
>
> Index: SemaAccess.cpp
>
> ===
>
> --- SemaAccess.cpp  (revision 297956)
>
> +++ SemaAccess.cpp   (working copy)
>
> @@ -823,7 +823,7 @@
>
>  continue;
>
>}
>
> -  switch (IsDerivedFromInclusive(InstanceContext, ECRecord)) {
>
> +  switch (IsDerivedFromInclusive(ECRecord, InstanceContext)) {
>
>case AR_accessible: return AR_accessible;
>
>case AR_inaccessible: continue;
>
>case AR_dependent: OnFailure = AR_dependent; continue;
>
>
>
> Thank you.
>
> ___
> 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: r294008 - [Sema][ObjC++] Typo correction should handle ivars and properties

[Alex L via cfe-commits]

Thanks!

On 3 February 2017 at 22:34, Hans Wennborg  wrote:

> Thanks! r294059.
>
> On Fri, Feb 3, 2017 at 2:29 PM, Richard Smith 
> wrote:
> > It looks like the only cases it should have any real impact on are those
> > where we would previously miscompile/crash, so this seems OK to me to
> merge
> > to Clang 4.
> >
> >
> > On 3 February 2017 at 13:45, Hans Wennborg  wrote:
> >>
> >> IIUC, this isn't strictly fixing a regression from 3.9, but it looks
> >> like a pretty small diff.
> >>
> >> Richard, what do you think?
> >>
> >> On Fri, Feb 3, 2017 at 6:37 AM, Alex L  wrote:
> >> > Hi Hans,
> >> >
> >> > Is there any chance we can merge this for 4.0? It fixed a nasty bug
> >> > where
> >> > clang didn't catch invalid ObjC++ code during semantic analysis which
> >> > led to
> >> > invalid object files or crashes in CodeGen.
> >> >
> >> > Cheers,
> >> > Alex
> >> >
> >> > On 3 February 2017 at 14:22, Alex Lorenz via cfe-commits
> >> >  wrote:
> >> >>
> >> >> Author: arphaman
> >> >> Date: Fri Feb  3 08:22:33 2017
> >> >> New Revision: 294008
> >> >>
> >> >> URL: http://llvm.org/viewvc/llvm-project?rev=294008=rev
> >> >> Log:
> >> >> [Sema][ObjC++] Typo correction should handle ivars and properties
> >> >>
> >> >> After r260016 and r260017 disabled typo correction for ivars and
> >> >> properties
> >> >> clang didn't report errors about unresolved identifier in the base of
> >> >> ivar
> >> >> and
> >> >> property ref expressions. This meant that clang invoked CodeGen on
> >> >> invalid
> >> >> AST
> >> >> which then caused a crash.
> >> >>
> >> >> This commit re-enables typo correction for ivars and properites, and
> >> >> fixes
> >> >> the
> >> >> PR25113 & PR26486 (that were originally fixed in r260017 and r260016)
> >> >> in a
> >> >> different manner by transforming the Objective-C ivar reference
> >> >> expression
> >> >> with
> >> >> 'IsFreeIvar' preserved.
> >> >>
> >> >> rdar://30310772
> >> >>
> >> >> Modified:
> >> >> cfe/trunk/lib/Sema/SemaExprCXX.cpp
> >> >> cfe/trunk/lib/Sema/TreeTransform.h
> >> >> cfe/trunk/test/SemaObjCXX/typo-correction.mm
> >> >>
> >> >> Modified: cfe/trunk/lib/Sema/SemaExprCXX.cpp
> >> >> URL:
> >> >>
> >> >> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/
> SemaExprCXX.cpp?rev=294008=294007=294008=diff
> >> >>
> >> >>
> >> >> 
> ==
> >> >> --- cfe/trunk/lib/Sema/SemaExprCXX.cpp (original)
> >> >> +++ cfe/trunk/lib/Sema/SemaExprCXX.cpp Fri Feb  3 08:22:33 2017
> >> >> @@ -7250,14 +7250,6 @@ public:
> >> >>
> >> >>ExprResult TransformBlockExpr(BlockExpr *E) { return Owned(E); }
> >> >>
> >> >> -  ExprResult TransformObjCPropertyRefExpr(ObjCPropertyRefExpr *E) {
> >> >> -return Owned(E);
> >> >> -  }
> >> >> -
> >> >> -  ExprResult TransformObjCIvarRefExpr(ObjCIvarRefExpr *E) {
> >> >> -return Owned(E);
> >> >> -  }
> >> >> -
> >> >>ExprResult Transform(Expr *E) {
> >> >>  ExprResult Res;
> >> >>  while (true) {
> >> >>
> >> >> Modified: cfe/trunk/lib/Sema/TreeTransform.h
> >> >> URL:
> >> >>
> >> >> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/
> TreeTransform.h?rev=294008=294007=294008=diff
> >> >>
> >> >>
> >> >> 
> ==
> >> >> --- cfe/trunk/lib/Sema/TreeTransform.h (original)
> >> >> +++ cfe/trunk/lib/Sema/TreeTransform.h Fri Feb  3 08:22:33 2017
> >> >> @@ -2982,16 +2982,17 @@ public:
> >> >>ExprResult RebuildObjCIvarRefExpr(Expr *BaseArg, ObjCIvarDecl
> *Ivar,
> >> >>SourceLocation IvarLoc,
> >> >>bool IsArrow, bool
> >> >> IsFreeIvar)
> >> >> {
> >> >> -// FIXME: We lose track of the IsFreeIvar bit.
> >> >>  CXXScopeSpec SS;
> >> >>  DeclarationNameInfo NameInfo(Ivar->getDeclName(), IvarLoc);
> >> >> -return getSema().BuildMemberReferenceExpr(BaseArg,
> >> >> BaseArg->getType(),
> >> >> -  /*FIXME:*/IvarLoc,
> >> >> IsArrow,
> >> >> -  SS, SourceLocation(),
> >> >> -
> >> >> /*FirstQualifierInScope=*/nullptr,
> >> >> -  NameInfo,
> >> >> -
> >> >> /*TemplateArgs=*/nullptr,
> >> >> -  /*S=*/nullptr);
> >> >> +ExprResult Result = getSema().BuildMemberReferenceExpr(
> >> >> +BaseArg, BaseArg->getType(),
> >> >> +/*FIXME:*/ IvarLoc, IsArrow, SS, SourceLocation(),
> >> >> +/*FirstQualifierInScope=*/nullptr, NameInfo,
> >> >> +/*TemplateArgs=*/nullptr,
> >> >> +/*S=*/nullptr);
> >> >> +if (IsFreeIvar && Result.isUsable())
> >> >> +  cast(Result.get())->setIsFreeIvar(
> IsFreeIvar);
> >> >> +return Result;
> >> >>}
> >> >>
> 

Re: r293518 - [ASTMatchers] Sprinkle some constexpr on the global matcher constructors.

[Alex L via cfe-commits]

Adrian has filed PR 31860 at https://llvm.org/bugs/show_bug.cgi?id=31860 .

On 3 February 2017 at 23:10, Duncan P. N. Exon Smith <dexonsm...@apple.com>
wrote:

> Note that this also failed on Linux:
> http://lab.llvm.org:8011/builders/clang-x86_64-linux-
> selfhost-modules/builds/2728
>
> This looks like a modules compiler bug, as opposed to a problem in the
> commit itself.  Alex, can you file a PR for this?
>
> > On 2017-Feb-01, at 07:35, Alex L via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
> >
> > I've narrowed the problem down to the difference in the linkage type for
> "clang::ast_matchers::recordDecl" between the module and non-module build:
> >
> > Module:
> > @_ZN5clang12ast_matchersL10recordDeclE = external global
> %"class.clang::ast_matchers::internal::VariadicDynCastAllOfMatcher.847",
> align 1
> >
> > Non-module:
> > @_ZN5clang12ast_matchersL10recordDeclE = internal constant
> %"class.clang::ast_matchers::internal::VariadicDynCastAllOfMatcher.916"
> undef, align 1, !dbg !7
> >
> > On 1 February 2017 at 11:03, Alex L <arpha...@gmail.com> wrote:
> > Hi Benjamin,
> >
> > This commit has caused a linking in our stage 2 modules buildbot at
> http://lab.llvm.org:8080/green/job/clang-stage2-cmake-modulesRDA/.
> Specifically, after this commit 'clang-reorder-fields' gets the following
> linking error:
> >
> > FAILED: bin/clang-reorder-fields
> > : && /Users/buildslave/jenkins/sharedspace/clang-stage2-
> cmake-modulesRDA@2/host-compiler/bin/clang++   -fPIC
> -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings
> -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long
> -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor
> -Wstring-conversion -Werror=date-time -std=c++11 -fmodules
> -fmodules-cache-path=/Users/buildslave/jenkins/sharedspace/clang-stage2-
> cmake-modulesRDA@2/clang-build/module.cache -fcxx-modules -gmodules
> -fcolor-diagnostics -fno-common -Woverloaded-virtual -Wno-nested-anon-types
> -O2 -g -DNDEBUG -Wl,-search_paths_first -Wl,-headerpad_max_install_names
> -Wl,-dead_strip tools/clang/tools/extra/clang-reorder-fields/tool/
> CMakeFiles/clang-reorder-fields.dir/ClangReorderFields.cpp.o  -o
> bin/clang-reorder-fields  lib/libLLVMSupport.a lib/libclangBasic.a
> lib/libclangFrontend.a lib/libclangReorderFields.a lib/libclangRewrite.a
> lib/libclangTooling.a lib/libclangToolingCore.a lib/libclangIndex.a
> lib/libclangFrontend.a lib/libclangParse.a lib/libLLVMMCParser.a
> lib/libclangSerialization.a lib/libclangSema.a lib/libclangEdit.a
> lib/libclangAnalysis.a lib/libLLVMBitReader.a lib/libLLVMProfileData.a
> lib/libclangDriver.a lib/libLLVMOption.a lib/libclangASTMatchers.a
> lib/libclangFormat.a lib/libclangToolingCore.a lib/libclangRewrite.a
> lib/libclangAST.a lib/libclangLex.a lib/libclangBasic.a lib/libLLVMCore.a
> lib/libLLVMMC.a lib/libLLVMSupport.a -lcurses -lz -lm lib/libLLVMDemangle.a
> -Wl,-rpath,@loader_path/../lib && :
> > Undefined symbols for architecture x86_64:
> >   "clang::ast_matchers::recordDecl", referenced from:
> >   clang::reorder_fields::(anonymous namespace)::ReorderingConsumer::
> HandleTranslationUnit(clang::ASTContext&) in libclangReorderFields.a(
> ReorderFieldsAction.cpp.o)
> > ld: symbol(s) not found for architecture x86_64
> >
> > This might be a bug/regression in clang and modules since in my opinion
> the link should succeed. I've reverted your commit in r293759 while we are
> investigating.
> >
> > Thanks,
> > Alex
> >
> >
> > On 30 January 2017 at 18:20, Benjamin Kramer via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
> > Author: d0k
> > Date: Mon Jan 30 12:20:00 2017
> > New Revision: 293518
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=293518=rev
> > Log:
> > [ASTMatchers] Sprinkle some constexpr on the global matcher constructors.
> >
> > This dramatically reduces the size of the global constructors we emit
> > for those variables in debug mode.
> >
> > Modified:
> > cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h
> >
> > Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h
> > URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/ASTMatchers/ASTMatchersInternal.h?rev=293518=293517=293518&
> view=diff
> > 
> ==
> > --- cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h (original)
> > +++ cfe/trunk/include/clang/ASTMatchers/ASTMatchers

Re: r294008 - [Sema][ObjC++] Typo correction should handle ivars and properties

[Alex L via cfe-commits]

Hi Hans,

Is there any chance we can merge this for 4.0? It fixed a nasty bug where
clang didn't catch invalid ObjC++ code during semantic analysis which led
to invalid object files or crashes in CodeGen.

Cheers,
Alex

On 3 February 2017 at 14:22, Alex Lorenz via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: arphaman
> Date: Fri Feb  3 08:22:33 2017
> New Revision: 294008
>
> URL: http://llvm.org/viewvc/llvm-project?rev=294008=rev
> Log:
> [Sema][ObjC++] Typo correction should handle ivars and properties
>
> After r260016 and r260017 disabled typo correction for ivars and properties
> clang didn't report errors about unresolved identifier in the base of ivar
> and
> property ref expressions. This meant that clang invoked CodeGen on invalid
> AST
> which then caused a crash.
>
> This commit re-enables typo correction for ivars and properites, and fixes
> the
> PR25113 & PR26486 (that were originally fixed in r260017 and r260016) in a
> different manner by transforming the Objective-C ivar reference expression
> with
> 'IsFreeIvar' preserved.
>
> rdar://30310772
>
> Modified:
> cfe/trunk/lib/Sema/SemaExprCXX.cpp
> cfe/trunk/lib/Sema/TreeTransform.h
> cfe/trunk/test/SemaObjCXX/typo-correction.mm
>
> Modified: cfe/trunk/lib/Sema/SemaExprCXX.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/
> SemaExprCXX.cpp?rev=294008=294007=294008=diff
> 
> ==
> --- cfe/trunk/lib/Sema/SemaExprCXX.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaExprCXX.cpp Fri Feb  3 08:22:33 2017
> @@ -7250,14 +7250,6 @@ public:
>
>ExprResult TransformBlockExpr(BlockExpr *E) { return Owned(E); }
>
> -  ExprResult TransformObjCPropertyRefExpr(ObjCPropertyRefExpr *E) {
> -return Owned(E);
> -  }
> -
> -  ExprResult TransformObjCIvarRefExpr(ObjCIvarRefExpr *E) {
> -return Owned(E);
> -  }
> -
>ExprResult Transform(Expr *E) {
>  ExprResult Res;
>  while (true) {
>
> Modified: cfe/trunk/lib/Sema/TreeTransform.h
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/
> TreeTransform.h?rev=294008=294007=294008=diff
> 
> ==
> --- cfe/trunk/lib/Sema/TreeTransform.h (original)
> +++ cfe/trunk/lib/Sema/TreeTransform.h Fri Feb  3 08:22:33 2017
> @@ -2982,16 +2982,17 @@ public:
>ExprResult RebuildObjCIvarRefExpr(Expr *BaseArg, ObjCIvarDecl *Ivar,
>SourceLocation IvarLoc,
>bool IsArrow, bool IsFreeIvar) {
> -// FIXME: We lose track of the IsFreeIvar bit.
>  CXXScopeSpec SS;
>  DeclarationNameInfo NameInfo(Ivar->getDeclName(), IvarLoc);
> -return getSema().BuildMemberReferenceExpr(BaseArg,
> BaseArg->getType(),
> -  /*FIXME:*/IvarLoc, IsArrow,
> -  SS, SourceLocation(),
> -  /*FirstQualifierInScope=*/
> nullptr,
> -  NameInfo,
> -  /*TemplateArgs=*/nullptr,
> -  /*S=*/nullptr);
> +ExprResult Result = getSema().BuildMemberReferenceExpr(
> +BaseArg, BaseArg->getType(),
> +/*FIXME:*/ IvarLoc, IsArrow, SS, SourceLocation(),
> +/*FirstQualifierInScope=*/nullptr, NameInfo,
> +/*TemplateArgs=*/nullptr,
> +/*S=*/nullptr);
> +if (IsFreeIvar && Result.isUsable())
> +  cast(Result.get())->setIsFreeIvar(IsFreeIvar);
> +return Result;
>}
>
>/// \brief Build a new Objective-C property reference expression.
>
> Modified: cfe/trunk/test/SemaObjCXX/typo-correction.mm
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/
> SemaObjCXX/typo-correction.mm?rev=294008=294007=294008=diff
> 
> ==
> --- cfe/trunk/test/SemaObjCXX/typo-correction.mm (original)
> +++ cfe/trunk/test/SemaObjCXX/typo-correction.mm Fri Feb  3 08:22:33 2017
> @@ -21,3 +21,18 @@ public:
>self.m_prop2 = new ClassB(m_prop1); // expected-error {{use of
> undeclared identifier 'm_prop1'; did you mean '_m_prop1'?}}
>  }
>  @end
> +
> +// rdar://30310772
> +
> +@interface InvalidNameInIvarAndPropertyBase
> +{
> +@public
> +  float  _a;
> +}
> +@property float _b;
> +@end
> +
> +void invalidNameInIvarAndPropertyBase() {
> +  float a = ((InvalidNameInIvarAndPropertyBase*)node)->_a; //
> expected-error {{use of undeclared identifier 'node'}}
> +  float b = ((InvalidNameInIvarAndPropertyBase*)node)._b; //
> expected-error {{use of undeclared identifier 'node'}}
> +}
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___

Re: r293787 - [CodeGen][ObjC] Avoid asserting on block pointer types in

[Alex L via cfe-commits]

Thanks!

On 1 February 2017 at 18:57, Hans Wennborg  wrote:

> OK. Merged in r293797.
>
> Thanks,
> Hans
>
> On Wed, Feb 1, 2017 at 9:50 AM, Alex L  wrote:
> > Hi Hans,
> >
> > Would it be possible to merge this for 4.0?
> >
> > Cheers,
> > Alex
> >
> > On 1 February 2017 at 17:37, Alex Lorenz via cfe-commits
> >  wrote:
> >>
> >> Author: arphaman
> >> Date: Wed Feb  1 11:37:28 2017
> >> New Revision: 293787
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=293787=rev
> >> Log:
> >> [CodeGen][ObjC] Avoid asserting on block pointer types in
> >> isPointerZeroInitializable
> >>
> >> rdar://30111891
> >>
> >> Added:
> >> cfe/trunk/test/CodeGenObjC/block-ptr-type-crash.m
> >> Modified:
> >> cfe/trunk/lib/CodeGen/CodeGenTypes.cpp
> >>
> >> Modified: cfe/trunk/lib/CodeGen/CodeGenTypes.cpp
> >> URL:
> >> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/
> CodeGenTypes.cpp?rev=293787=293786=293787=diff
> >>
> >> 
> ==
> >> --- cfe/trunk/lib/CodeGen/CodeGenTypes.cpp (original)
> >> +++ cfe/trunk/lib/CodeGen/CodeGenTypes.cpp Wed Feb  1 11:37:28 2017
> >> @@ -738,7 +738,7 @@ CodeGenTypes::getCGRecordLayout(const Re
> >>  }
> >>
> >>  bool CodeGenTypes::isPointerZeroInitializable(QualType T) {
> >> -  assert (T->isAnyPointerType() && "Invalid type");
> >> +  assert((T->isAnyPointerType() || T->isBlockPointerType()) && "Invalid
> >> type");
> >>return isZeroInitializable(T);
> >>  }
> >>
> >>
> >> Added: cfe/trunk/test/CodeGenObjC/block-ptr-type-crash.m
> >> URL:
> >> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/
> CodeGenObjC/block-ptr-type-crash.m?rev=293787=auto
> >>
> >> 
> ==
> >> --- cfe/trunk/test/CodeGenObjC/block-ptr-type-crash.m (added)
> >> +++ cfe/trunk/test/CodeGenObjC/block-ptr-type-crash.m Wed Feb  1
> 11:37:28
> >> 2017
> >> @@ -0,0 +1,28 @@
> >> +// RUN: %clang_cc1 -Wno-objc-root-class -fblocks -o /dev/null -triple
> >> x86_64-- -emit-llvm %s
> >> +// REQUIRES: asserts
> >> +// Verify there is no assertion.
> >> +
> >> +// rdar://30111891
> >> +
> >> +typedef unsigned long long uint64_t;
> >> +typedef enum AnEnum : uint64_t AnEnum;
> >> +enum AnEnum: uint64_t {
> >> +AnEnumA
> >> +};
> >> +
> >> +typedef void (^BlockType)();
> >> +@interface MyClass
> >> +@end
> >> +@implementation MyClass
> >> +- (void)_doStuff {
> >> +  struct {
> >> +int identifier;
> >> +AnEnum type;
> >> +BlockType handler;
> >> +  } var = {
> >> +"hello",
> >> +AnEnumA,
> >> +((void *)0)
> >> +  };
> >> +}
> >> +@end
> >>
> >>
> >> ___
> >> 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: r293787 - [CodeGen][ObjC] Avoid asserting on block pointer types in

[Alex L via cfe-commits]

Hi Hans,

Would it be possible to merge this for 4.0?

Cheers,
Alex

On 1 February 2017 at 17:37, Alex Lorenz via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: arphaman
> Date: Wed Feb  1 11:37:28 2017
> New Revision: 293787
>
> URL: http://llvm.org/viewvc/llvm-project?rev=293787=rev
> Log:
> [CodeGen][ObjC] Avoid asserting on block pointer types in
> isPointerZeroInitializable
>
> rdar://30111891
>
> Added:
> cfe/trunk/test/CodeGenObjC/block-ptr-type-crash.m
> Modified:
> cfe/trunk/lib/CodeGen/CodeGenTypes.cpp
>
> Modified: cfe/trunk/lib/CodeGen/CodeGenTypes.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/
> CodeGenTypes.cpp?rev=293787=293786=293787=diff
> 
> ==
> --- cfe/trunk/lib/CodeGen/CodeGenTypes.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CodeGenTypes.cpp Wed Feb  1 11:37:28 2017
> @@ -738,7 +738,7 @@ CodeGenTypes::getCGRecordLayout(const Re
>  }
>
>  bool CodeGenTypes::isPointerZeroInitializable(QualType T) {
> -  assert (T->isAnyPointerType() && "Invalid type");
> +  assert((T->isAnyPointerType() || T->isBlockPointerType()) && "Invalid
> type");
>return isZeroInitializable(T);
>  }
>
>
> Added: cfe/trunk/test/CodeGenObjC/block-ptr-type-crash.m
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/
> CodeGenObjC/block-ptr-type-crash.m?rev=293787=auto
> 
> ==
> --- cfe/trunk/test/CodeGenObjC/block-ptr-type-crash.m (added)
> +++ cfe/trunk/test/CodeGenObjC/block-ptr-type-crash.m Wed Feb  1 11:37:28
> 2017
> @@ -0,0 +1,28 @@
> +// RUN: %clang_cc1 -Wno-objc-root-class -fblocks -o /dev/null -triple
> x86_64-- -emit-llvm %s
> +// REQUIRES: asserts
> +// Verify there is no assertion.
> +
> +// rdar://30111891
> +
> +typedef unsigned long long uint64_t;
> +typedef enum AnEnum : uint64_t AnEnum;
> +enum AnEnum: uint64_t {
> +AnEnumA
> +};
> +
> +typedef void (^BlockType)();
> +@interface MyClass
> +@end
> +@implementation MyClass
> +- (void)_doStuff {
> +  struct {
> +int identifier;
> +AnEnum type;
> +BlockType handler;
> +  } var = {
> +"hello",
> +AnEnumA,
> +((void *)0)
> +  };
> +}
> +@end
>
>
> ___
> 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: r293518 - [ASTMatchers] Sprinkle some constexpr on the global matcher constructors.

[Alex L via cfe-commits]

I've narrowed the problem down to the difference in the linkage type for
"clang::ast_matchers::recordDecl" between the module and non-module build:

Module:
@_ZN5clang12ast_matchersL10recordDeclE = external global
%"class.clang::ast_matchers::internal::VariadicDynCastAllOfMatcher.847",
align 1

Non-module:
@_ZN5clang12ast_matchersL10recordDeclE = internal constant
%"class.clang::ast_matchers::internal::VariadicDynCastAllOfMatcher.916"
undef, align 1, !dbg !7

On 1 February 2017 at 11:03, Alex L  wrote:

> Hi Benjamin,
>
> This commit has caused a linking in our stage 2 modules buildbot at
> http://lab.llvm.org:8080/green/job/clang-stage2-cmake-modulesRDA/.
> Specifically, after this commit 'clang-reorder-fields' gets the following
> linking error:
>
> FAILED: bin/clang-reorder-fields
> : && /Users/buildslave/jenkins/sharedspace/clang-stage2-cmake-modulesRDA@2
> /host-compiler/bin/clang++   -fPIC -fvisibility-inlines-hidden -Wall -W
> -Wno-unused-parameter -Wwrite-strings -Wcast-qual
> -Wmissing-field-initializers -pedantic -Wno-long-long
> -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor
> -Wstring-conversion -Werror=date-time -std=c++11 -fmodules
> -fmodules-cache-path=/Users/buildslave/jenkins/sharedspace/clang-stage2-
> cmake-modulesRDA@2/clang-build/module.cache -fcxx-modules -gmodules
> -fcolor-diagnostics -fno-common -Woverloaded-virtual -Wno-nested-anon-types
> -O2 -g -DNDEBUG -Wl,-search_paths_first -Wl,-headerpad_max_install_names
> -Wl,-dead_strip tools/clang/tools/extra/clang-reorder-fields/tool/
> CMakeFiles/clang-reorder-fields.dir/ClangReorderFields.cpp.o  -o
> bin/clang-reorder-fields  lib/libLLVMSupport.a lib/libclangBasic.a
> lib/libclangFrontend.a lib/libclangReorderFields.a lib/libclangRewrite.a
> lib/libclangTooling.a lib/libclangToolingCore.a lib/libclangIndex.a
> lib/libclangFrontend.a lib/libclangParse.a lib/libLLVMMCParser.a
> lib/libclangSerialization.a lib/libclangSema.a lib/libclangEdit.a
> lib/libclangAnalysis.a lib/libLLVMBitReader.a lib/libLLVMProfileData.a
> lib/libclangDriver.a lib/libLLVMOption.a lib/libclangASTMatchers.a
> lib/libclangFormat.a lib/libclangToolingCore.a lib/libclangRewrite.a
> lib/libclangAST.a lib/libclangLex.a lib/libclangBasic.a lib/libLLVMCore.a
> lib/libLLVMMC.a lib/libLLVMSupport.a -lcurses -lz -lm lib/libLLVMDemangle.a
> -Wl,-rpath,@loader_path/../lib && :
> Undefined symbols for architecture x86_64:
>   "clang::ast_matchers::recordDecl", referenced from:
>   clang::reorder_fields::(anonymous namespace)::ReorderingConsumer::
> HandleTranslationUnit(clang::ASTContext&) in libclangReorderFields.a(
> ReorderFieldsAction.cpp.o)
> ld: symbol(s) not found for architecture x86_64
>
> This might be a bug/regression in clang and modules since in my opinion
> the link should succeed. I've reverted your commit in r293759 while we are
> investigating.
>
> Thanks,
> Alex
>
>
> On 30 January 2017 at 18:20, Benjamin Kramer via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: d0k
>> Date: Mon Jan 30 12:20:00 2017
>> New Revision: 293518
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=293518=rev
>> Log:
>> [ASTMatchers] Sprinkle some constexpr on the global matcher constructors.
>>
>> This dramatically reduces the size of the global constructors we emit
>> for those variables in debug mode.
>>
>> Modified:
>> cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h
>>
>> Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/
>> ASTMatchers/ASTMatchersInternal.h?rev=293518=293517=
>> 293518=diff
>> 
>> ==
>> --- cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h (original)
>> +++ cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h Mon Jan 30
>> 12:20:00 2017
>> @@ -1459,7 +1459,7 @@ class VariadicDynCastAllOfMatcher
>>  : public VariadicFunction> Matcher,
>>makeDynCastAllOfComposite> TargetT>> {
>>  public:
>> -  VariadicDynCastAllOfMatcher() {}
>> +  constexpr VariadicDynCastAllOfMatcher() {}
>>  };
>>
>>  /// \brief A \c VariadicAllOfMatcher object is a variadic functor
>> that takes
>> @@ -1477,7 +1477,7 @@ class VariadicAllOfMatcher
>>  : public VariadicFunction>makeAllOfComposite> {
>>  public:
>> -  VariadicAllOfMatcher() {}
>> +  constexpr VariadicAllOfMatcher() {}
>>  };
>>
>>  /// \brief Matches nodes of type \c TLoc for which the inner
>> @@ -1598,7 +1598,7 @@ public:
>>
>>struct Func
>>: public VariadicFunction> ::create> {
>> -Func() {}
>> +constexpr Func() {}
>>};
>>
>>  private:
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> 

Re: r293518 - [ASTMatchers] Sprinkle some constexpr on the global matcher constructors.

[Alex L via cfe-commits]

Hi Benjamin,

This commit has caused a linking in our stage 2 modules buildbot at
http://lab.llvm.org:8080/green/job/clang-stage2-cmake-modulesRDA/.
Specifically, after this commit 'clang-reorder-fields' gets the following
linking error:

FAILED: bin/clang-reorder-fields
: && 
/Users/buildslave/jenkins/sharedspace/clang-stage2-cmake-modulesRDA@2/host-compiler/bin/clang++
  -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter
-Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic
-Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor
-Wdelete-non-virtual-dtor -Wstring-conversion -Werror=date-time -std=c++11
-fmodules
-fmodules-cache-path=/Users/buildslave/jenkins/sharedspace/clang-stage2-cmake-modulesRDA@2/clang-build/module.cache
-fcxx-modules -gmodules -fcolor-diagnostics -fno-common
-Woverloaded-virtual -Wno-nested-anon-types -O2 -g -DNDEBUG
-Wl,-search_paths_first -Wl,-headerpad_max_install_names -Wl,-dead_strip
tools/clang/tools/extra/clang-reorder-fields/tool/CMakeFiles/clang-reorder-fields.dir/ClangReorderFields.cpp.o
 -o bin/clang-reorder-fields  lib/libLLVMSupport.a lib/libclangBasic.a
lib/libclangFrontend.a lib/libclangReorderFields.a lib/libclangRewrite.a
lib/libclangTooling.a lib/libclangToolingCore.a lib/libclangIndex.a
lib/libclangFrontend.a lib/libclangParse.a lib/libLLVMMCParser.a
lib/libclangSerialization.a lib/libclangSema.a lib/libclangEdit.a
lib/libclangAnalysis.a lib/libLLVMBitReader.a lib/libLLVMProfileData.a
lib/libclangDriver.a lib/libLLVMOption.a lib/libclangASTMatchers.a
lib/libclangFormat.a lib/libclangToolingCore.a lib/libclangRewrite.a
lib/libclangAST.a lib/libclangLex.a lib/libclangBasic.a lib/libLLVMCore.a
lib/libLLVMMC.a lib/libLLVMSupport.a -lcurses -lz -lm lib/libLLVMDemangle.a
-Wl,-rpath,@loader_path/../lib && :
Undefined symbols for architecture x86_64:
  "clang::ast_matchers::recordDecl", referenced from:
  clang::reorder_fields::(anonymous
namespace)::ReorderingConsumer::HandleTranslationUnit(clang::ASTContext&)
in libclangReorderFields.a(ReorderFieldsAction.cpp.o)
ld: symbol(s) not found for architecture x86_64

This might be a bug/regression in clang and modules since in my opinion the
link should succeed. I've reverted your commit in r293759 while we are
investigating.

Thanks,
Alex


On 30 January 2017 at 18:20, Benjamin Kramer via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: d0k
> Date: Mon Jan 30 12:20:00 2017
> New Revision: 293518
>
> URL: http://llvm.org/viewvc/llvm-project?rev=293518=rev
> Log:
> [ASTMatchers] Sprinkle some constexpr on the global matcher constructors.
>
> This dramatically reduces the size of the global constructors we emit
> for those variables in debug mode.
>
> Modified:
> cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h
>
> Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/ASTMatchers/ASTMatchersInternal.h?rev=293518=293517=293518&
> view=diff
> 
> ==
> --- cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h (original)
> +++ cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h Mon Jan 30
> 12:20:00 2017
> @@ -1459,7 +1459,7 @@ class VariadicDynCastAllOfMatcher
>  : public VariadicFunctionmakeDynCastAllOfComposite TargetT>> {
>  public:
> -  VariadicDynCastAllOfMatcher() {}
> +  constexpr VariadicDynCastAllOfMatcher() {}
>  };
>
>  /// \brief A \c VariadicAllOfMatcher object is a variadic functor that
> takes
> @@ -1477,7 +1477,7 @@ class VariadicAllOfMatcher
>  : public VariadicFunctionmakeAllOfComposite> {
>  public:
> -  VariadicAllOfMatcher() {}
> +  constexpr VariadicAllOfMatcher() {}
>  };
>
>  /// \brief Matches nodes of type \c TLoc for which the inner
> @@ -1598,7 +1598,7 @@ public:
>
>struct Func
>: public VariadicFunction
> {
> -Func() {}
> +constexpr Func() {}
>};
>
>  private:
>
>
> ___
> 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: r293343 - [ubsan] Sanity-check shift amounts before truncation (fixes PR27271)

[Alex L via cfe-commits]

Hi Vedant,

This commit has caused a compiler crash in our stage 2 green dragon
ASAN+Ubsan bot (
http://lab.llvm.org:8080/green/job/clang-stage2-cmake-RgSan_build/). I have
reverted it in r293475. The following example reproduces the crash with
-fsanitize=undefined :

  typedef unsigned long long uint64_t;
  typedef signed long long int64_t;

  uint64_t foo(int64_t x, unsigned i) {
   return x << i;
  }

Alex


On 27 January 2017 at 23:02, Vedant Kumar via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: vedantk
> Date: Fri Jan 27 17:02:44 2017
> New Revision: 293343
>
> URL: http://llvm.org/viewvc/llvm-project?rev=293343=rev
> Log:
> [ubsan] Sanity-check shift amounts before truncation (fixes PR27271)
>
> Ubsan does not report UB shifts in some cases where the shift exponent
> needs to be truncated to match the type of the shift base. We perform a
> range check on the truncated shift amount, leading to false negatives.
>
> Fix the issue (PR27271) by performing the range check on the original
> shift amount.
>
> Differential Revision: https://reviews.llvm.org/D29234
>
> Added:
> cfe/trunk/test/CodeGen/ubsan-shift.c
> Modified:
> cfe/trunk/lib/CodeGen/CGExprScalar.cpp
>
> Modified: cfe/trunk/lib/CodeGen/CGExprScalar.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/
> CGExprScalar.cpp?rev=293343=293342=293343=diff
> 
> ==
> --- cfe/trunk/lib/CodeGen/CGExprScalar.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGExprScalar.cpp Fri Jan 27 17:02:44 2017
> @@ -2751,8 +2751,8 @@ Value *ScalarExprEmitter::EmitShl(const
> isa(Ops.LHS->getType())) {
>  CodeGenFunction::SanitizerScope SanScope();
>  SmallVector Checks;
> -llvm::Value *WidthMinusOne = GetWidthMinusOneValue(Ops.LHS, RHS);
> -llvm::Value *ValidExponent = Builder.CreateICmpULE(RHS,
> WidthMinusOne);
> +llvm::Value *WidthMinusOne = GetWidthMinusOneValue(Ops.LHS, Ops.RHS);
> +llvm::Value *ValidExponent = Builder.CreateICmpULE(Ops.RHS,
> WidthMinusOne);
>
>  if (SanitizeExponent) {
>Checks.push_back(
>
> Added: cfe/trunk/test/CodeGen/ubsan-shift.c
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/
> CodeGen/ubsan-shift.c?rev=293343=auto
> 
> ==
> --- cfe/trunk/test/CodeGen/ubsan-shift.c (added)
> +++ cfe/trunk/test/CodeGen/ubsan-shift.c Fri Jan 27 17:02:44 2017
> @@ -0,0 +1,29 @@
> +// RUN: %clang_cc1 -triple=x86_64-apple-darwin -fsanitize=shift-exponent
> -emit-llvm %s -o - | FileCheck %s
> +
> +// CHECK-LABEL: define i32 @f1
> +int f1(int c, int shamt) {
> +// CHECK: icmp ule i32 %{{.*}}, 31, !nosanitize
> +// CHECK: icmp ule i32 %{{.*}}, 31, !nosanitize
> +  return 1 << (c << shamt);
> +}
> +
> +// CHECK-LABEL: define i32 @f2
> +int f2(long c, int shamt) {
> +// CHECK: icmp ule i32 %{{.*}}, 63, !nosanitize
> +// CHECK: icmp ule i64 %{{.*}}, 31, !nosanitize
> +  return 1 << (c << shamt);
> +}
> +
> +// CHECK-LABEL: define i32 @f3
> +unsigned f3(unsigned c, int shamt) {
> +// CHECK: icmp ule i32 %{{.*}}, 31, !nosanitize
> +// CHECK: icmp ule i32 %{{.*}}, 31, !nosanitize
> +  return 1U << (c << shamt);
> +}
> +
> +// CHECK-LABEL: define i32 @f4
> +unsigned f4(unsigned long c, int shamt) {
> +// CHECK: icmp ule i32 %{{.*}}, 63, !nosanitize
> +// CHECK: icmp ule i64 %{{.*}}, 31, !nosanitize
> +  return 1U << (c << shamt);
> +}
>
>
> ___
> 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: r292497 - [Sema] Fix PR28181 by avoiding calling BuildOverloadedBinOp in C mode

[Alex L via cfe-commits]

Hi Hans,

Would it be possible to merge this for 4.0?

Cheers,
Alex

On 19 January 2017 at 17:17, Alex Lorenz via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: arphaman
> Date: Thu Jan 19 11:17:57 2017
> New Revision: 292497
>
> URL: http://llvm.org/viewvc/llvm-project?rev=292497=rev
> Log:
> [Sema] Fix PR28181 by avoiding calling BuildOverloadedBinOp in C mode
>
> rdar://28532840
>
> Differential Revision: https://reviews.llvm.org/D25213
>
> Added:
> cfe/trunk/test/Sema/PR28181.c
> Modified:
> cfe/trunk/lib/Sema/SemaExpr.cpp
>
> Modified: cfe/trunk/lib/Sema/SemaExpr.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaE
> xpr.cpp?rev=292497=292496=292497=diff
> 
> ==
> --- cfe/trunk/lib/Sema/SemaExpr.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaExpr.cpp Thu Jan 19 11:17:57 2017
> @@ -11505,7 +11505,7 @@ ExprResult Sema::BuildBinOp(Scope *S, So
>return checkPseudoObjectAssignment(S, OpLoc, Opc, LHSExpr, RHSExpr);
>
>  // Don't resolve overloads if the other type is overloadable.
> -if (pty->getKind() == BuiltinType::Overload) {
> +if (getLangOpts().CPlusPlus && pty->getKind() ==
> BuiltinType::Overload) {
>// We can't actually test that if we still have a placeholder,
>// though.  Fortunately, none of the exceptions we see in that
>// code below are valid when the LHS is an overload set.  Note
> @@ -11530,17 +11530,16 @@ ExprResult Sema::BuildBinOp(Scope *S, So
>  // An overload in the RHS can potentially be resolved by the type
>  // being assigned to.
>  if (Opc == BO_Assign && pty->getKind() == BuiltinType::Overload) {
> -  if (LHSExpr->isTypeDependent() || RHSExpr->isTypeDependent())
> -return BuildOverloadedBinOp(*this, S, OpLoc, Opc, LHSExpr,
> RHSExpr);
> -
> -  if (LHSExpr->getType()->isOverloadableType())
> +  if (getLangOpts().CPlusPlus &&
> +  (LHSExpr->isTypeDependent() || RHSExpr->isTypeDependent() ||
> +   LHSExpr->getType()->isOverloadableType()))
>  return BuildOverloadedBinOp(*this, S, OpLoc, Opc, LHSExpr,
> RHSExpr);
>
>return CreateBuiltinBinOp(OpLoc, Opc, LHSExpr, RHSExpr);
>  }
>
>  // Don't resolve overloads if the other type is overloadable.
> -if (pty->getKind() == BuiltinType::Overload &&
> +if (getLangOpts().CPlusPlus && pty->getKind() ==
> BuiltinType::Overload &&
>  LHSExpr->getType()->isOverloadableType())
>return BuildOverloadedBinOp(*this, S, OpLoc, Opc, LHSExpr, RHSExpr);
>
>
> Added: cfe/trunk/test/Sema/PR28181.c
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/PR28
> 181.c?rev=292497=auto
> 
> ==
> --- cfe/trunk/test/Sema/PR28181.c (added)
> +++ cfe/trunk/test/Sema/PR28181.c Thu Jan 19 11:17:57 2017
> @@ -0,0 +1,13 @@
> +// RUN: %clang_cc1 -fsyntax-only -verify %s
> +
> +struct spinlock_t {
> +  int lock;
> +} audit_skb_queue;
> +
> +void fn1() {
> +  audit_skb_queue = (lock); // expected-error {{use of undeclared
> identifier 'lock'; did you mean 'long'?}}
> +}   // expected-error@-1 {{assigning to 'struct
> spinlock_t' from incompatible type ''}}
> +
> +void fn2() {
> +  audit_skb_queue + (lock); // expected-error {{use of undeclared
> identifier 'lock'; did you mean 'long'?}}
> +}   // expected-error@-1 {{reference to
> overloaded function could not be resolved; did you mean to call it?}}
>
>
> ___
> 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] Add missing Decl::Kind for -print-decl-contexts

[Alex L via cfe-commits]

Thanks for working on this patch! I'm sorry to say but I had an earlier
patch in review that fixes this issue (https://reviews.llvm.org/D26964). I
think my patch covers all of the decl kinds that are fixed by this patch. I
plan on committing my patch today.

Alex

On 29 December 2016 at 23:35, Fangrui Song via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> ---
>  lib/Frontend/ASTConsumers.cpp | 37 -
>  1 file changed, 32 insertions(+), 5 deletions(-)
>
> diff --git a/lib/Frontend/ASTConsumers.cpp b/lib/Frontend/ASTConsumers.cpp
> index bd2ee06d16..987b8ca398 100644
> --- a/lib/Frontend/ASTConsumers.cpp
> +++ b/lib/Frontend/ASTConsumers.cpp
> @@ -405,6 +405,22 @@ void DeclContextPrinter::PrintDeclContext(const
> DeclContext* DC,
>PrintDeclContext(DC, Indentation+2);
>break;
>  }
> +case Decl::AccessSpec: {
> +  Out << "\n";
> +  break;
> +}
> +case Decl::ClassTemplate: {
> +  Out << " " << *cast(I) << '\n';
> +  break;
> +}
> +case Decl::ClassTemplateSpecialization: {
> +  Out << " " << *cast<
> ClassTemplateSpecializationDecl>(I) << '\n';
> +  break;
> +}
> +case Decl::ClassTemplatePartialSpecialization: {
> +  Out << " " << *cast<
> ClassTemplatePartialSpecializationDecl>(I) << '\n';
> +  break;
> +}
>  case Decl::IndirectField: {
>IndirectFieldDecl* IFD = cast(I);
>Out << " " << *IFD << '\n';
> @@ -420,6 +436,10 @@ void DeclContextPrinter::PrintDeclContext(const
> DeclContext* DC,
>Out << " " << *FD << '\n';
>break;
>  }
> +case Decl::Friend: {
> +  Out << "\n";
> +  break;
> +}
>  case Decl::Typedef:
>  case Decl::TypeAlias: {
>TypedefNameDecl* TD = cast(I);
> @@ -460,6 +480,14 @@ void DeclContextPrinter::PrintDeclContext(const
> DeclContext* DC,
>Out << "\n";
>break;
>  }
> +case Decl::Using: {
> +  Out << " " << *cast(I) << '\n';
> +  break;
> +}
> +case Decl::UsingShadow: {
> +  Out << " " << *cast(I) << '\n';
> +  break;
> +}
>  case Decl::UsingDirective: {
>Out << "\n";
>break;
> @@ -469,15 +497,14 @@ void DeclContextPrinter::PrintDeclContext(const
> DeclContext* DC,
>Out << " " << *NAD << '\n';
>break;
>  }
> -case Decl::ClassTemplate: {
> -  ClassTemplateDecl *CTD = cast(I);
> -  Out << " " << *CTD << '\n';
> -  break;
> -}
>  case Decl::OMPThreadPrivate: {
>Out << " " << '"' << I << "\"\n";
>break;
>  }
> +case Decl::VarTemplate: {
> +  Out << " " << *cast(I) << '\n';
> +  break;
> +}
>  default:
>Out << "DeclKind: " << DK << '"' << I << "\"\n";
>llvm_unreachable("decl unhandled");
> --
> 2.11.0
>
> ___
> 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: r288689 - Fix stack-use-after-scope in CheckExplicitlyDefaultedMemberExceptionSpec

[Alex L via cfe-commits]

On 6 December 2016 at 19:39, Vitaly Buka  wrote:

> Hi Alex,
>
>
>
> On Tue, Dec 6, 2016 at 11:14 AM Alex L  wrote:
>
> Hi Vitaly,
>
> I noticed that you posted this patch up for review at
> https://reviews.llvm.org/D27422, but then committed it instantly without
> waiting for approval (and you did the same for r288685 as well). Is there
> any particular reason why you did this? I think that you should've waited
> for approval before committing.
>
>
> We had broken build bots, so seem like this trivial change is better than
> reverting patches.
> No.3 of http://llvm.org/docs/DeveloperPolicy.html#code-reviews allows
> after commit review for changes like this.
>

Thanks for the clarification. Yes, the developer policy states that you can
commit small changes and get them reviewed after committing, so a commit
like this would've been perfect for a post-commit review. However, it also
says that "Specifically, once a patch is sent out for review, it needs an
explicit “looks good” before it is submitted". Please avoid submitting
patches for review if you know that you will commit them without waiting
for approval in the future.


>
>
> This patch is pretty small, and so it looks to me like it could have been
> reviewed after it was committed, but patches that get post-commit reviews
> shouldn't get explicit review requests like this one did.
>
>
> Sorry, probably I did the same few time before. I can't find exact details
> in the policy, but I assumed that was a reasonable approach.
> So what is the process for after commit review?
>

People usually read the commit logs and check which commits need
post-commit reviews, and then look at them. There's no need for an explicit
review request for commits like this.


>
>
>
> Alex
>
> On 5 December 2016 at 19:25, Vitaly Buka via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
> Author: vitalybuka
> Date: Mon Dec  5 13:25:00 2016
> New Revision: 288689
>
> URL: http://llvm.org/viewvc/llvm-project?rev=288689=rev
> Log:
> Fix stack-use-after-scope in CheckExplicitlyDefaultedMemberExceptionSpec
>
> Summary:
> Similar to r288685.
> getExceptionSpec returned structure with pointers to temporarily object
> created
> by computeImplicitExceptionSpec.
>
> Reviewers: rsmith
>
> Subscribers: aizatsky, cfe-commits
>
> Differential Revision: https://reviews.llvm.org/D27422
>
> Modified:
> cfe/trunk/lib/Sema/SemaDeclCXX.cpp
>
> Modified: cfe/trunk/lib/Sema/SemaDeclCXX.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/
> SemaDeclCXX.cpp?rev=288689=288688=288689=diff
> 
> ==
> --- cfe/trunk/lib/Sema/SemaDeclCXX.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaDeclCXX.cpp Mon Dec  5 13:25:00 2016
> @@ -6299,8 +6299,8 @@ void Sema::CheckExplicitlyDefaultedMembe
>CallingConv CC = Context.getDefaultCallingConvention(/*
> IsVariadic=*/false,
>
> /*IsCXXMethod=*/true);
>FunctionProtoType::ExtProtoInfo EPI(CC);
> -  EPI.ExceptionSpec = computeImplicitExceptionSpec(*this,
> MD->getLocation(), MD)
> -  .getExceptionSpec();
> +  auto IES = computeImplicitExceptionSpec(*this, MD->getLocation(), MD);
> +  EPI.ExceptionSpec = IES.getExceptionSpec();
>const FunctionProtoType *ImplicitType = cast(
>  Context.getFunctionType(Context.VoidTy, None, EPI));
>
>
>
> ___
> 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: r288689 - Fix stack-use-after-scope in CheckExplicitlyDefaultedMemberExceptionSpec

[Alex L via cfe-commits]

Hi Vitaly,

I noticed that you posted this patch up for review at
https://reviews.llvm.org/D27422, but then committed it instantly without
waiting for approval (and you did the same for r288685 as well). Is there
any particular reason why you did this? I think that you should've waited
for approval before committing. This patch is pretty small, and so it looks
to me like it could have been reviewed after it was committed, but patches
that get post-commit reviews shouldn't get explicit review requests like
this one did.

Alex

On 5 December 2016 at 19:25, Vitaly Buka via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: vitalybuka
> Date: Mon Dec  5 13:25:00 2016
> New Revision: 288689
>
> URL: http://llvm.org/viewvc/llvm-project?rev=288689=rev
> Log:
> Fix stack-use-after-scope in CheckExplicitlyDefaultedMemberExceptionSpec
>
> Summary:
> Similar to r288685.
> getExceptionSpec returned structure with pointers to temporarily object
> created
> by computeImplicitExceptionSpec.
>
> Reviewers: rsmith
>
> Subscribers: aizatsky, cfe-commits
>
> Differential Revision: https://reviews.llvm.org/D27422
>
> Modified:
> cfe/trunk/lib/Sema/SemaDeclCXX.cpp
>
> Modified: cfe/trunk/lib/Sema/SemaDeclCXX.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/
> SemaDeclCXX.cpp?rev=288689=288688=288689=diff
> 
> ==
> --- cfe/trunk/lib/Sema/SemaDeclCXX.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaDeclCXX.cpp Mon Dec  5 13:25:00 2016
> @@ -6299,8 +6299,8 @@ void Sema::CheckExplicitlyDefaultedMembe
>CallingConv CC = Context.getDefaultCallingConvention(/*
> IsVariadic=*/false,
>
> /*IsCXXMethod=*/true);
>FunctionProtoType::ExtProtoInfo EPI(CC);
> -  EPI.ExceptionSpec = computeImplicitExceptionSpec(*this,
> MD->getLocation(), MD)
> -  .getExceptionSpec();
> +  auto IES = computeImplicitExceptionSpec(*this, MD->getLocation(), MD);
> +  EPI.ExceptionSpec = IES.getExceptionSpec();
>const FunctionProtoType *ImplicitType = cast(
>  Context.getFunctionType(Context.VoidTy, None, EPI));
>
>
>
> ___
> 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: [RFC] Embedded bitcode and related upstream (Part II)

[Alex L via cfe-commits]

On 30 November 2016 at 15:46, Nico Weber via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Hi Steven,
>
> On Fri, Jun 3, 2016 at 2:36 PM, Steven Wu via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Hi everyone
>>
>> I am still in the process of upstreaming some improvements to the embed
>> bitcode option. If you want more background, you can read the previous RFC (
>> http://lists.llvm.org/pipermail/llvm-dev/2016-February/094851.html).
>> This is part II of the discussion.
>>
>> Current Status:
>> A basic version of -fembed-bitcode option is upstreamed and functioning.
>> You can use -fembed-bitcode={off, all, bitcode, marker} option to control
>> what gets embedded in the final object file output:
>> off: default, nothing gets embedded.
>> all: optimized bitcode and command line options gets embedded in the
>> object file.
>> bitcode: only optimized bitcode is embedded
>> marker: only put a marker in the object file
>>
>> What needs to be improved:
>> 1. Whitelist for command line options that can be used with bitcode:
>> Current trunk implementation embeds all the cc1 command line options
>> (that includes header include paths, warning flags and other front-end
>> options) in the command line section. That is lot of redundant information.
>> To re-create the object file from the embedded optimized bitcode, most of
>> these options are useless. On the other hand, they can leak information of
>> the source code. One solution will be keeping a list of all the options
>> that can affect code generation but not encoded in the bitcode. I have
>> internally prototyped with disallowing these options explicitly and allowed
>> only the reminder of the  options to be embedded (
>> http://reviews.llvm.org/D17394). A better solution might be encoding
>> that information in "Options.td" as specific group.
>>
>> 2. Assembly input handling:
>> This is a workaround to allow source code written in assembly to work
>> with "-fembed-bitcode" options. When compiling assembly source code with
>> "-fembed-bitcode", clang-as creates an empty section "__LLVM, __asm" in the
>> object file. That is just a way to distinguish object files compiled from
>> assembly source from those compiled from higher level source code but
>> forgot to use "-fembed-bitcode" options. Linker can use this section to
>> diagnose if "-fembed-bitcode" is consistently used on all the object files
>> participated in the linking.
>>
>
> It looks like shipping Xcode's clang has this behavior, but open-source
> clang still doesn't. Can you contribute it? It's very useful to us if
> open-source clang has the same features as the clang shipping in Xcode.
> (That last sentence is true in general, not just for this specific feature.)
>

Just FYI, Steven is away on vacation for a month. I think he should be back
in January.


>
>
>>
>> 3. Bitcode symbol hiding:
>> There was some concerns for leaking source code information when using
>> bitcode feature. One approach to avoid the leak is to add a pass which
>> renames all the globals and metadata strings. The also keeps a reverse map
>> in case the original name needs to be recovered. The final bitcode should
>> contain no more symbols or debug info than a stripped binary. To make sure
>> modified bitcode can still be linked correctly, the renaming need to be
>> consistent across all bitcode participated in the linking and everything
>> that is external of the linkage unit need to be preserved. This means the
>> pass can only be run during the linking and requires some LTO api.
>>
>> 4. Debug info strip to line-tables pass:
>> As the name suggested, this pass strip down the full debug info to
>> line-tables only. This is also one of the steps we took to prevent the leak
>> of source code information in bitcode.
>>
>> Please let me know what do you think about the pieces above or if you
>> have any concerns about the methodology. I will put up patches for review
>> soon.
>>
>> Thanks
>>
>> Steven
>>
>> ___
>> 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: [libcxx] r287435 - Fix stdint/cstdint modules

[Alex L via cfe-commits]

Hello Eric,

I think that this commit (r287435) might have broken the green dragon stage
2 ASAN + UBSAN buildbot:

http://lab.llvm.org:8080/green/job/clang-stage2-cmake-RgSan_check/2643/

I'm not sure why exactly the tests fail, since ASAN/UBSAN isn't triggering
anything, and it's just a module error. The other bots have passed these
tests successfully. Do you happen to know what might be causing the test
failures?

Thanks,
Alex

On 19 November 2016 at 03:29, Eric Fiselier via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: ericwf
> Date: Fri Nov 18 21:29:03 2016
> New Revision: 287435
>
> URL: http://llvm.org/viewvc/llvm-project?rev=287435=rev
> Log:
> Fix stdint/cstdint modules
>
> Added:
> libcxx/trunk/test/libcxx/modules/cinttypes_exports.sh.cpp
> libcxx/trunk/test/libcxx/modules/cstdint_exports.sh.cpp
> libcxx/trunk/test/libcxx/modules/inttypes_h_exports.sh.cpp
> libcxx/trunk/test/libcxx/modules/stdint_h_exports.sh.cpp
> Modified:
> libcxx/trunk/include/module.modulemap
>
> Modified: libcxx/trunk/include/module.modulemap
> URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/
> module.modulemap?rev=287435=287434=287435=diff
> 
> ==
> --- libcxx/trunk/include/module.modulemap (original)
> +++ libcxx/trunk/include/module.modulemap Fri Nov 18 21:29:03 2016
> @@ -21,47 +21,20 @@ module std [system] {
>  module inttypes_h {
>header "inttypes.h"
>export stdint_h
> -/*
> -  export_macros
> -PRId8, PRId16, PRId32, PRId64, PRIdFAST8, PRIdFAST16, PRIdFAST32,
> PRIdFAST64, PRIdLEAST8, PRIdLEAST16, PRIdLEAST32, PRIdLEAST64, PRIdMAX,
> PRIdPTR,
> -PRIi8, PRIi16, PRIi32, PRIi64, PRIiFAST8, PRIiFAST16, PRIiFAST32,
> PRIiFAST64, PRIiLEAST8, PRIiLEAST16, PRIiLEAST32, PRIiLEAST64, PRIiMAX,
> PRIiPTR,
> -PRIo8, PRIo16, PRIo32, PRIo64, PRIoFAST8, PRIoFAST16, PRIoFAST32,
> PRIoFAST64, PRIoLEAST8, PRIoLEAST16, PRIoLEAST32, PRIoLEAST64, PRIoMAX,
> PRIoPTR,
> -PRIu8, PRIu16, PRIu32, PRIu64, PRIuFAST8, PRIuFAST16, PRIuFAST32,
> PRIuFAST64, PRIuLEAST8, PRIuLEAST16, PRIuLEAST32, PRIuLEAST64, PRIuMAX,
> PRIuPTR,
> -PRIx8, PRIx16, PRIx32, PRIx64, PRIxFAST8, PRIxFAST16, PRIxFAST32,
> PRIxFAST64, PRIxLEAST8, PRIxLEAST16, PRIxLEAST32, PRIxLEAST64, PRIxMAX,
> PRIxPTR,
> -PRIX8, PRIX16, PRIX32, PRIX64, PRIXFAST8, PRIXFAST16, PRIXFAST32,
> PRIXFAST64, PRIXLEAST8, PRIXLEAST16, PRIXLEAST32, PRIXLEAST64, PRIXMAX,
> PRIXPTR,
> -SCNd8, SCNd16, SCNd32, SCNd64, SCNdFAST8, SCNdFAST16, SCNdFAST32,
> SCNdFAST64, SCNdLEAST8, SCNdLEAST16, SCNdLEAST32, SCNdLEAST64, SCNdMAX,
> SCNdPTR,
> -SCNi8, SCNi16, SCNi32, SCNi64, SCNiFAST8, SCNiFAST16, SCNiFAST32,
> SCNiFAST64, SCNiLEAST8, SCNiLEAST16, SCNiLEAST32, SCNiLEAST64, SCNiMAX,
> SCNiPTR,
> -SCNo8, SCNo16, SCNo32, SCNo64, SCNoFAST8, SCNoFAST16, SCNoFAST32,
> SCNoFAST64, SCNoLEAST8, SCNoLEAST16, SCNoLEAST32, SCNoLEAST64, SCNoMAX,
> SCNoPTR,
> -SCNu8, SCNu16, SCNu32, SCNu64, SCNuFAST8, SCNuFAST16, SCNuFAST32,
> SCNuFAST64, SCNuLEAST8, SCNuLEAST16, SCNuLEAST32, SCNuLEAST64, SCNuMAX,
> SCNuPTR,
> -SCNx8, SCNx16, SCNx32, SCNx64, SCNxFAST8, SCNxFAST16, SCNxFAST32,
> SCNxFAST64, SCNxLEAST8, SCNxLEAST16, SCNxLEAST32, SCNxLEAST64, SCNxMAX,
> SCNxPTR,
> -SCNX8, SCNX16, SCNX32, SCNX64, SCNXFAST8, SCNXFAST16, SCNXFAST32,
> SCNXFAST64, SCNXLEAST8, SCNXLEAST16, SCNXLEAST32, SCNXLEAST64, SCNXMAX,
> SCNXPTR
> -*/
>export *
>  }
>  //  provided by compiler.
>  //  provided by compiler or C library.
>  module locale_h {
>header "locale.h"
> -/*
> -  export_macros LC_ALL LC_COLLATE LC_CTYPE LC_MONETARY LC_NUMERIC
> LC_TIME
> -*/
>export *
>  }
>  module math_h {
>header "math.h"
> -/*
> -  export_macros FP_FAST_FMA, FP_FAST_FMAF, FP_FAST_FMAL, FP_ILOGBO,
> FP_ILOGBNAN,
> -FP_INFINITE, FP_NAN, FP_NORMAL, FP_SUBNORMAL, FP_ZERO,
> -HUGE_VAL, HUGE_VALF, HUGE_VALL, INFINITY, NAN,
> -MATH_ERRNO, MATH_ERREXCEPT, math_errhandling
> -*/
>export *
>  }
>  module setjmp_h {
>header "setjmp.h"
> -/*
> -  export_macros setjmp
> -*/
>export *
>  }
>  // FIXME:  is missing.
> @@ -72,30 +45,22 @@ module std [system] {
>// 's __need_* macros require textual inclusion.
>textual header "stddef.h"
>  }
> -//  provided by compiler or C library.
> +module stdint_h {
> +  header "stdint.h"
> +  export *
> +}
>  module stdio_h {
>// 's __need_* macros require textual inclusion.
>textual header "stdio.h"
> -/*
> -  export_macros BUFSIZ, EOF, FILENAME_MAX, FOPEN_MAX, L_tmpnam, NULL,
> -SEEK_CUR, SEEK_END, SEEK_SET, TMP_MAX, _IOFBF, _IOLBF,
> -stdin, stdout, stderr
> -*/
>export *
>  }
>  module stdlib_h {
>// 's __need_* 

Re: [PATCH] D25816: Use descriptive message if list initializer is incorrectly parenthesized.

[Alex L via cfe-commits]

I think you can go ahead and commit it, yes.

Alex

On 11 November 2016 at 05:28, Serge Pavlov  wrote:

> Is it OK to commit this patch?
>
> Thanks,
> --Serge
>
> 2016-10-21 18:21 GMT+07:00 Alex Lorenz :
>
>> arphaman added a subscriber: rsmith.
>> arphaman added a comment.
>>
>> LGTM, I added Richard in case he has something to add.
>>
>> > I chose to retain current clang behavior and reject questionable code.
>> GCC patch that introduced this message explains using warning by some
>> uncertainty, 5 years passed, I think the standard is stable in viewpoint on
>> such usage.
>>
>> Thanks for the detailed explanation, I wasn't sure if GCC's was behaving
>> according to the standard or not.
>>
>>
>> https://reviews.llvm.org/D25816
>>
>>
>>
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits