On Fri, Aug 23, 2019 at 02:43:42PM -0700, Jason Merrill wrote: > On 8/23/19 9:32 AM, Marek Polacek wrote: > > This patch implements another C++20 feature, partially deprecating volatile. > > You can read the proposal here: <http://wg21.link/p1152r4>. I encourage > > interested people to read the background in <http://wg21.link/p1152r0> which > > provides a lot of interesting volatile-related information. > > > > Note that P1152R4 differs slightly from what's now in the standard: the > > mention > > of "non-class type" was dropped. (Assignment to objects of a class type is > > defined by the copy/move assignment operator.) > > > > The gist is that expressions that involve both load and store of a volatile > > lvalue, such as ++ or += are deprecated, as are volatile-qualified parameter > > and return types. Chained assignments of the form "a = b = c" are also > > deprecated because there's some confusion as to if 'b' is re-read before > > storing > > the value to 'a' (GCC claims not to do it). See Annex D > > [depr.volatile.type]. > > > > [expr.ass] further says that "A simple assignment whose left operand is of > > a volatile-qualified type is deprecated unless the assignment is either > > a discarded-value expression or appears in an unevaluated context." > > and therein lies the rub. When parsing/building the MODIFY_EXPR, we don't > > know > > if the assignment's value is going to be discared. We only know that after > > mark_discarded_use has run, which for expression-statements takes place in > > finish_expr_stmt -> conver_to_void, and that is quite late. > > It wouldn't work to warn in mark_[lr]value_use?
My worry is that we might be calling those too often and generate redundant diagnostics but I'll have to play with that a bit before I can say for sure. Marek
