Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Format options for attributes, ability to specify custom attributes. #45968

Closed
allisonvacanti mannequin opened this issue Jul 7, 2020 · 4 comments
Closed

Format options for attributes, ability to specify custom attributes. #45968

allisonvacanti mannequin opened this issue Jul 7, 2020 · 4 comments
Labels
bugzilla Issues migrated from bugzilla clang-format enhancement Improving things as opposed to bug fixing, e.g. new or missing feature

Comments

@allisonvacanti
Copy link
Mannequin

allisonvacanti mannequin commented Jul 7, 2020

Bugzilla Link 46623
Version unspecified
OS All
CC @JonasGilg,@mydeveloperday

Extended Description

Clang-format currently does not have options to control attribute formatting.

Some projects prefer to put prefix attributes on a separate line, eg:


[[nodiscard]]
int foo();

instead of:

[[nodiscard]] int foo();

Additionally, it would be useful to be able to provide a list of regexes that identify custom attributes. Maintaining an exhaustive list of attributes in clang-format proper would be daunting, as many projects hide them behind macros for backward compatibility, or rely on platform-specific attributes. Allowing projects to extend the list of recognized attributes would be quite useful.

My personal interest in this stems from using clang-format on CUDA projects, where __host__ __device__ annotations are frequently used and commonly placed on the line above a function definition. Being able to achieve this common formatting style would ease adoption of clang-format by CUDA projects.

@mydeveloperday
Copy link
Contributor

mydeveloperday commented Jul 10, 2020

I think you are only talking about breaking after an attribute when that attribute is part of the return type correct?

should

class [[gnu::unused]] f {
   public:  f() 
   {}
}

become


class [[gnu::unused]] 
f {
  public:
  f() 
  {}
}

@allisonvacanti
Copy link
Mannequin Author

allisonvacanti mannequin commented Jul 10, 2020

I'm interested in two situations primarily:

  1. Prefix function attributes:
    __host__ __device__ [[nodiscard]]
    int foo();
  1. Prefix variable attributes:
    __shared__ [[deprecated]]
    int bar;

I'm not concerned about:

  • Infix attributes on anything:
    namespace [[deprecated]] kramble {
      int foo[[noreturn]]();
      struct [[deprecated]] baz;
    }
  • Postfix attributes on anything:

int foo() [[nodiscard]];

@JonasGilg
Copy link
Mannequin

JonasGilg mannequin commented Apr 16, 2021

I would also prefer an option to move all identifiers and attributes that come before the return type to a separate line above. As C++ gains more and more keywords that inflate the function like:

struct my_class : public other_class {
  [[nodiscard]] return_t const& my_function(parameter_t const& p) const noexcept override;
}

The function declaration just gets too long. Additionally other languages also put the prefix attributes on the line above. I.e.: Java and C#.

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 10, 2021
@mydeveloperday mydeveloperday added the enhancement Improving things as opposed to bug fixing, e.g. new or missing feature label Dec 15, 2021
valassi added a commit to valassi/madgraph4gpu that referenced this issue Feb 24, 2022
@owenca owenca added the awaiting-review Has pending Phabricator review label Jan 5, 2023
@owenca
Copy link
Contributor

owenca commented Jan 5, 2023

@owenca owenca closed this as completed in a28f074 Jan 5, 2023
@github-actions github-actions bot removed the awaiting-review Has pending Phabricator review label Jan 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla clang-format enhancement Improving things as opposed to bug fixing, e.g. new or missing feature
Projects
None yet
Development

No branches or pull requests

2 participants