Page MenuHomePhabricator
Feed Advanced Search

Yesterday

erik.pilkington updated the diff for D62825: [C++2a] Add __builtin_bit_cast, used to implement std::bit_cast.

Address review comments.

Mon, Jun 24, 2:47 PM · Restricted Project, Restricted Project
erik.pilkington added inline comments to D62825: [C++2a] Add __builtin_bit_cast, used to implement std::bit_cast.
Mon, Jun 24, 2:47 PM · Restricted Project, Restricted Project

Wed, Jun 19

erik.pilkington added inline comments to D62825: [C++2a] Add __builtin_bit_cast, used to implement std::bit_cast.
Wed, Jun 19, 4:54 PM · Restricted Project, Restricted Project
erik.pilkington updated the diff for D62825: [C++2a] Add __builtin_bit_cast, used to implement std::bit_cast.

Address review comments, thanks!

Wed, Jun 19, 4:54 PM · Restricted Project, Restricted Project
erik.pilkington added inline comments to D62960: SVE opaque type for C intrinsics demo.
Wed, Jun 19, 11:04 AM · Restricted Project

Tue, Jun 18

erik.pilkington committed rGcf8c6cfcdc82: [demangle] Special case clang's creative mangling of __uuidof expressions. (authored by erik.pilkington).
[demangle] Special case clang's creative mangling of __uuidof expressions.
Tue, Jun 18, 4:32 PM

Thu, Jun 13

erik.pilkington added a comment to D62825: [C++2a] Add __builtin_bit_cast, used to implement std::bit_cast.

Can we also use the same bit reader/writer implementation to generalize the current implementation of __builtin_memcpy and friends? (I don't think we can remove the existing implementation, sadly, since we allow copying arrays of the same trivially-copyable type today even if it contains pointers and unions and such.)

Thu, Jun 13, 12:43 PM · Restricted Project, Restricted Project
erik.pilkington updated the diff for D62825: [C++2a] Add __builtin_bit_cast, used to implement std::bit_cast.

Address review comments.

Thu, Jun 13, 12:43 PM · Restricted Project, Restricted Project

Tue, Jun 11

erik.pilkington created D63176: [SemaObjC] Infer availability of stuff declared in categories from the availability of the enclosing category.
Tue, Jun 11, 5:03 PM · Restricted Project

Mon, Jun 10

erik.pilkington committed rG65831d049964: [demangle] Vendor extended types shouldn't be considered substitution candidates (authored by erik.pilkington).
[demangle] Vendor extended types shouldn't be considered substitution candidates
Mon, Jun 10, 2:03 PM
erik.pilkington added inline comments to D62960: SVE opaque type for C intrinsics demo.
Mon, Jun 10, 10:31 AM · Restricted Project

Wed, Jun 5

erik.pilkington added a comment to D62831: [CodeGen][ObjC] Add attribute "objc_arc_intert" to ObjC globals that are retain-agnostic.

I think this looks good from a clang perspective. No reason to land it before the dust settles on D62433 though.

Wed, Jun 5, 2:41 PM · Restricted Project, Restricted Project
erik.pilkington added inline comments to D62831: [CodeGen][ObjC] Add attribute "objc_arc_intert" to ObjC globals that are retain-agnostic.
Wed, Jun 5, 11:16 AM · Restricted Project, Restricted Project

Mon, Jun 3

erik.pilkington accepted D62643: [CodeGen][ObjC] Convert '[self alloc]' in a class method to 'objc_alloc(self)'.

I thinks this looks good, aside from a null concern.

Mon, Jun 3, 5:09 PM · Restricted Project, Restricted Project
erik.pilkington created D62825: [C++2a] Add __builtin_bit_cast, used to implement std::bit_cast.
Mon, Jun 3, 3:11 PM · Restricted Project, Restricted Project

Fri, May 31

erik.pilkington committed rGabb2a93c5327: [SimplifyLibCalls] Fold more fortified functions into non-fortified variants (authored by erik.pilkington).
[SimplifyLibCalls] Fold more fortified functions into non-fortified variants
Fri, May 31, 3:39 PM
erik.pilkington committed rG5234921119f9: NFC: Pull out a function to reduce some duplication (authored by erik.pilkington).
NFC: Pull out a function to reduce some duplication
Fri, May 31, 3:39 PM
erik.pilkington added inline comments to D62358: [SimplifyLibCalls] Fold more fortified builtin functions into their non-fortified variants when possible.
Fri, May 31, 3:39 PM · Restricted Project

Thu, May 30

erik.pilkington added a comment to D62358: [SimplifyLibCalls] Fold more fortified builtin functions into their non-fortified variants when possible.

Ping!

Thu, May 30, 12:43 PM · Restricted Project

May 23 2019

erik.pilkington created D62358: [SimplifyLibCalls] Fold more fortified builtin functions into their non-fortified variants when possible.
May 23 2019, 5:12 PM · Restricted Project

May 15 2019

erik.pilkington added a reviewer for D61722: [AST] Add RecoveryExpr; produce it on overload resolution failure and missing member.: erik.pilkington.
May 15 2019, 4:46 PM · Restricted Project
erik.pilkington committed rGf6c645f9fd93: [CodeGenObjC] invoke objc_autorelease, objc_retain when necessary (authored by erik.pilkington).
[CodeGenObjC] invoke objc_autorelease, objc_retain when necessary
May 15 2019, 1:14 PM
erik.pilkington created D61957: [CodeGenObjC] invoke objc_autorelease, objc_retain when necessary.
May 15 2019, 11:11 AM · Restricted Project

May 10 2019

erik.pilkington accepted D61803: [CodeGen][ObjC] Emit invoke instead of call to call `objc_release` when necessary..

LGTM, thanks!

May 10 2019, 2:12 PM · Restricted Project, Restricted Project
erik.pilkington added inline comments to D61803: [CodeGen][ObjC] Emit invoke instead of call to call `objc_release` when necessary..
May 10 2019, 1:50 PM · Restricted Project, Restricted Project
erik.pilkington committed rGf8ccf052935a: [Sema] Mark array element destructors referenced during initialization (authored by erik.pilkington).
[Sema] Mark array element destructors referenced during initialization
May 10 2019, 10:51 AM

May 9 2019

erik.pilkington updated the diff for D61165: Fix a crash where a [[no_destroy]] destructor was not emitted in an array.

Rename hasAccessibleDestructor.

May 9 2019, 4:49 PM · Restricted Project, Restricted Project
erik.pilkington added inline comments to D61165: Fix a crash where a [[no_destroy]] destructor was not emitted in an array.
May 9 2019, 4:49 PM · Restricted Project, Restricted Project
erik.pilkington added inline comments to D61165: Fix a crash where a [[no_destroy]] destructor was not emitted in an array.
May 9 2019, 4:14 PM · Restricted Project, Restricted Project
erik.pilkington added inline comments to D61165: Fix a crash where a [[no_destroy]] destructor was not emitted in an array.
May 9 2019, 3:08 PM · Restricted Project, Restricted Project
erik.pilkington updated the diff for D61165: Fix a crash where a [[no_destroy]] destructor was not emitted in an array.

Address review comments. Also remove the special case where we wouldn't check a destructor for an array in -fno-exceptions mode. This seems inconsistent with both how we're treating -fno-exceptions in general, and inconsistent with other cases of aggregate initialization (i.e. we still check struct members here).

May 9 2019, 3:08 PM · Restricted Project, Restricted Project

May 6 2019

erik.pilkington added a comment to D61165: Fix a crash where a [[no_destroy]] destructor was not emitted in an array.

Duncan pointed out eel.is/c++draft/class.init#class.base.init-13, which appears to claim that initialization ends with the execution of the constructor, excluding temporary destructors.

May 6 2019, 3:37 PM · Restricted Project, Restricted Project

May 3 2019

erik.pilkington added a comment to D61165: Fix a crash where a [[no_destroy]] destructor was not emitted in an array.

The flip side of that argument is that (1) there aren't very many users right now and (2) it's much easier to start conservative and then weaken the rule than it will be to strengthen it later. It really isn't acceptable to just turn off access/use-checking for the destructor, so if we get trapped by the choice we make here, we'll end up having to either leak or call std::terminate.

May 3 2019, 5:06 PM · Restricted Project, Restricted Project
erik.pilkington added a comment to D61165: Fix a crash where a [[no_destroy]] destructor was not emitted in an array.

I think the intuitive rule is that initialization is complete when the full-expression performing the initialization is complete because that's the normal unit of sequencing. Note that the standard does use both "constructed" and "initialized" in different contexts, although this might just be an editorial choice.

May 3 2019, 2:01 PM · Restricted Project, Restricted Project
erik.pilkington added a comment to D61165: Fix a crash where a [[no_destroy]] destructor was not emitted in an array.

It seems like the most common sense interpretation here is to just treat the initialization of G as completed at the point when the constructor finishes (this appears to be what GCC implements: https://wandbox.org/permlink/R3C9pPhoT4efAdL1).

Your example doesn't actually demonstrate that that's what GCC implements because it doesn't try to execute the declaration twice. But you're right, GCC does appear to consider the initialization complete as soon as the static object's constructor returns normally. On the other hand, GCC gets the array case here wrong: if a static local has array type, and a destructor for a temporary required by the first element initializer throws, then it does not destroy the element but also (correctly) does not mark the variable as fully initialized, and so a second attempt to run the initializer will simply construct a new object on top of an already-constructed one. This is arguably correct under the standard — the first array element is not a previously-constructed object of automatic duration — but I hope it's obvious that that's a defect.

So if it was static it would just get destroyed at exit-time, and therefore should be disable-able with no_destroy. If the standard implies that we should be doing something else, then we should do that, but I can't seem to find any reference to the rule you're describing.

Like I said, this is a poorly-specified part of the standard, because at least *some* objects with static storage duration have to be destroyed when an exception is thrown (because of aggregate initialization), but the standard wants to pretend that this isn't true. I think that allowing temporary destructors to cancel initialization uniformly across all kinds of objects is the most consistent rule,

That's only true for subobjects of an enclosing aggregate before that aggregate's initialization is complete though, right? So it doesn't seem like that much of an inconsistency, just mimicking what we would be doing if an exception was thrown in, say, the body of the ctor before the object's initialization is completed.

Conceptually yes, but formally no. The standard *could* write this rule as "all currently-initialized subobjects must be separately destroyed when an exception aborts initialization of the containing aggregate, including constructor bodies and aggregate initialization", but it doesn't actually do so; instead it has specific rules covering the behavior when an exception is thrown out of the body of a constructor, and those rules simply do not apply to aggregate initialization.

May 3 2019, 9:49 AM · Restricted Project, Restricted Project

May 2 2019

erik.pilkington added a comment to D61165: Fix a crash where a [[no_destroy]] destructor was not emitted in an array.

It seems like the most common sense interpretation here is to just treat the initialization of G as completed at the point when the constructor finishes (this appears to be what GCC implements: https://wandbox.org/permlink/R3C9pPhoT4efAdL1).

Your example doesn't actually demonstrate that that's what GCC implements because it doesn't try to execute the declaration twice. But you're right, GCC does appear to consider the initialization complete as soon as the static object's constructor returns normally. On the other hand, GCC gets the array case here wrong: if a static local has array type, and a destructor for a temporary required by the first element initializer throws, then it does not destroy the element but also (correctly) does not mark the variable as fully initialized, and so a second attempt to run the initializer will simply construct a new object on top of an already-constructed one. This is arguably correct under the standard — the first array element is not a previously-constructed object of automatic duration — but I hope it's obvious that that's a defect.

So if it was static it would just get destroyed at exit-time, and therefore should be disable-able with no_destroy. If the standard implies that we should be doing something else, then we should do that, but I can't seem to find any reference to the rule you're describing.

Like I said, this is a poorly-specified part of the standard, because at least *some* objects with static storage duration have to be destroyed when an exception is thrown (because of aggregate initialization), but the standard wants to pretend that this isn't true. I think that allowing temporary destructors to cancel initialization uniformly across all kinds of objects is the most consistent rule,

May 2 2019, 1:49 PM · Restricted Project, Restricted Project

May 1 2019

erik.pilkington added a comment to D61165: Fix a crash where a [[no_destroy]] destructor was not emitted in an array.

Hmm. You know, there's another case where the destructor can be called even for a non-array: if constructing the object requires a temporary, I believe an exception thrown from that temporary's destructor is supposed to go back and destroy the variable. (This is, sadly, not entirely clear under the standard since the object is not automatic.) Now, Clang does not actually get this correct — we abort the construction, but we don't destroy the variable — but (1) we should fix that someday and (2) in the meantime, we shouldn't implement something which will be a problem when we go to fix that.

May 1 2019, 4:53 PM · Restricted Project, Restricted Project

Apr 30 2019

erik.pilkington updated the diff for D61165: Fix a crash where a [[no_destroy]] destructor was not emitted in an array.

Add a try/catch block to the docs.

Apr 30 2019, 4:04 PM · Restricted Project, Restricted Project
erik.pilkington accepted D61147: [Sema][ObjC] Disable -Wunused-parameter for ObjC methods.

LGTM, thanks!

Apr 30 2019, 3:58 PM · Restricted Project, Restricted Project
erik.pilkington updated the diff for D61165: Fix a crash where a [[no_destroy]] destructor was not emitted in an array.

Address review comments.

Apr 30 2019, 3:06 PM · Restricted Project, Restricted Project
erik.pilkington accepted D61280: Variable auto-init: don't initialize aggregate padding of all aggregates.

LGTM, I think this makes sense.

Apr 30 2019, 1:36 PM · Restricted Project

Apr 26 2019

erik.pilkington added a comment to D52521: [Sema] DR727: Ensure we pick up enclosing template instantiation arguments for a class-scope explicit specialization..

No worries! It happens, I probably should have pinged this more aggressively.

Apr 26 2019, 3:34 PM
erik.pilkington planned changes to D61165: Fix a crash where a [[no_destroy]] destructor was not emitted in an array.

I believe at least one of the goals of nodestroy is to allow the type to potentially not provide a destructor at all, so if we're going to implicitly require the destructor anyway in certain situations, we should clearly document that, and we should be aware that we may be making the attribute less useful.

Since I believe the dominant use-case here is a true global, does only requiring the destructor for arrays in the static-local case when exceptions are enabled at least make it acceptable to do proper access checking, or is that still a source-compatibility problem for existing clients?

Apr 26 2019, 2:54 PM · Restricted Project, Restricted Project
erik.pilkington added a comment to D61165: Fix a crash where a [[no_destroy]] destructor was not emitted in an array.

By using no_destroy, you're saying that exit-time destructor doesn't matter because the OS will either reclaim the resources automatically, or its just doesn't matter since the process is going down. I don't think that implies that we can safely ignore the destructor in the middle of the program's execution.

Apr 26 2019, 2:31 PM · Restricted Project, Restricted Project
erik.pilkington added a comment to D61165: Fix a crash where a [[no_destroy]] destructor was not emitted in an array.

JF, Michael, and I were talking about this offline, and we think that the right choice of semantics for the static local case is to call the destructors.

Apr 26 2019, 2:29 PM · Restricted Project, Restricted Project
erik.pilkington added a comment to D61147: [Sema][ObjC] Disable -Wunused-parameter for ObjC methods.

I do not think the ObjC version of this diagnostic is useful as it's been explained here, and I would strongly recommend just not including such a warning for the time being.

Why? It seems to me like the vast majority of methods only declared in an @implementation are used as local helpers (even if people probably should be using functions for this), where this warning would be useful. Maybe I'm missing something? Still trying to learn more about Objective-C.

What rule are you suggesting for whether a method is "only declared in an @implementation"? Where exactly are you proposing to look for other declarations?

Objective-C does not have a formalized notion of an @implementation-private method, or really even an unambiguous convention for them (underscoring is *library*-private by convention, not class-private). The Objective-C ecosystem includes a lot of informal protocols and conventions based around discovery via naming, and Objective-C programmers do (admittedly rarely) just override methods that they know are there but which they can't see. These things make me very worried about trying to port assumptions from other languages.

Apr 26 2019, 1:47 PM · Restricted Project, Restricted Project

Apr 25 2019

erik.pilkington added a comment to D61147: [Sema][ObjC] Disable -Wunused-parameter for ObjC methods.

I do not think the ObjC version of this diagnostic is useful as it's been explained here, and I would strongly recommend just not including such a warning for the time being.

Apr 25 2019, 10:27 PM · Restricted Project, Restricted Project
erik.pilkington abandoned D52521: [Sema] DR727: Ensure we pick up enclosing template instantiation arguments for a class-scope explicit specialization..

Looks like @rsmith fixed this in r359266.

Apr 25 2019, 8:52 PM
erik.pilkington created D61165: Fix a crash where a [[no_destroy]] destructor was not emitted in an array.
Apr 25 2019, 5:47 PM · Restricted Project, Restricted Project
erik.pilkington accepted D60848: [Parser] Avoid correcting delayed typos in array subscript multiple times..

Huh, okay. I guess there are two separate bugs that are conspiring to crash the compiler here: we shouldn't correct a TypoExpr more than once, and we shouldn't correct a TypoExpr less than once. I think fixing one of the two is fine. FYI I think you should be able to write a testcase if you RUN it with -disable-free.

Apr 25 2019, 5:23 PM · Restricted Project
erik.pilkington added a comment to D61147: [Sema][ObjC] Disable -Wunused-parameter for ObjC methods.

Yeah, I tend to think we should just suppress this unconditionally in Objective-C.

IMO this warning still makes sense for normal functions, or methods that are only declared in an @implementation. Adding a fix-it to cast to void in the function/method body would probably go a long way too.

Should we use the new warning to warn just about unused ObjC method parameters and have -Wunused-parameter warn about everything else? If we make -Wunused-parameter unconditionally ignore ObjC methods, a user might complain about it later if -Wunused-parameter didn't diagnose an unused parameter when it should have.

Apr 25 2019, 3:38 PM · Restricted Project, Restricted Project
erik.pilkington added a comment to D61147: [Sema][ObjC] Disable -Wunused-parameter for ObjC methods.

Yeah, I tend to think we should just suppress this unconditionally in Objective-C.

Apr 25 2019, 2:24 PM · Restricted Project, Restricted Project
erik.pilkington added a comment to D61147: [Sema][ObjC] Disable -Wunused-parameter for ObjC methods.

but don't want to annotate each unused ObjC method parameters with __attribute__((unused)) or insert (void)unused_param into the body of the method to silence the warning since, unlike C/C++ functions, it's not possible to comment out the unused parameters of ObjC methods.

Apr 25 2019, 1:53 PM · Restricted Project, Restricted Project

Apr 19 2019

erik.pilkington added a comment to D60848: [Parser] Avoid correcting delayed typos in array subscript multiple times..

Wait, why is NumTypos incorrect here? I think its because we don't handle the typo on the line: [self undeclaredMethod:undeclaredArg];, even the following asserts now. Seems like the right fix would be to track down why we aren't handling the typo in the message expr.

Apr 19 2019, 11:02 AM · Restricted Project

Apr 17 2019

erik.pilkington accepted D60736: [Sema][ObjC] Don't warn about a block implicitly retaining self if the block is marked noescape.

LGTM too, thanks!

Apr 17 2019, 3:27 PM · Restricted Project, Restricted Project
erik.pilkington added inline comments to D60736: [Sema][ObjC] Don't warn about a block implicitly retaining self if the block is marked noescape.
Apr 17 2019, 11:09 AM · Restricted Project, Restricted Project

Apr 15 2019

erik.pilkington added a comment to D60736: [Sema][ObjC] Don't warn about a block implicitly retaining self if the block is marked noescape.

Akira and I were just talking about an alternative approach to this: Keep a vector of pairs of BlockDecls and SourceLocations in the enclosing method's FunctionScopeInfo, and emit any unsuppressed diagnostics when popping the method. This would avoid having to traverse all the blocks in methods in ARC mode, at the cost of a small amount of memory.

Apr 15 2019, 5:01 PM · Restricted Project, Restricted Project

Apr 11 2019

erik.pilkington committed rG1138d8c8924b: Support objc_nonlazy_class attribute on Objective-C implementations (authored by erik.pilkington).
Support objc_nonlazy_class attribute on Objective-C implementations
Apr 11 2019, 10:55 AM
erik.pilkington committed rGc5a0583400b7: Add support for attributes on @implementations in Objective-C (authored by erik.pilkington).
Add support for attributes on @implementations in Objective-C
Apr 11 2019, 10:55 AM
erik.pilkington added a comment to D60544: Support objc_nonlazy_class attribute on Objective-C implementations.

Should we have a special has_feature test to check that this attribute is allowed on implementations? We've done that in the past when expanding the set of subjects for an attribute. But that's not necessary if we haven't made this attribute part of a public Xcode release yet, because then the attribute is just understood to always apply to implementations; I can't remember when exactly this was added and what releases it's made it into.

Apr 11 2019, 10:27 AM · Restricted Project, Restricted Project
erik.pilkington added inline comments to D60542: Add support for attributes on @implementations in Objective-C.
Apr 11 2019, 10:17 AM · Restricted Project

Apr 10 2019

erik.pilkington committed rGcb5c7bd9ebfa: Fix a hang when lowering __builtin_dynamic_object_size (authored by erik.pilkington).
Fix a hang when lowering __builtin_dynamic_object_size
Apr 10 2019, 4:42 PM
erik.pilkington added a parent revision for D60544: Support objc_nonlazy_class attribute on Objective-C implementations: D60542: Add support for attributes on @implementations in Objective-C.
Apr 10 2019, 3:18 PM · Restricted Project, Restricted Project
erik.pilkington added a child revision for D60542: Add support for attributes on @implementations in Objective-C: D60544: Support objc_nonlazy_class attribute on Objective-C implementations.
Apr 10 2019, 3:18 PM · Restricted Project
erik.pilkington created D60544: Support objc_nonlazy_class attribute on Objective-C implementations.
Apr 10 2019, 3:15 PM · Restricted Project, Restricted Project
erik.pilkington created D60542: Add support for attributes on @implementations in Objective-C.
Apr 10 2019, 3:11 PM · Restricted Project
erik.pilkington committed rGde051dfe029b: Fix a test, NFC (authored by erik.pilkington).
Fix a test, NFC
Apr 10 2019, 2:20 PM

Apr 4 2019

erik.pilkington created D60298: Fix a hang when lowering __builtin_dynamic_object_size.
Apr 4 2019, 5:43 PM · Restricted Project

Apr 3 2019

erik.pilkington added inline comments to D60229: llvm-cxxfilt: Demangle gcc "old-style unified" ctors and dtors.
Apr 3 2019, 2:03 PM · Restricted Project
erik.pilkington accepted D60229: llvm-cxxfilt: Demangle gcc "old-style unified" ctors and dtors.

LGTM, thanks!

Apr 3 2019, 2:03 PM · Restricted Project
erik.pilkington added a comment to D24639: [Sema] Warn when returning a lambda that captures a local variable by reference.

Is there a reason why this was never merged?
Has the functionality been folded in in some other revision?

I saw a bug recently which would have been caught by exactly this, which would have been awesome.
How can we get this merged?

Apr 3 2019, 12:53 PM

Apr 2 2019

erik.pilkington committed rG3299ead8e9ff: [CodeGen] Fix a regression by emitting lambda expressions in EmitLValue (authored by erik.pilkington).
[CodeGen] Fix a regression by emitting lambda expressions in EmitLValue
Apr 2 2019, 12:50 PM
erik.pilkington committed rGaf913156685a: [Sema] Fix a use-after-deallocate of a ParsedAttr (authored by erik.pilkington).
[Sema] Fix a use-after-deallocate of a ParsedAttr
Apr 2 2019, 12:50 PM

Apr 1 2019

erik.pilkington created D60101: [Sema] Fix a use-after-deallocate of a ParsedAttr.
Apr 1 2019, 3:28 PM · Restricted Project
erik.pilkington created D60099: [CodeGen] Fix a regression by emitting lambda expressions in EmitLValue.
Apr 1 2019, 2:40 PM · Restricted Project

Mar 29 2019

erik.pilkington committed rG233ff9421263: [Sema] Avoid sending a dependent expression to the constant evaluator. (authored by erik.pilkington).
[Sema] Avoid sending a dependent expression to the constant evaluator.
Mar 29 2019, 12:57 PM
erik.pilkington added a comment to D58797: [Sema] Add some compile time _FORTIFY_SOURCE diagnostics.

This is triggering a Clang assertion failure in Fuchsia build:

clang/lib/AST/ExprConstant.cpp:5032: bool (anonymous namespace)::ExprEvaluatorBase<(anonymous namespace)::PointerExprEvaluator>::VisitMemberExpr(const clang::MemberExpr *) [Derived = (anonymous namespace)::PointerExprEvaluator]: Assertion `!E->isArrow() && "missing call to bound member function?"' failed.

I've filed PR41286 which also has a reproducer.

Mar 29 2019, 12:56 PM · Restricted Project

Mar 28 2019

erik.pilkington added a comment to D58797: [Sema] Add some compile time _FORTIFY_SOURCE diagnostics.

Ah, looks like the problem is we're sending a dependent expression to the constant evaluator, we should just bail out in that case. I'll fix this tomorrow morning, thanks for tracking this down!

Mar 28 2019, 7:22 PM · Restricted Project

Mar 26 2019

erik.pilkington closed D59670: [Sema] Fix an assert when a block captures a constexpr local.

Landed in r357040. (I forgot to write Differential revision:!)

Mar 26 2019, 4:31 PM · Restricted Project
erik.pilkington committed rG818698010cd4: Emit -Wfortify-source using DiagRuntimeBehaviour (authored by erik.pilkington).
Emit -Wfortify-source using DiagRuntimeBehaviour
Mar 26 2019, 4:21 PM
erik.pilkington committed rG14f6d1527c70: [Sema] Fix an assert when a block captures a constexpr local (authored by erik.pilkington).
[Sema] Fix an assert when a block captures a constexpr local
Mar 26 2019, 4:20 PM
erik.pilkington added a comment to D58797: [Sema] Add some compile time _FORTIFY_SOURCE diagnostics.

For that particular case, I think we could suppress the false positive using DiagRuntimeBehavior. How many total false positives are we talking about, and how many can the compiler statically prove are unreachable?

Mar 26 2019, 4:20 PM · Restricted Project
erik.pilkington added inline comments to D59670: [Sema] Fix an assert when a block captures a constexpr local.
Mar 26 2019, 11:13 AM · Restricted Project
erik.pilkington updated the diff for D59670: [Sema] Fix an assert when a block captures a constexpr local.

Add an assert.

Mar 26 2019, 11:13 AM · Restricted Project

Mar 22 2019

erik.pilkington added a comment to D58797: [Sema] Add some compile time _FORTIFY_SOURCE diagnostics.

This is causing false positive warnings for the Linux kernel:
https://github.com/ClangBuiltLinux/linux/issues/423
:(

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/statfs.c#n128
Consider this untested case (when the condition is false):

	if (sizeof(buf) == sizeof(*st))
		memcpy(&buf, st, sizeof(*st));

fs/statfs.c:129:3: warning: 'memcpy' will always overflow; destination buffer has size 64, but size argument is 88 [-Wfortify-source]

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/statfs.c#n169, too.

Mar 22 2019, 12:16 PM · Restricted Project

Mar 21 2019

erik.pilkington created D59670: [Sema] Fix an assert when a block captures a constexpr local.
Mar 21 2019, 2:32 PM · Restricted Project

Mar 20 2019

erik.pilkington committed rG8ca6ab33b7d2: Add a __has_extension check for '#pragma clang attribute' as an external… (authored by erik.pilkington).
Add a __has_extension check for '#pragma clang attribute' as an external…
Mar 20 2019, 12:27 PM
erik.pilkington committed rG13ee62f7d7ee: [Sema] Deduplicate some availability checking logic (authored by erik.pilkington).
[Sema] Deduplicate some availability checking logic
Mar 20 2019, 12:27 PM

Mar 19 2019

erik.pilkington committed rG02d5fb1a6efb: Add a spelling of pass_object_size that uses __builtin_dynamic_object_size (authored by erik.pilkington).
Add a spelling of pass_object_size that uses __builtin_dynamic_object_size
Mar 19 2019, 1:47 PM

Mar 18 2019

erik.pilkington added a comment to D59523: Thread Safety: also look at ObjC methods.

I don't understand this code at all, but what about BlockDecl?

Mar 18 2019, 5:09 PM · Restricted Project, Restricted Project
erik.pilkington committed rGb6e16ea006a2: [Sema] Add some compile time _FORTIFY_SOURCE diagnostics (authored by erik.pilkington).
[Sema] Add some compile time _FORTIFY_SOURCE diagnostics
Mar 18 2019, 12:24 PM
erik.pilkington requested review of D59394: [Sema] De-duplicate some availability checking logic.

I can confirm this fixed my original problem. It's also close to the patch I attempted writing myself earlier this week -- but this one is better of course.

Mar 18 2019, 11:46 AM · Restricted Project, Restricted Project

Mar 15 2019

erik.pilkington added inline comments to D58757: Add a version of the pass_object_size attribute that works with builtin_dynamic_object_size.
Mar 15 2019, 3:58 PM · Restricted Project
erik.pilkington updated the diff for D58757: Add a version of the pass_object_size attribute that works with builtin_dynamic_object_size.

Address review comments.

Mar 15 2019, 3:58 PM · Restricted Project

Mar 14 2019

erik.pilkington created D59394: [Sema] De-duplicate some availability checking logic.
Mar 14 2019, 4:08 PM · Restricted Project, Restricted Project
erik.pilkington added a comment to D58514: Avoid needlessly copying blocks that initialize or are assigned to local auto variables to the heap.

There is no way in the existing ABI for copying a block to cause other references to the block to become references to the heap block. We do do that for __block variables, but not for block objects themselves.

Do you think thats worth doing? We could add a forwarding pointer to the end of a block literal on the stack (after all the captures) and flip an unused bit to track it, preserving ABI. Seems like now that we're delaying _Block_copyies this might be a bigger issue.

We've always delayed _Block_copy in a bunch of places. Now we're just delaying it in a place that ARC used to be more conservative about.

I guess we could actually make forwarding work at some code-size cost (functions that emitted forwardable blocks would have to zero the forwarding slot and release it when destroying the stack copy). But it'd just silently do nothing without a runtime update, so it'd be somewhat treacherous, especially after a couple of releases: e.g. if we made the runtime change in macOS 20 Eugene O'Neill National Historic Site, and Chromium eventually only ran tests on macOS 20 and higher but still supported deploying to macOS 19 San Francisco Maritime National Historical Park, then Chromium might not catch that it was still necessary to include an explicit copy here.

Mar 14 2019, 12:21 PM · Restricted Project
erik.pilkington committed rG3689caebecfa: [Sema] Fix a use-after-free of a _Nonnull ParsedAttr (authored by erik.pilkington).
[Sema] Fix a use-after-free of a _Nonnull ParsedAttr
Mar 14 2019, 11:40 AM
erik.pilkington added a comment to D58514: Avoid needlessly copying blocks that initialize or are assigned to local auto variables to the heap.

There is no way in the existing ABI for copying a block to cause other references to the block to become references to the heap block. We do do that for __block variables, but not for block objects themselves.

Mar 14 2019, 11:17 AM · Restricted Project

Mar 13 2019

erik.pilkington added inline comments to D58797: [Sema] Add some compile time _FORTIFY_SOURCE diagnostics.
Mar 13 2019, 6:10 PM · Restricted Project
erik.pilkington updated the diff for D58797: [Sema] Add some compile time _FORTIFY_SOURCE diagnostics.

Address review comments. Thanks!

Mar 13 2019, 6:09 PM · Restricted Project