- User Since
- Jul 12 2012, 2:19 PM (466 w, 1 h)
Thanks, let's go with this for now.
I think we need to take this to the C++ committee. For example, consider a case like:
Tue, Jun 15
Mon, Jun 14
I think this is the wrong solution; I think the assertion is correct and is observing a problem elsewhere. Imagine if we had something like:
Thu, Jun 10
Wed, Jun 9
Tue, Jun 8
This will diagnose unused values in unreachable code in constant-evaluated contexts; that doesn't seem quite right. For example, in:
Looks good to me.
I think this is worth doing -- "rvalue" is at least ambiguous and, in C++-specific cases, confusing and wrong. Saying "prvalue" in C-specific parts of clang may also be a bit surprising, but it's unambiguous and still meaningful.
Wed, Jun 2
Tue, Jun 1
@ldionne How should we go about establishing whether libc++ would be prepared to officially support CUDA? Right now, Clang's CUDA support is patching in attributes onto libc++ functions from the outside, which doesn't seem like a sustainable model.
Wed, May 26
Should we also warn about inline variables in anonymous namespaces?
Mon, May 24
Wed, May 19
Tue, May 18
May 17 2021
May 16 2021
May 14 2021
I don't think out-of-tree experiments on possibilities for move semantics are especially motivating for this, one way or the other, but I do think it would be nice to make some kind of change here.
Thanks, nice catch!
May 13 2021
The undef problem seems pretty fundamental here, and I don't think there's an easy fix. Let's consider that separately from this patch.
May 12 2021
May 11 2021
(Reopening, earlier commit was accidental.)
(No blocking concerns here.)
May 10 2021
Generally-speaking, we have a plan that I'm happy for us to work towards, and I'm happy for our progress towards that plan to be incremental. Even though this might not be fully in that direction right now, I think that's OK.
May 6 2021
Thanks, this looks good to me!
May 5 2021
Thanks, I'm broadly very happy with this. My remaining comments are all very minor.
Apr 30 2021
This change is not correct. The language rules only apply to particular syntactic forms, so we need to check for those exact syntactic forms here.
Apr 29 2021
Apr 28 2021
When this change returns, I'd like to see a different implementation strategy. Running a recursive AST visitation after the fact is generally not the right way to look for this kind of issue; adding an extra pass to speculatively hunt for each kind of warning we might want to issue is too expensive. Instead, I think we should do something simpler and cheaper, such as tracking, for each variable in scope, the number of potentially-evaluated non-assignment references to that variable. For example:
Apr 27 2021
Apr 22 2021
Apr 16 2021
From a process standpoint, I think the best thing would be to first send out a patch adding a release note saying we no longer support libstdc++ < 4.8.3 and updating the part of docs/Toolchain.rst that Aaron linked to, and send a brief note to cfe-dev drawing people's attention to that patch and asking for objections -- I don't think you need to wait for more than a couple of days for such objections, but as this is effectively a policy change we should probably give people a little time to respond. Then remove the workarounds as (hopefully now entirely uncontroversial) follow-up steps.
I think we should decide what version of libstdc++ we're prepared to support and document that somewhere, and it would make sense to remove the various libstdc++ compatibility changes that target older versions. Google still has builds that use Clang trunk, recent glibc, and libstdc++ 4.9, in >=C++14 mode, though (which I think is the combination that needs this workaround), so I'm not sure that the world is ready for Clang's minimum to be increased to 6.3 or later. (Of course Google could locally patch their libstdc++, but if there's one organization building in this mode still, it seems likely that there are others, and in particular version 4.9 was the last version prior to the introduction of the dual ABI, so there may be reasons people want to stop there in particular. I think at least the need to support libstdc++ 4.2 for Apple targets has disappeared now, though, so it's possible that we could drop support for 4.8 and earlier?)
Apr 15 2021
Apr 14 2021
Apr 13 2021
Functionally this looks good to me. I've suggested some minor cleanups and I understand you're doing some wordsmithing on the diagnostics; I think once those are complete this will be ready to land. Thank you!
Apr 12 2021
Exposing this information seems fine to me. I think it'd be more useful to expose it in a way the preprocessor can inspect, but it's hard to see how to do that without requiring us to invent identifier-shaped names for all encodings, and perhaps we shouldn't be in the business of doing that. If this string literal approach addresses the use cases you have, then I think that's OK.
Thanks, I think this makes sense as a generalization of the existing "idiomatic aggregate initialization" rule. Some suggested cleanups but otherwise LGTM.
Apr 8 2021
Apr 7 2021
Sorry for the late review.
This is somewhat related to the following RFC by @rjmccall: