[PATCH] D130055: Clang extensions yolo, woot & kaboom

aaron.ballman added a comment. In D130055#3683822 , @jkorous wrote: > In D130055#3683173 , @aaron.ballman > wrote: > >> Are there circumstances where we cannot "simply" infer this from the >> constructor

[PATCH] D130055: Clang extensions yolo, woot & kaboom

aaron.ballman added subscribers: aaronpuchert, delesley. aaron.ballman added a comment. In D130055#3683279 , @beanz wrote: > In D130055#3683173 , @aaron.ballman > wrote: > >> Are there circumstances where we

[PATCH] D130055: Clang extensions yolo, woot & kaboom

jkorous added a comment. One more thing - the "attributes as a cross-TU metadata" idea might be (possibly with some squinting) conceptually similar to `enforce_tcb` attribute that @NoQ made me aware of some time ago. https://clang.llvm.org/docs/AttributeReference.html#enforce-tcb Repository:

[PATCH] D130055: Clang extensions yolo, woot & kaboom

jkorous added a comment. In D130055#3683279 , @beanz wrote: > I'm wondering if there could be a generalization of the attribute like: I can't imagine it is possible to design a reasonable and practically usable system of attributes to model anything

[PATCH] D130055: Clang extensions yolo, woot & kaboom

jkorous added a comment. In D130055#3683173 , @aaron.ballman wrote: > Are there circumstances where we cannot "simply" infer this from the > constructor itself? (After instantiation) we know the class hierarchy, we > know the data members, and we know

[PATCH] D130055: Clang extensions yolo, woot & kaboom

beanz added a comment. In D130055#3683173 , @aaron.ballman wrote: > Are there circumstances where we cannot "simply" infer this from the > constructor itself? I think this gets tricky in cases where objects may have valid "uninitialized" state. Like

[PATCH] D130055: Clang extensions yolo, woot & kaboom

aaron.ballman added a comment. Thank you for this! I'm starting to get dug out from standards meetings and able to think about this a bit more, and I had some questions. > The yolo attribute denotes a constructor as creating an "uninitialized" > variable. Are there circumstances where we

[PATCH] D130055: Clang extensions yolo, woot & kaboom

dblaikie added a comment. In D130055#3682497 , @beanz wrote: > In D130055#3677743 , @dblaikie > wrote: > >> Any chance this could be a generalization of >>

[PATCH] D130055: Clang extensions yolo, woot & kaboom

beanz added a comment. In D130055#3677743 , @dblaikie wrote: > Any chance this could be a generalization of > https://clang.llvm.org/doxygen/Consumed_8cpp_source.html ? I'm not really familiar with that code, but at glance there seems to be some

[PATCH] D130055: Clang extensions yolo, woot & kaboom

dblaikie added a comment. Any chance this could be a generalization of https://clang.llvm.org/doxygen/Consumed_8cpp_source.html ? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D130055/new/ https://reviews.llvm.org/D130055

[PATCH] D130055: Clang extensions yolo, woot & kaboom

beanz added a comment. In D130055#3663164 , @jkorous wrote: > It looks like there is a possibility that a free function, static method or a > method of another class (a `friend`?) should be `woot` for a specific > pointer/reference parameter. Oh!

[PATCH] D130055: Clang extensions yolo, woot & kaboom

jkorous added a comment. Hi Chris! This is a very interesting idea! I do have couple thoughts - mostly that this could lead to something great and I would love it to apply to as many relevant cases as possible. It looks like there is a possibility that a free function, static method or a

[PATCH] D130055: Clang extensions yolo, woot & kaboom

beanz added a comment. In D130055#3662206 , @Szelethus wrote: > On another note, `kaboom` is interesting, shouldn't we assume all functions > to be `kaboom` unless proven to be `woot`? I won’t claim to have spent a whole lot of time thinking on this.

[PATCH] D130055: Clang extensions yolo, woot & kaboom

Szelethus added a subscriber: balazske. Szelethus added a comment. Yeah, I'm afraid no fun is allowed on this block. On another note, `kaboom` is interesting, shouldn't we assume all functions to be `kaboom` unless proven to be `woot`? @balazske's work on checking the return value of certain

[PATCH] D130055: Clang extensions yolo, woot & kaboom

NoQ added a subscriber: Szelethus. NoQ added a comment. @Szelethus this patch is closely related to your prior work! Ok yeah we'll need names. I recommend at least explaining it a bit in the review head so that people had at least some idea what is this about. Repository: rG LLVM Github

[PATCH] D130055: Clang extensions yolo, woot & kaboom

beanz created this revision. beanz added reviewers: aaron.ballman, bogner, rnk, MaskRay, void. Herald added a subscriber: StephenFan. Herald added a reviewer: NoQ. Herald added a project: All. beanz requested review of this revision. Herald added a project: clang. Sometimes a default-initialized