Tue, Apr 23
Mon, Apr 22
Here's the motivating bug report: https://bugs.llvm.org/show_bug.cgi?id=41027
I don't like making the validity of an input depend on optimizations, but I presume this is necessary to build Linux or similar? I'd be more comfortable with this if we still did the eager check if the enclosing function doesn't have the always_inline attribute. Is that sufficient to satisfy the use cases?
Sun, Apr 21
Fri, Apr 19
Hmm. So there are a few different situations where we might meet an unknown attribute (I'm sure I missed some):
LGTM, with a possible optimization. Thank you! I know this bug was incredibly hard to track down. =)
Thu, Apr 18
This needs revision to reflect changes between the Concepts TS and C++20. In particular, only the name of a type-concept can be used to declare a template-parameter in the new rules:
Wed, Apr 17
Yup, i confirm that this improves discoverability of this feature :) Maybe it deserves its own .rst doc, like FileCheck, but for now doxygen seems to be the best source of truth on how to use -verify and i consult it regularly.
I think you're missing the enforcement of the rule that the same field name cannot be designated multiple times in a single designated-initializer-list. I'm fine with that being done separately (not as part of this patch), though.
Mon, Apr 15
Please revert the (presumably unintended) mode changes to the ptxas executables.
Sun, Apr 14
Fri, Apr 12
Adding -std=c++14 doesn't work in general as it has side-effects: clang -std=c++14 foo.c is a warning, clang -std=c++14 -x c-header foo.h is an error. It would be nice if clang had a flag to specify the default c++ language version without also forcing the file to be parsed as C++, but AFAIK it does not.
Thu, Apr 11
I have applied the fix to all language versions, even though I think that the DR only applies to C++14
This seems liable to be moderately expensive, especially for large argument values, and it's a cost that is unnecessary in the common case where evaluation succeeds.
Wed, Apr 10
Generally it's a good thing for our test suite to be robust against changes to Clang's default language mode.
I expect that we get this wrong in the same way for all the SemaDeclRefs declarations (StdNamespace, StdBadAlloc, and StdAlignValT).
Mar 22 2019
Thanks, this looks like a good broad direction.
Mar 21 2019
Mar 19 2019
Mar 18 2019
Mar 12 2019
Mar 8 2019
LGTM, and I think this is safe enough to take for Clang 8.
Mar 7 2019
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.)
Mar 6 2019
If we go with a different name for the flag, then the user has to update their build scripts to get code to compile with Clang, which means it shouldn't be too onerous for them to spell out the specific diagnostics they need disabled (and it sort of forces them into somewhat better code hygiene by not disabling all diagnostics). I'm kind of leaning towards not providing a flag at all.
I also can't really tell what the intent is behind classifying some diagnostics in Clang as ExtWarn,DefaultError and others Warning,DefaultError -- or if there even is any useful purpose there at all. I note with special-puzzlement the existence of both ext_return_missing_expr and warn_return_missing_expr.
Mar 5 2019
The errors disabled by this feature are default-error warnings -- you can already get the same effect by using -Wno-<lots-of-things>.
Mar 4 2019
I'm not super keen on supporting -fpermissive -- what is the impetus for supporting this? Is it just for GCC compatibility?
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).