Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I do not know but maybe it makes sence to make configurable the style of the comment, e.g instead of @brief use \brief and the same for /*! to /**
Also I tried to use it now, and I'm not sure where it is a good idea to allow this tweak from within a function body. Because it is quite annoying that in every function you get this code action.
On the other hand maybe it is ok to allow it from within the body, but the tweak then should be smarter and should check whether on the function declaration the doxygen comment is already present. Also if the tweak is smarter it is fine to get this code action, as it will motivate me to get rid of it and provide a proper documentation ;-).
What do you think?
Another question that I have, whether it makes sense to add @pre and @post to the default snippet.
Sorry about the delay on this.
This looks useful - I know a lot of people write comments in this style, whatever my own reservations :-)
clang-tools-extra/clangd/refactor/tweaks/AddDoxygenComment.cpp | ||
---|---|---|
31 | nit: mark where triggering is possible with ^^s on the next line (see docs for other tweaks) IMO we should only be triggering on func itself - tweaks that fire on a large portion of the codebase reduce the signal/noise ratio too much. | |
33 | ///-style comments appear to be the most common style, followed fairly closely by /**, with /*! a distant third. (1.4M vs 1.1M vs 0.2M files in our internal codebase: we don't use doxygen comments so it's a sample of third-party libraries). /// is also the style that LLVM prefers: https://llvm.org/docs/CodingStandards.html#comment-formatting | |
34 | I'd reluctantly ask to remove @brief from the template. It hurts readability too much for people reading the code (as opposed to reading generated docs). I realize that doxygen no longer extracts any part of the comment by default, but I think it's up to them to fix their defaults. | |
38 | I'm a bit concerned about people generating these @param bar and @return and leaving them there without filling them in - I've seen plenty of code like that and it's substantially worse than no comments at all. I'm not sure we can do much though: could generate @return TODO or so to make it more visually obvious - WDYT? | |
59 | The coding style is sorely outdated on this point (indentation?!), and the code in this subproject doesn't follow it - happy to take this up on discourse if needed but I don't think we should create a mess of mixed local style here. | |
63 | "Add documentation comment"? Short is quicker to scan, and if we keep the triggering tight then it's obvious what it's for. I suspect if people care much about the flavor of doc comment, we'll end up adding config to customize it (I can see it coming with /// vs // vs /** vs /*! already...) and using a generic name is going to work better than trying to describe the style. | |
66 | west const in llvm please (and other occurrences elsewhere) | |
66 | isCommentExist => hasComment but really this is just Inputs.AST->getRawCommentForDeclNoCache(D) != nullptr, maybe just inline it? | |
75 | why? doxygen supports C AFAIK | |
79 | This may be the body of a function template, in which case we could still generate doc but it needs to be inserted above the TemplateDecl, not above the FunctionDecl. (feel free to bail out in this case though) | |
86 | I don't think we should be walking up, code actions should really be relevant to the thing the user is targeting, and I don't think e.g. pointing at a param means you want to act on the function. | |
108 | what about unnamed parameters? I think we can't usefully document them, should we skip them here or disallow the code action entirely? | |
121 | insertionPoint() is used when adding decls to a scope where we don't know the existing set. Here we already have the function, and just want to insert before it. | |
133 | these are user-visible errors, we shouldn't use AST jargon here | |
clang-tools-extra/clangd/unittests/tweaks/AddDoxygenCommentTests.cpp | ||
2 | There are some more cases to consider, which should be tested: do we do anything different if:
| |
42 | rather than 1/2 please give these somewhat descriptive names | |
54 | the whitespace here is wonky - it's not critical to get the indentation right, but it should be consistent |
clang-tools-extra/clangd/refactor/tweaks/AddDoxygenComment.cpp | ||
---|---|---|
38 | VS Code itself has support for snippets - https://code.visualstudio.com/api/references/vscode-api#TextEditor - insertSnippet - but the LSP spec doesn't yet. Once it has it I think it would makes sense to use them here, but until then, TODO seems like the best we can do? | |
75 | Would also be nice to support ObjC too, we'll just need to add support for ObjCMethodDecl as well to expand support for ObjC methods. (https://clang.llvm.org/doxygen/classclang_1_1ObjCMethodDecl.html vs https://clang.llvm.org/doxygen/classclang_1_1FunctionDecl.html) But even if that's not done in this diff, still seems fine to enable it generally? |
Hey, are you still planning to work on this? Otherwise, is it okay if I take over this patch to implement this feature?
Hi,
sorry for the long delay, but actually in this particular moment I was working on addressing the comments.
Therefore, I will push the updated patch soon.
clang-tools-extra/clangd/refactor/tweaks/AddDoxygenComment.cpp | ||
---|---|---|
25 | I prefer not to do it, because all other files with tweaks have the same style. | |
38 | I do not think that adding here TODO makes much sense, because in this case I can just type the whole comment automatically. Think about I added a template but then I need to remove part of this template because it was a placeholder. I personally think that people who do not want to fill the template properly should blame themselves for not writing a proper comment and it is not a responsibility of the clangd to motivate them to do it. What I'm not sure about whether we need to add to the template @pre and @post because this is more important as filling the parameters names. Ideally it would be good if the template can be configurable through the .clangd config. What do you think? | |
59 | See the comment above. | |
75 | What is the correct language option for the C language? I found only the enumeration of all C standards? |
Could you please also advice me what else need to be done for the ObjC, since there were many years since I wrote ObjC last time I'm not sure what else need to be done there.
Thanks.
I think this is fine for a v1 - I think the main improvement would be changing the style/format, Xcode itself uses the following format instead where <#Placeholder Name#> denotes a placeholder:
/// <#Description#> /// - Parameters: /// - arg1: <#arg1 description#> /// - arg2: <#arg2 description#> /// - Returns: <#description#>
You can merge this into namespace clang::clangd.