For whatever 10 minutes on Google's worth, it seems Visual Studio doesn't support this.
Some compilers do attempt this, but there's a reason it's a bit fragile / best-effort...
To first rehash and knock down the common but bogus explanation for this: there's a conceptually distinct preprocessing step that substitutes text for the uses of preprocessor macros before "proper" compilation begins, but there's really no reason the preprocessing stage can't pass a record of the #define and #undefine statements onwards for inclusion with other debug information.
What is a pain is that what is intuitively and commonly considered "#define-ing a preprocessor constant" isn't anything like...
const Some_Type some_identifier = some_value;
...in that the latter has a specific location in the application's namespace heirarchy and really can't be changed, while a #define can be #undef-ined and re-#defined any number of times, such that the "value" of a preprocessor macro at a particular line of code can depend on how that line's been included in the translation unit: each inclusion of the same line in each translation unit could have a different value (or no value) for that macro.
For this reason, displaying the "value" of a macro as you're debugging through some code is problematic - it's only guaranteed to have a single value at a particular line in a particular translation unit, but programmers normally want debuggers to show and navigate programs in terms of lines in source files.
Consider:
use_x.h
class T ## X {
void g() { ... }
};
some_app.cc
#define X 2783
#include "use_x.h"
#undef X
#define X 2928
#include "use_x.h"
void f() {
const int last_x = X;
}
If your debugger's stepping through f() above, X can be said to be 2928, but what if you're stepping through a version of g() - the debugger would have a tough time understanding there's some connection between the class name and the value of X used to create it, or working out what to display some other way....
It gets worse if you hover a mouse over a macro while stopped at some other line - possibly linked in from a different translation unit - it can be impossible for the debugger to know whether you're interested in the last value of that macro that your execution has passed through, or the next value it might have if execution continues (if it can even predict any branching that may happen first), or the value (if any) of the macro at the line the debugger's stopped at.
So, some tool chains (compilers / debug-info-encodings / debuggers) just don't buy into this mess. Better tools might track simple cases then display nothing - or a list of possible values - for cases too complex to analyse. Displaying wrong values is much worse than nothing.
It doesn't help within the debugger, but when macro values/substitutions need to be reviewed you can try cl /E (for GCC/clang the option's -E) to provide preprocessed output for a translation unit - you can then see what substitutions have been made by the preprocessor.
