MSVC 2022 Template Build Errors No Compile-Time Strack Trace? - c++

Question

I may well just be missing some silly option in the boatload of options available in MSVC 2022 that changed in terms of their defaults (please tell me if so), but I can't seem to get a compile-time stack trace when we encounter errors in the middle of function or class templates.
Basic example in MSVC 2022:
template <class T>
void foo()
{
static_assert(false);
}
int main()
{
foo<int>();
}
In MSVC 2022 with default settings, all I get is a "static assert failed" kind of message. It doesn't tell me who called foo. Whereas in MSVC 2019, I got a full compile-time stack trace letting me know that calling foo failed down to the precise line that called foo.
I'm really missing that extra info from 2019. But I have a sneaking suspicion that there's some option in Tools->Options I'm not aware about to enable this output behavior again.
Picture:
Anyone else encountering this issue after upgrading to 2022 from 2019 and/or have a fix for it?
MSVC 2019 as a comparison where I got error messages in templates that are actually usable to help me figure out where/how they occurred!
Also, I only used static_assert to produce a bare minimum and reproducible result. I'm lacking this stack trace on every kind of error that occurs inside a function or class template.
In response to the automated Q for the site:
I tried going through all the options I could find and searching Google along with this site for answers. In fairness, I'm an old and dumb guy now so I might have overlooked something obvious. I really think that has to be the most obvious answer since MSVC 2022 has been out for a long time now and I figure other people would have complained left and right in ways I could easily find if this wasn't a behavior we can revert. I'm really hoping I'm overlooking something because that would totally suck if we can no longer see the compile-time call stack for errors in class and function templates (that's actually omitting crucial info in many cases, since it may not be an error with the template/callee but an error in the way the caller calls the callee).
Stack Trace?
My bad if I used the wrong terminology for this. I got a comment pointing this out. I am thinking about something that is like tracing the call stack (not calling, but evaluating calls in a nested fashion at compile time as we parse, generate AST, generate IR, optimize IR, etc.). That could be a second question as a bonus if I'm using "compile-time stack trace" incorrectly! What's the proper term? English is not my first language as a half-excuse but I'm probably just really dumb!
Update in Response to HolyBlackCat
I just made a project with the default settings using your code and got the type of errors I expect and wanted from MSVC 2019! A sample of the errors I get which match yours:
1>C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.34.31933\include\memory(3256,5): message : see declaration of 'std::unique_ptr<int,std::default_delete<int>>::unique_ptr'
1>C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.34.31933\include\memory(3256,5): message : 'std::unique_ptr<int,std::default_delete<int>>::unique_ptr(const std::unique_ptr<int,std::default_delete<int>> &)': function was explicitly deleted
1>C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.34.31933\include\vector(852,1): message : see reference to function template instantiation 'void std::_Default_allocator_traits<_Alloc>::construct<_Ty,const _Ty&>(_Alloc &,_Objty *const ,const _Ty &)' being compiled
1> with
1> [
1> _Alloc=std::allocator<std::unique_ptr<int,std::default_delete<int>>>,
1> _Ty=std::unique_ptr<int,std::default_delete<int>>,
1> _Objty=std::unique_ptr<int,std::default_delete<int>>
1> ]
1>C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.34.31933\include\vector(863,36): message : see reference to function template instantiation 'void std::_Default_allocator_traits<_Alloc>::construct<_Ty,const _Ty&>(_Alloc &,_Objty *const ,const _Ty &)' being compiled
1> with
1> [
1> _Alloc=std::allocator<std::unique_ptr<int,std::default_delete<int>>>,
1> _Ty=std::unique_ptr<int,std::default_delete<int>>,
1> _Objty=std::unique_ptr<int,std::default_delete<int>>
1> ]
So that's great and wonderful! I at least like this part of MSVC 2022. But I could swear that I was getting errors in function and class templates in our project that didn't show this for whatever reason. I tried to use static_assert(false) as an MVE. But it seems like some cases show us hierarchy of callers and not just the error in the callee and some cases don't... although I still think seeing that even for static_assert fails is so useful!

Answer 1

Had a chance to test my theory from my comments. The issue is with trying to be standards compliant.
You likely have /permissive- flag set, to be standards compliant (default when C++20 is used). This enables two phase name lookups for templates. Under the non-standard parsing which Microsoft did before:
It parses only the template declaration, the class head, and the base class list. The template body is captured as a token stream. No function bodies, initializers, default arguments, or noexcept arguments are parsed. The class template is pseudo-instantiated on a tentative type to validate that the declarations in the class template are correct.
...
When it parses a function template, the compiler parses only the function signature. The function body is never parsed. Instead, it's captured as a token stream.
In this, non-standard mode, it ignores the static_assert( false ), until it is instantiated from main, in which case you get the information about who's instantiating it.
In the standards compliant mode, it does parse the body, and sees the static_assert( false ) and fails immediately, before any instantiation is done.
If you want the old behaviour, you can turn off the standards conformance by specifying /permissive (though I would not recommend this). You can disabled just the two-phase name lookup (again, not really recommended) by specifying /Zc:twoPhase-
See more here: https://learn.microsoft.com/en-us/cpp/build/reference/zc-twophase?view=msvc-170
Also, example (side by side) with two phase on and off here: https://godbolt.org/z/MPEWGsYTx (godbolt gives less details in its output than MS, but does show its instantiation)
Note: The compile still gives information on who's instantiating if the issue is with the caller, not the callee.
Funny aside: when MS first did this, they broke their own code in the process, and caused a whole lot of programs to stop compiling because they were using static_assert( false ) in their Unit test framework ... I guess they forgot to use their own unit testing before pushing it out :P