[RFC] make `__builtin_dump_struct` expand `typeof` declarations

Clang Frontend
1

Introduction

Background and Motivation

I created a macro for getting the type and value of any C type using __builtin_dump_struct

#define $to_string(...) ({\
    static char _buf[1024];\
    int offset = 0;\
    struct { typeof(__VA_ARGS__) value; } _x = { .value = (__VA_ARGS__) };\
    __builtin_dump_struct(&_x, &type_to_string, &offset, sizeof(_buf), _buf);\
    _buf;
})

Upon running this on clang17 with the input of

    int s = 4;
    printf("%s\n", $to_string(s));

the resultant expression in stdout is as follows:

struct (unnamed) {
  typeof (s) value = 4
}

Possible solutions

Expanding the typeof statement

The best possible solution is if the typeof, or in C++ decltype, statement is expanded, so the output would look something like

struct (unnamed) {
  int value = 4
}

Type aliases should not be expanded, so code like

typedef int Handle_t;

Handle_t i = 4;
printf("%s\n", $to_string(s));

Should become

struct (unnamed) {
  Handle_t value = 4
}

__builtin_type_as_string

Another is introducing a new builtin to convert type T into a C String that can be consumed by the program

int i = 4;
printf("%s\n", __builtin_type_as_string(typeof(i)))

This is my first RFC, so I am open to criticism and feedback :slight_smile: . I am hoping to implement these features myself and put them in a pull request, but I’m not sure if I was supposed to do that before or after I made this post.

1 Like
2

I don’t think I would mind the first one, but I’d also suggest we do the same for any sort of decltype (in C++) expressions as well, but make sure we leave type aliases alone (so something like Foo::Type).

3

I agree! Should I edit the RFC to add that? I am not too sure whats proper etiquette

4

Sure, feel free to edit, as long as you mention an edit in comments.