[cfe-dev] Switching terminology from 'instantiation' to 'expansion' for macros?

Chandler Carruth chandlerc at google.com
Thu Jul 7 18:49:39 PDT 2011


This is something that came up some time ago on IRC, and several (myself,
John McCall, and maybe others) really liked the idea of: systematically
switch from 'instantiation' to 'expansion' in terminology relating to macros
and the preprocessor. (Is there a better word than 'expand'? I couldn't come
up with one. The following argument should be independent of what wording is
actually chosen, except that it be different from 'instantiation'.)

The reasoning is two fold:
1) It more accurately describes the underlying process (token expansion),
including the fact that the process happens on each use of a macro, not just
on the first with a particular set of arguments, etc.

2) It helps users (and likely developers) distinguish between diagnostics
and systems relating to macros vs. templates.

I think the second point is perhaps the most important here. As a bit of an
extreme case, consider the following code:

% cat t5.cc
struct S1;
struct S2;
template <typename T> struct X1 { T value; };
template <typename T> struct X2 { X1<T> value; };
#define M0 X2<S1>().value;
#define M1(x, y, z) X2<S2> foo = y
#define M2(x, y, z) M1(x, y, z)
M2(1, M0, 3);

% ./bin/clang -fsyntax-only t5.cc
t5.cc:3:37: error: field has incomplete type 'S1'
template <typename T> struct X1 { T value; };
                                    ^
t5.cc:4:41: note: in instantiation of template class 'X1<S1>' requested here
template <typename T> struct X2 { X1<T> value; };
                                        ^
t5.cc:8:7: note: in instantiation of template class 'X2<S1>' requested here
M2(1, M0, 3);
      ^
t5.cc:5:12: note: instantiated from:
#define M0 X2<S1>().value;
           ^
t5.cc:7:27: note: instantiated from:
#define M2(x, y, z) M1(x, y, z)
                          ^
t5.cc:6:34: note: instantiated from:
#define M1(x, y, z) X2<S2> foo = y
                                 ^
<snip>

I think it's very nice to have different wording for the macro back traces.
As a bit of a straw-man, I've just replaced 'instantiated' with 'expanded'
and I already find the result somewhat better:

% ./bin/clang -fsyntax-only t5.cc
t5.cc:3:37: error: field has incomplete type 'S1'
template <typename T> struct X1 { T value; };
                                    ^
t5.cc:4:41: note: in instantiation of template class 'X1<S1>' requested here
template <typename T> struct X2 { X1<T> value; };
                                        ^
t5.cc:8:7: note: in instantiation of template class 'X2<S1>' requested here
M2(1, M0, 3);
      ^
t5.cc:5:12: note: expanded from:
#define M0 X2<S1>().value;
           ^
t5.cc:7:27: note: expanded from:
#define M2(x, y, z) M1(x, y, z)
                          ^
t5.cc:6:34: note: expanded from:
#define M1(x, y, z) X2<S2> foo = y
                                 ^

I'd like to slowly work to move the note text to be instead:

% ./bin/clang -fsyntax-only t5.cc
t5.cc:3:37: error: field has incomplete type 'S1'
template <typename T> struct X1 { T value; };
                                    ^
t5.cc:4:41: note: in instantiation of template class 'X1<S1>' requested here
template <typename T> struct X2 { X1<T> value; };
                                        ^
t5.cc:8:7: note: in instantiation of template class 'X2<S1>' requested here
M2(1, M0, 3);
      ^
t5.cc:5:12: note: 'M0' expanded from the macro defined here:
#define M0 X2<S1>().value;
           ^
t5.cc:7:27: note: 'M2(...)' expanded from the macro defined here:
#define M2(x, y, z) M1(x, y, z)
                          ^
t5.cc:6:34: note: 'M1(...)' expanded from the macro defined here:
#define M1(x, y, z) X2<S2> foo = y
                                 ^

What do folks think? Would it be OK to work toward this in increments,
starting with 'expanded from the macro defined here', and then working on a
patch to add the name of the macro that we're showing the definition for?


As a related, but not necessary additional step, how do folks feel about
moving the APIs, comments, etc inside of Clang's code itself to use the same
nomenclature? I'd really like to see this as it would make reading these
parts of the codebase easier in the same way I think it makes reading the
diagnostics above easier. Thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110707/47430e7f/attachment.html>


More information about the cfe-dev mailing list