When comment is not enough

[kiselgra]

I want to write this code:

inline __attribute((always_inline)) int foo() { return 0; }

However, neither of the following two work. The former because the function-call gets messed up (which, I think, is ok), the latter because of c-compatible renaming (which, I think, we want to have in the general case).

(function foo () -> (inline __attribute__((always_inline)) int)
  (return 0))

(function foo () -> (inline |__ATTRIBUTE__((ALWAYS_INLINE))| int)
  (return 0))

The result is as follows

inline __attribute__ 
always_inline()(); int foo(void)
{
        return 0;
}

inline __attribute____always_inline__ int foo(void)
{
        return 0;
}

As usual with unusual cases, comment comes in handy:

(function foo () -> (inline (comment "__attribute__((always_inline))" :prefix "") int)
  (return 0))

But starts a new line:

inline 
__attribute__((always_inline)) int foo(void)
{
        return 0;
}

@lispbub Maybe we can just add an option to comment to not trigger a newline?

[lispbub]

The syntax is slightly different:
(Also there was a small bug in the code, but it should work now)

(function foo () -> (inline (__attribute__ always_inline) int)
     (return 0))

[kiselgra]

That version is still missing a set of parens:

inline __attribute__(always_inline) int foo()
{
        return 0;
}

Adding the pair then generates a function call:

inline __attribute__(always_inline)() int foo()
{
        return 0;
}

The intended output is the (somewhat weird) gcc syntax:

inline __attribute__((always_inline)) int foo()
{
        return 0;
}

[lispbub]

Support for new command attribute since e9a5aed

(function foo () -> (inline (attribute always_inline) int)
     (return 0))

yields:

inline __attribute__ ((always_inline)) int foo()
{
        return 0;
}

works also with multiple arguments:
(attribute weak (alias "__f")) results in __attribute __ ((weak, alias("___f")))
and arguments with parameters:
(attribute (assume_aligned 32 8)) generates __attribute__ ((assume_aligned(32, 8))

[lispbub]

It's now possible to disable the line break in comments with:

(function foo () -> (inline (comment "__attribute__((always_inline))"
                                     :prefix ""
                                     :linebreak nil)
                    int)
  (return 0))

allowing easy workarounds:

inline __attribute__((always_inline)) int foo()
{
        return 0;
}

[kiselgra]

It seems we forgot about a very unfortunate operator: operator().

(function operator<< ((int a) (int b)) -> bool (return true))

(function operator() ((int a) (int b)) -> bool (return true))

(function (comment "operator()" :prefix "" :linebreak nil) ((int a) (int b)) -> bool
          (return true))

bool operator<<(int a, int b)
{
        return true;
}

__ operator()
{
        return true;
}

bool operator()(int a, int b)
{
        return true;
}

I think parsing this one will be really hard, so I'm open for alternatives, one would be just keeping

(function operator\(\) ((int a) (int b)) -> bool (return true))

I'm basically re-opening this to have it acknowledged. :)

[lispbub]

(function |operator()| ... also works, but generates OPERATOR().
(function |OPERATOR()|... works fine :)

What about adding an inverted reader to |foo|?

[kiselgra]

How bad do you think this would mess up regular code? Think of SBCL's |List|. Will such things be affected? They should be if some piece of code macroexpands to them, right?