- User Since
- Jul 12 2012, 2:19 PM (349 w, 4 d)
Fri, Mar 22
Thanks, this looks like a good broad direction.
Thu, Mar 21
Tue, Mar 19
Mon, Mar 18
Tue, Mar 12
Fri, Mar 8
LGTM, and I think this is safe enough to take for Clang 8.
Thu, Mar 7
In principle, I think an extension in this space seems reasonable and useful. Considering the points in http://clang.llvm.org/get_involved.html, I'm happy to assume you meet points 2, 5, and 6, but I'd like to see a written-up rationale for the other points. (In particular, you do not yet meet the bar for points 3 and 7, and if you're not proposing this to WG14 or WG21 or similar, some amount of rationale justifying that is necessary.)
Wed, Mar 6
Tue, Mar 5
Mon, Mar 4
Feb 23 2019
Feb 21 2019
Feb 15 2019
This seems fine to me, but I think we can do better if we want to. How about: call TryCreateTempFile() N times, and check that it succeeds exactly 16 times. Pick N such that the probability of it failing to find all 16 possible file names (given that it has 128 retries for each call) is astronomically small. (Right now the test should fail somewhere around 0.03% of the time; if we made, say, 32 calls, the probability of a flake would be significantly lower than the probability of a flake due to spontaneous hardware failure (in order to flake, we must find only 15 of the 16 filenames with at least 17 * 128 + 15 guesses, the probability of which is 1 in 3.9x10^62).
Feb 14 2019
Feb 13 2019
Address review comments.
Feb 12 2019
Combine WithinStmtExpr flag with AllowedStmtKinds into a more general statement
context. In doing so, fix some bugs where the OpenMP context was not being
propagated properly through labels and expression-statements starting with @.
Feb 11 2019
@ABataev Is it intentional that we do not propagate Allowed through labels? For example:
Address a couple of review comments.
Feb 8 2019
Thanks, this is a much cleaner model than having two different APValue representations for arrays.
You'll also need to update TreeTransform::TransformCompoundStmt. (And please add some tests for template instantiation.)
Feb 6 2019
Feb 5 2019
The "false negatives" in the current behaviour are the result of an intentional decision to avoid false positives for unsequenced operations that cannot actually both happen as part of the same evaluation (because both are conditional on different and mutually-exclusive conditions), such as the false positive we now get in the tests. I think it's reasonable to revisit that decision, though; the new false positive cases do not realistically seem likely to occur in real code whereas the false negatives do.
Feb 4 2019
Feb 1 2019
Jan 31 2019
Jan 29 2019
Jan 28 2019
Jan 26 2019
Jan 24 2019
Looks good to me, thanks! Let's try this and see if it shakes out any problems.
There isn't really a standard name for this; in the absence of such a name, this seems as good as anything.
Jan 23 2019
Thanks for the added tests! They seem to have found a bug in the handling of local const integral variables.
Jan 22 2019
Jan 21 2019
This seems to be introducing a requirement that enterUnknown is called on all paths through the parser where we recurse to parse a subexpression and don't have specific type information. That seems like an unfortunate requirement to me from a maintenance perspective; have you considered alternative approaches? For example, we could store the preferred type alongside the SourceLocation of the corresponding token (and propagate the information when we parse parentheses and any other completion-type-preserving construct), and only apply the information when the code completion token is at that location. That way, we only need to annotate cases where we know the preferred type, not when we don't.
Jan 18 2019
Thanks, looks great!