https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116064
Patrick Palka <ppalka at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2024-07-24
Status|RESOLVED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
Ever confirmed|0 |1
Resolution|INVALID |---
CC| |jason at gcc dot gnu.org,
| |ppalka at gcc dot gnu.org
--- Comment #4 from Patrick Palka <ppalka at gcc dot gnu.org> ---
FWIW -fdelayed-template-parsing seems to originally have been introduced as an
MSVC compatibility flag:
https://clang.llvm.org/docs/MSVCCompatibility.html#template-instantiation-and-name-lookup
It can change the meaning of valid code since it causes unqualified lookup to
be performed from the point of instantiation instead of from the template
definition:
int g(long) { return 0; }
template<class T>
int f() { return g(0); }
int g(int) { return 1; }
int main() {
return f<int>(); // returns 1 with -fdelayed-template-parsing, 0 without
}
That it also suppresses errors inside uninstantiated templates seems to be a
convenient coincidence, so it doesn't seem to be an ideal workaround.
I'm going to try downgrading these name lookup errors into permerrors when
inside an uninstantiated template, so that they can be worked around by passing
-fpermissive (which doesn't change the meaning of valid code).
