Rename cpp11-migrate to be something more general?

Greetings folks!

C++14 is just around the corner, and I thought it would be a good time to float an idea I had a long time ago: should we rename cpp11-migrate to something that frees it to target C++14 and maybe even newer features?

If folks like this general idea, I think we should do it now-ish. =D It’s a good time.

My suggested names:

{clang,cpp}-modernize

I lean slightly toward the ‘clang’ prefix to match clang-format and other tools.

Greetings folks!

C++14 is just around the corner, and I thought it would be a good time to float an idea I had a long time ago: should we rename cpp11-migrate to something that frees it to target C++14 and maybe even newer features?

If folks like this general idea, I think we should do it now-ish. =D It's a good time.

My suggested names:

  {clang,cpp}-modernize

I lean slightly toward the 'clang' prefix to match clang-format and other tools.

I like clang-modernize.

+1

Good with me too.

+1 for clang-modernize.

clang-modernize looks good. :slight_smile:

"Siraj, Tareq A" <tareq.a.siraj@intel.com> writes:

Awesome. Thanks for everyone replying. I’ll plan to do the rename tonight so beware the outstanding patches. =D

In article <CAGCO0KgQ5wdA9-8ZZ7kvijTbpBkbLLPmbxCSdNWdaEsZq=P6XA@mail.gmail.com>,
    Chandler Carruth <chandlerc@google.com> writes:

Awesome. Thanks for everyone replying. I'll plan to do the rename tonight
so beware the outstanding patches. =D

I recently did some playing around with libtooling to understand how
to create an automated refactoring.

I could contribute it to clang-modernize if people think it's
appropriate.

The tool replaces an argument list of "(void)" with "()".

I have it drilling down into most places, but I am still a little
sketchy on how to get it to recognize that:

  void some_function_taking_fn_ptrs(
    void (*fn_ptr)(void (*fn_void_ptr)(void)));

should become

  void some_function_taking_fn_ptrs(
    void (*fn_ptr(void (*fn_void_ptr)()));

This nesting of function pointer types can obviously occur farther and
farther down into an "inline" type declaration.

My questions for this audience are:

1) is this considered a "modernizing" transform that is appropriate
   for clang-modernize?

2) how do I walk arbitrary type declarations like this without having
   to re-invent parsing the type expressions?

With knowledge of 2), I think I can make this transformation complete
across everywhere that fn(void) is acceptable and replace it with
fn().

In article <CAGCO0KgQ5wdA9-8ZZ7kvijTbpBkbLLPmbxCSdNWdaEsZq=
P6XA@mail.gmail.com>,
    Chandler Carruth <chandlerc@google.com> writes:

> Awesome. Thanks for everyone replying. I'll plan to do the rename tonight
> so beware the outstanding patches. =D

I recently did some playing around with libtooling to understand how
to create an automated refactoring.

I could contribute it to clang-modernize if people think it's
appropriate.

The tool replaces an argument list of "(void)" with "()".

I have it drilling down into most places, but I am still a little
sketchy on how to get it to recognize that:

        void some_function_taking_fn_ptrs(
                void (*fn_ptr)(void (*fn_void_ptr)(void)));

should become

        void some_function_taking_fn_ptrs(
                void (*fn_ptr(void (*fn_void_ptr)()));

This nesting of function pointer types can obviously occur farther and
farther down into an "inline" type declaration.

My questions for this audience are:

1) is this considered a "modernizing" transform that is appropriate
   for clang-modernize?

Maybe? Some people might consider it more of a style choice.

2) how do I walk arbitrary type declarations like this without having
   to re-invent parsing the type expressions?

You walk type declarations using TypeSourceInfo: FunctionTypeLoc has

functions to retrieve the LParen and RParen locations for a function type
declaration.

-Eli

In article <CAJdarcHpLLjcXUgQzOpOQB0cuzTJQtehT+aggH_niAJFtRekQw@mail.gmail.com>,
    Eli Friedman <eli.friedman@gmail.com> writes:

> My questions for this audience are:
>
> 1) is this considered a "modernizing" transform that is appropriate
> for clang-modernize?
>

Maybe? Some people might consider it more of a style choice.

It is my understanding that the syntax "(void)" is for compatibility
with C, where (void) is needed to explicitly say that a function takes
no arguments and () is the legacy syntax used by older C code before
function prototypes.

Am I wrong?

> 2) how do I walk arbitrary type declarations like this without having
> to re-invent parsing the type expressions?
>
> You walk type declarations using TypeSourceInfo: FunctionTypeLoc has
functions to retrieve the LParen and RParen locations for a function type
declaration.

The problem is that source locations just give me a position within
the text, they don't give me smaller units of semantic structure that
I can walk. Finding the start and end positions in the source text is
easy -- what I'm stumbling with is finding the corresponding parsed
structure from that text.

In C, "(void)" in a prototype means "no arguments", while "()" means "no information about arguments". The latter is really only applicable to K&R-style code, so in a prototype it doesn't tell you anything about the arguments to the function. You would have to visit the actual definition to figure out which arguments the function has.

-Dimitry

In article <
CAJdarcHpLLjcXUgQzOpOQB0cuzTJQtehT+aggH_niAJFtRekQw@mail.gmail.com>,
    Eli Friedman <eli.friedman@gmail.com> writes:

> > My questions for this audience are:
> >
> > 1) is this considered a "modernizing" transform that is appropriate
> > for clang-modernize?
> >
>
> Maybe? Some people might consider it more of a style choice.

It is my understanding that the syntax "(void)" is for compatibility
with C, where (void) is needed to explicitly say that a function takes
no arguments and () is the legacy syntax used by older C code before
function prototypes.

Am I wrong?

No, you're not wrong, but some people might consider it a style choice
anyway, given that C++ has always worked that way.

> > 2) how do I walk arbitrary type declarations like this without having
> > to re-invent parsing the type expressions?
> >
> > You walk type declarations using TypeSourceInfo: FunctionTypeLoc has
> functions to retrieve the LParen and RParen locations for a function type
> declaration.

The problem is that source locations just give me a position within
the text, they don't give me smaller units of semantic structure that
I can walk. Finding the start and end positions in the source text is
easy -- what I'm stumbling with is finding the corresponding parsed
structure from that text.

You can walk TypeSourceInfo: given a FunctionTypeLoc, you can get TypeLocs
for the arguments, which you can then convert to FunctionTypeLocs, etc.

-Eli

In article <CAJdarcGc3JhFHGCvL1Xb8tKYK0=M-FKxuMQe5sD4ao970=+BRw@mail.gmail.com>,
    Eli Friedman <eli.friedman@gmail.com> writes:

That’s a really good conceptually simple refactoring. I think it would make a great topic for a tutorial (independently of its utility otherwise).

– Sean Silva