Clang-expand: Expand function invocations into current scope
1–10 of 17 posts
Re: Clang-expand: Expand function invocations into current scope
#2Very very nice. But it should really be an action in clangd instead of its own tool, for simple integration with LSP.
Also instead of always replacing the text, it could also be an overlay, where the function call is temporarily expanded in your IDE while in some special mode.
Re: Clang-expand: Expand function invocations into current scope
#3Very very nice. But it should really be an action in clangd instead of its own tool, for simple integration with LSP. Also instead of always replacing the text, it could also be an overlay, where the function call is temporarily expanded in your IDE while in some special mode.
The choice between replacing and making it an overlay is up to your editor. I think it would be pretty to handle either choice as a plugin in your editor given the returned json.
I was surprised it wasn't combined with clangd.
Re: Clang-expand: Expand function invocations into current scope
#4rust-analyzer has this as well. I've never actually used it though. In most cases where I would have found it useful the function was so simple that I just did it manually without thinking. This also seems to do a better job cleaning up the resulting code than rust-analyzer does for example.
let cell = self.cell_mut(pos);
let cell = {
let ref mut this = self;
&mut this.board[usize::from(pos)]
};
let cell = &mut self.board[usize::from(pos)];
Re: Clang-expand: Expand function invocations into current scope
#5This is so cool! I want this for every language now.
Re: Clang-expand: Expand function invocations into current scope
#6Maybe I'm the only one, but... why?
What about by-hand-inlining `std::find` makes the code better?
Re: Clang-expand: Expand function invocations into current scope
#7Maybe I'm the only one, but... why? What about by-hand-inlining `std::find` makes the code better?
Clang has a statement attribute `[[clang::always_inline]]` that automates this at a call site, but GCC only has a function attribute for it. You could wrap the function in a `[[gnu::flatten]]` function that takes the callable as a non-type template parameter in C++20 to do this, though, but that could be more aggressive than what you want. It also won't work for operators as easily as this.
You can already expand macros at call site in any major C++ editor, so why not functions as well?
I would like this mainly just for making source exploration easier. Visual Studio and Clion have a "peek" feature that does something similar, but as a purely UI element, but Emacs' implementation of peek from LSP works much worse.
Re: Clang-expand: Expand function invocations into current scope
#8Maybe I'm the only one, but... why? What about by-hand-inlining `std::find` makes the code better?
It's great for doing security reviews! Often times with crazy template and macro ridden code, it's a challenge to even find the implementation for something. Sometimes it's easier to compile the binary, throw it into Ghidra, and look at the disassembly and decompilation to grok what the code is actually doing than try to bounce your way through a dozen templates and types.
Re: Clang-expand: Expand function invocations into current scope
#9Maybe I'm the only one, but... why? What about by-hand-inlining `std::find` makes the code better?
I just want to know what code is actually called. This is often a pain in C++. I assume this code handles SFINAE etc.
Re: Clang-expand: Expand function invocations into current scope
#10Maybe I'm the only one, but... why? What about by-hand-inlining `std::find` makes the code better?
Copy-pasta is typically a no-no, but this tool sure helps experiment especially when templates / types are complex.
Moreover things like SFINAE, variadic functions, and macros can make some libraries really opaque. Stuff like loggers, pub-subs, SERDES code... there will be a lot of template complexity and other indirection where this tool would help dramatically in peeling back the layers and could be used in place of breakpoints or a traditional debugger. (And it can often be hard to set up a debug session for large systems).
Can also be useful when you want to take an existing function and customize it for the call site versus write a new helper. For example maybe you want std::find_if() but instead of writing a lambda predicate you want some other code embedded into the body of the loop.