[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: Clang-format configuration discussion - pt 1
On 13.11.2023 16:20, Luca Fancellu wrote: >> On 13 Nov 2023, at 11:31, Jan Beulich <jbeulich@xxxxxxxx> wrote: >> On 08.11.2023 10:53, Luca Fancellu wrote: >> -------------------------------------------------------------------------------------------------------------------------------------------------------------- >>> >>> Standard: C++03 >>> >>> --- >>> From the documentation: Parse and format C++ constructs compatible with >>> this standard. >> >> Since I continue to be puzzled - iirc you said this is because of lack >> of availability of "C99" as a value here. What's entirely unclear to >> me is: How does this matter to a tool checking coding style (which is >> largely about formatting, not any lexical or syntactical aspects)? >> >>> This value is used also in Linux. >> >> Considering how different the two styles are, I don't think this is >> overly relevant. > > Ok, maybe I understand your point, you are looking for a reason to declare > this configurable instead > of not specifying it at all? Not really, no. Here I was merely saying that with the styles being sufficiently different, what Linux uses is probably not very significant for our own decision. > If it’s that, from what I understand clang-format will use the default value > if we don’t specify anything > for this one, so it will take ‘Latest’. I think we should put a value for > this one to fix it and don’t have > surprises if that behaviour changes and seeing that also in Linux that value > is fixed increased my > confidence. > > However, if you feel that we should not specify it, I’ve done a test and not > specifying it is not changing > the current output. I can’t say that for a different clang-format version > though or if changes happen in the > future. It's fine to set values. All I'm saying is that at least I would prefer if it was also clear what exact effect the setting of a value has, especially when that does not really match the language we use in the project. >> -------------------------------------------------------------------------------------------------------------------------------------------------------------- >>> >>> AttributeMacros: >>> - '__init' >>> - '__exit' >>> - '__initdata' >>> - '__initconst' >>> - '__initconstrel' >>> - '__initdata_cf_clobber' >>> - '__initconst_cf_clobber' >>> - '__hwdom_init' >>> - '__hwdom_initdata' >>> - '__maybe_unused' >>> - '__packed' >>> - '__stdcall' >>> - '__vfp_aligned' >>> - '__alt_call_maybe_initdata' >>> - '__cacheline_aligned' >>> - '__ro_after_init' >>> - 'always_inline' >>> - 'noinline' >>> - 'noreturn' >>> - '__weak' >>> - '__inline__' >>> - '__attribute_const__' >>> - '__transparent__' >>> - '__used' >>> - '__must_check' >>> - '__kprobes' >>> >>> --- >>> A vector of strings that should be interpreted as attributes/qualifiers >>> instead of identifiers. >>> I’ve tried to list all the attributes I’ve found. >> >> Like above, the significance of having this list and needing to keep it >> up-to-date is unclear to me. I guess the same also applies to a few >> further settings down from here. > > From what I understand, we should give to the formatter tool all the hint > possible to make it do a good > job, for example here we should maintain a list of our attributes so that > clang-format doesn’t think the function > below is called __init instead of device_tree_node_matches. > > static bool __init device_tree_node_matches(const void *fdt, int node, const > char *match) > { ... } Well, perhaps they indeed need to do some level of syntax analysis, in which case knowing which identifiers act as attributes is likely going to help. Which is where the "needs keeping up-to-date" aspect comes into play. The example above is simple enough that I wouldn't think a parser needs to guess what this represents, but presumably there are cases where ambiguities might arise. (I also wouldn't exclude that the more involved syntax in C++ increases the desire to have apriori knowledge on the purpose of certain identifiers. In the end, as per above, the tool is being told to expect C++ code.) Jan
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |