[PATCH] D88295: [Sema] Fix volatile check when test if a return object can be implicitly move

Richard Smith - zygoloid via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Fri Oct 30 12:57:09 PDT 2020


rsmith added a comment.

In D88295#2365312 <https://reviews.llvm.org/D88295#2365312>, @Quuxplusone wrote:

> I believe the organization of that directory implies that the path should be `class/class.init/class.copy.elision/`, not `special/class.copy/`.
> Otherwise LGTM, and I like this new test better than the old one!
> I still can't help re actually landing this patch, as I don't have permissions either.
>
> EDIT: Actually I take that back; I don't understand why any existing test would have the path `special/class.copy/`, since no section by that name exists in the Standard. So, I defer to anybody with a strong opinion on the matter.

It's historical; we haven't reorganized our tests in response to the subclauses in the standard being reorganized, and (for example) in C++98 the copy elision wording was in subclause 12.8 [class.copy], within Clause 12 [special]. Moving the test to `class/class.init/class.copy.elision/p1.cpp` would make sense to me. Otherwise the change to copy elision looks good; the history here is long and subtle, but the status quo after P1825R0 (which was moved as a DR) is clear that volatile objects are not implicitly movable.

However, it looks like this change also affects users of `CES_AsIfByStdMove`, and for "as if by `std::move`" semantics, I don't think `volatile` variables should be ignored. This affects two things:

One is whether we produce the warning suggesting use of `std::move`. For example, given:

  X f() {
    volatile X x;
    return x;
  }

... where `X` has a volatile copy constructor and a volatile move constructor, I think we should produce the warning suggesting use of `std::move`.

The other is whether implicitly move in a `co_return` statement. In that case, I think the use of `CES_AsIfByStdMove` is a mistake, and we should be using `CES_Default` there.

So, how about we add another `CES` flag to indicate whether we should reject variables with volatile-qualified type, and set it for `CES_Default` but not for `CES_AsIfByStdMove`, and also change the `co_return` handling to use `CES_Default`?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88295/new/

https://reviews.llvm.org/D88295



More information about the cfe-commits mailing list