Is there a way to check and change which headers cpp is looking at in Visual Studio 2015?

F12 fails to move to definition, but compilation is successful.

#define SINGLETON_CLASS(T)classT

This coding convention seems to be the cause.The compiler parses the source code faithfully, but the IDE skips some analysis to balance it with the speed of analysis.

#define SINGLETON_CLASS class

and the coding convention, or if that is difficult, why don't you consider using an editor other than Visual Studio?

I was able to confirm the symptom.As I pointed out, IDE is just breaking the analysis.

// Question Status
#define SINGLETON_CLASS(T)class T
SINGLETON_CLASS(A){};

// Answer 1…Not resolved
#define SINGLETON_CLASS class
SINGLETON_CLASSA {};

// Answer 2…ANALYSISABLE
#define SINGLETON
SINGLETON class A {};

Please revise the coding convention around here (if possible) and if not, give up or use another editor.

Quoted from Comments:

"It says ""LINL2019 errors do not appear and can be executed,"" but does the purpose of the question mean that the IDE (Visual Studio) intelligence reports errors, although the program behavior can be compiled and linked as expected?"
Yes, you can compile, link, and run as expected, but if you say "Function definition not found", you will see a green wavy line in that area.

Short Answer: IntelliSense is not a complete C++ compiler.Simply ignore the IntelliSense error or give up using the Visual Studio editor.

As a precondition, Visual Studio's C++ Compiler (cl.exe) and IntelliSense are independent processing systems.There are cases where one side reports an error, but the other side has no problem.IntelliSense is often useless when deploying complex macros such as code during questioning.

To be honest, I don't recommend it, but you can use the macro __INTELLISE__ to determine if the IntelliSense process is in progress or if it is a normal C++ compilation process.

#define DEFINETEST(T)class T

# ifdef__INTERLISE__
class Hoge
# else
DEFINETEST (Hoge)
#endif
{
   //...
};

Also see the Visual C++ Team Blog article Troubleshooting Tips for IntelliSense Slowness:

The IntelliSense compiler is not the build compiler
It is important, here, to call out that the IntelliSense compiler is different from the build compiler. We have made every effort to give these two compilers parity. (For more information about how this works with C++/CLI please check this blog post.)

However, there are still differences, and occasionally, a file that compiles without error using our build compiler will not compile properly with our IntelliSense compiler. Often, this is because the IntelliSense compiler has a more strict interpretation of the C++ standard than the build compiler. In these cases, you can usually work around this problem by fixing the error reported by the IntelliSense compillar. (In most cases, the build compiler will accept the more-conforming code being required by the IntelliSense compiler.)

Additionally, if you are targeting an architecture other than x86, you may notice that the IntelliSense compiler is always operating in x86 mode. This can produce errors that are very different to work around, and while these errors will not give you a present from the cause.

If you are unable to find a code workaround for your problems, there is one further stopgap measure that can help: the compiler macro __INTELLISENSE__, which is only defined when using the IntelliSense compiler. You can use this macro to guard code the IntelliSense compiler does not understand, or use it to toggle between the build and IntelliSense compiler.

First of all, if the cause can be identified as a target macro,
I omit it, but there are many reasons why it is reasonable to exclude it.
Regarding the symptoms,

1. You can predict that both class view and intelligence refer to the same symbol DB(pdb), so the result will be the same.

2. From my experience, I have an impression that I am not good at moving to definition especially for #define macros.You can write anywhere as long as it's the same.

If you want to know which header you're looking at,

3. The header file line you want to disclose, e.g.
　# Right-click on the line such as include "foo.h" and select "Open document "foo.h" from the context menu that appears to open the appropriate file in the include path. You can find the location of the file by trying to "keep it as."

If possible,

4. I couldn't guess the meaning of this unnatural macro well, but if you can replace it with typeef, template, etc., it's more natural in C++ language.
Personally, I feel very uncomfortable replacing the language's essential identifiers (although I allow them to be debugged).