Apply formatting to thrust

[miscco]

This applies formatting to all files inside thrust

There is one dependency within <thrust/memory.h>

That I cannot track down. I have added a Fixme to the strange include I needed to add 🤷

[alliepiper]

Mostly just grumbling, and I know it's probably too late in the process to change, but i really do hate this particular formatting:

_CCCL_HOST_DEVICE ReturnType
SomeFunctionWithAReallyLongSignature(Arg1 arg1, Arg2 arg2, ...)

Do you know if there's a way to change this to something like:

_CCCL_HOST_DEVICE
ReturnType SomeFunctionWithAReallyLongSignature(
  Arg1 arg1,
  Arg2 arg2, 
  ...)

Or even just

_CCCL_HOST_DEVICE
ReturnType
SomeFunctionWithAReallyLongSignature(Arg1 arg1, Arg2 arg2, ...)

Having the return type on the same line as _CCCL_HOST_DEVICE that bugs me.

[alliepiper]

Spot checked a bunch of places, this LGTM.

[gevtushenko]

Having the return type on the same line as _CCCL_HOST_DEVICE that bugs me.

@alliepiper could you elaborate? Execution space specifier doesn't look that different from other specifiers. I don't see any of the major formatting styles separate the return type in the code below.

[[deprecated]] [[nodiscard]] inline int //
foo() {}

In your example, how would you format the following code?

_CCCL_HOST_DEVICE [[nodiscard]] inline ReturnType SomeFunctionWithAReallyLongSignature();

In other words, is your concert specifically targeting execution space specifier?

Do you know if there's a way to change this to something like:

_CCCL_HOST_DEVICE
ReturnType SomeFunctionWithAReallyLongSignature(

I tried BreakAfterAttributes: Always, but surprisingly it doesn't affect AttributeMacros. @miscco do you know if this is expected behavior?

[miscco]

I tried BreakAfterAttributes: Always, but surprisingly it doesn't affect AttributeMacros. @miscco do you know if this is expected behavior?

No idea, we could add an implicit replacement of the macro with an actual attribute maybe?

[alliepiper]

could you elaborate?

For a concrete example, this appears in this patch:

template <typename DerivedPolicy>
_CCCL_HOST_DEVICE pointer<void, DerivedPolicy>
malloc(const thrust::detail::execution_policy_base<DerivedPolicy>& system, std::size_t n);

In your example, how would you format the following code?

Personally, if I were manually formatting I'd go with

_CCCL_HOST_DEVICE inline
[[nodiscard]] const ReturnType&
SomeFunctionWithAReallyLongSignature(
  args...)
{ }

since I like to have [[nodiscard]] next to the return type, but this is probably not doable with clang-format. Since we probably have to treat all attributes the same, I'd be happy with:

_CCCL_HOST_DEVICE [[nodiscard]] inline
const ReturnType& SomeFunctionWithAReallyLongSignature(
  args...)
{ }

or, if the function name + returntype exceeds the char limit,

_CCCL_HOST_DEVICE [[nodiscard]] inline
const ReturnType&
SomeFunctionWithAReallyLongSignature(
  args...)
{ }

In other words, is your concern specifically targeting execution space specifier?

I think this is mostly about the ReturnType placement. Having it lumped in with the attributes instead of the signature is weird, and I'd rather break the args to a newline before splitting the return type and function name. I never want the return type buried at the end of a list of attributes because the arguments overflow the line. So for the mallloc example that's in this patch, I think this would be best:

template <typename DerivedPolicy>
_CCCL_HOST_DEVICE
pointer<void, DerivedPolicy> malloc(
  const thrust::detail::execution_policy_base<DerivedPolicy>& system, 
  std::size_t n);

[gevtushenko]

@miscco I've pushed a few fixes, please, take a look before merging.

[gevtushenko]

@alliepiper since the manual formatting you shared is not possible, and alternatives are not unanimous, we'll go forward with the current style.

[alliepiper]

we'll go forward with the current style.

No worries, having things formatted consistently is much more important. Hopefully someday we can find a way to pull the return type out of the attribute lists, I do find that annoying but I'll live ;-)