c++: Set loc on call even if result is discarded
authorAlexandre Oliva <oliva@adacore.com>
Mon, 11 Apr 2022 15:11:08 +0000 (12:11 -0300)
committerAlexandre Oliva <oliva@gnu.org>
Mon, 11 Apr 2022 15:11:08 +0000 (12:11 -0300)
commit396a013a5857f85d878993eda32fb2df689bb8e8
tree3ae0f323ca99b222791957eaeeeddeabb53faa8d
parent4132f6ba9583e128a00d55961ae8c8e7245b2223
c++: Set loc on call even if result is discarded

This patch fixes a divergence in line numbers in diagnostics and,
presumably, debug information, between targets whose cdtors return
this and those that don't.

The problem was visible in g++.dg/cpp2a/constexpr-dtor3.C: while the
dtor call in the cleanup for f4 was expected at the closing brace, on
returning-this targets it came up at the assignment.

The reason is convoluted: statements in cleanups have their location
information removed, to avoid bumpy debugger behavior, and then set to
the location of the end of the scope.

The cleanup dtor call has its locus cleared in both kinds of targets,
but the end-of-scope locus doesn't make it on returning-this targets.
The calls are wrapped with a cast-to-void to discard the unused return
value, and the existing logic only attached the locus to the
conversion NOP_EXPR.

The call thus remains locus-less.  When constexpr logic copies and
evals the body, it sets unset locations; while copying cleanups, the
locus is taken from the cleanup expression, rather than matching the
end-of-scope locus set by the parser.  So we end up with different
locations.

This patch sets the locus of the call even when it's wrapped by a
convert-to-void NOP_EXPR, so it won't diverge any more.

for  gcc/cp/ChangeLog

* semantics.cc (set_cleanup_locs): Propagate locus to call
wrapped in cast-to-void.
gcc/cp/semantics.cc