#clangd — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #clangd, aggregated by home.social.
-
Quick and dirty VSCode project for WSL/Ubuntu for getting started with coding in #C for #C64 :
https://codeberg.org/csepp/llvm-mos-sampleMade for my partner and generally for people who might be new to C and for some reason want to learn it while they also learn Commodore 64 programming. She hasn't tried it yet, so I can't vouch for the followability of the docs.
Uses #LLVMMOS / #Clang / #clangd to make things a bit more ergonomic. I know about CC65 and its debug info and VICE support was tempting, but better code navigation and static analysis IMHO wins.
PRs that set up support for other IDEs are welcome, as long as they don't break VSCode.
cc: #theWorkshop
-
Quick and dirty VSCode project for WSL/Ubuntu for getting started with coding in #C for #C64 :
https://codeberg.org/csepp/llvm-mos-sampleMade for my partner and generally for people who might be new to C and for some reason want to learn it while they also learn Commodore 64 programming. She hasn't tried it yet, so I can't vouch for the followability of the docs.
Uses #LLVMMOS / #Clang / #clangd to make things a bit more ergonomic. I know about CC65 and its debug info and VICE support was tempting, but better code navigation and static analysis IMHO wins.
PRs that set up support for other IDEs are welcome, as long as they don't break VSCode.
cc: #theWorkshop
-
Quick and dirty VSCode project for WSL/Ubuntu for getting started with coding in #C for #C64 :
https://codeberg.org/csepp/llvm-mos-sampleMade for my partner and generally for people who might be new to C and for some reason want to learn it while they also learn Commodore 64 programming. She hasn't tried it yet, so I can't vouch for the followability of the docs.
Uses #LLVMMOS / #Clang / #clangd to make things a bit more ergonomic. I know about CC65 and its debug info and VICE support was tempting, but better code navigation and static analysis IMHO wins.
PRs that set up support for other IDEs are welcome, as long as they don't break VSCode.
cc: #theWorkshop
-
Quick and dirty VSCode project for WSL/Ubuntu for getting started with coding in #C for #C64 :
https://codeberg.org/csepp/llvm-mos-sampleMade for my partner and generally for people who might be new to C and for some reason want to learn it while they also learn Commodore 64 programming. She hasn't tried it yet, so I can't vouch for the followability of the docs.
Uses #LLVMMOS / #Clang / #clangd to make things a bit more ergonomic. I know about CC65 and its debug info and VICE support was tempting, but better code navigation and static analysis IMHO wins.
PRs that set up support for other IDEs are welcome, as long as they don't break VSCode.
cc: #theWorkshop
-
Quick and dirty VSCode project for WSL/Ubuntu for getting started with coding in #C for #C64 :
https://codeberg.org/csepp/llvm-mos-sampleMade for my partner and generally for people who might be new to C and for some reason want to learn it while they also learn Commodore 64 programming. She hasn't tried it yet, so I can't vouch for the followability of the docs.
Uses #LLVMMOS / #Clang / #clangd to make things a bit more ergonomic. I know about CC65 and its debug info and VICE support was tempting, but better code navigation and static analysis IMHO wins.
PRs that set up support for other IDEs are welcome, as long as they don't break VSCode.
cc: #theWorkshop
-
I really hate using VS Code for... well, anything, really.
Thing is, I haven't yet worked out how to set up #NeoVim and #clangd for #PlatformIO and #Arduino projects. I'm guessing the Pico SDK is going to be equally as awkward when I get around to it.
Plus, there's no way to get clangd to properly interpret Psion's old 16-bit DOS-influenced C. If LLVM can't compile it, clangd doesn't seem to care about it.
-
I really hate using VS Code for... well, anything, really.
Thing is, I haven't yet worked out how to set up #NeoVim and #clangd for #PlatformIO and #Arduino projects. I'm guessing the Pico SDK is going to be equally as awkward when I get around to it.
Plus, there's no way to get clangd to properly interpret Psion's old 16-bit DOS-influenced C. If LLVM can't compile it, clangd doesn't seem to care about it.
-
I really hate using VS Code for... well, anything, really.
Thing is, I haven't yet worked out how to set up #NeoVim and #clangd for #PlatformIO and #Arduino projects. I'm guessing the Pico SDK is going to be equally as awkward when I get around to it.
Plus, there's no way to get clangd to properly interpret Psion's old 16-bit DOS-influenced C. If LLVM can't compile it, clangd doesn't seem to care about it.
-
I really hate using VS Code for... well, anything, really.
Thing is, I haven't yet worked out how to set up #NeoVim and #clangd for #PlatformIO and #Arduino projects. I'm guessing the Pico SDK is going to be equally as awkward when I get around to it.
Plus, there's no way to get clangd to properly interpret Psion's old 16-bit DOS-influenced C. If LLVM can't compile it, clangd doesn't seem to care about it.
-
I really hate using VS Code for... well, anything, really.
Thing is, I haven't yet worked out how to set up #NeoVim and #clangd for #PlatformIO and #Arduino projects. I'm guessing the Pico SDK is going to be equally as awkward when I get around to it.
Plus, there's no way to get clangd to properly interpret Psion's old 16-bit DOS-influenced C. If LLVM can't compile it, clangd doesn't seem to care about it.
-
#clangd is has issues when module import is in a header file, and not the cpp file. This is not a problem for clang, its all in the same translation unit. AFAICT this is legal and fine C++20 module code, clangd shouldn't have this issue.
-
#clangd is has issues when module import is in a header file, and not the cpp file. This is not a problem for clang, its all in the same translation unit. AFAICT this is legal and fine C++20 module code, clangd shouldn't have this issue.
-
#clangd is has issues when module import is in a header file, and not the cpp file. This is not a problem for clang, its all in the same translation unit. AFAICT this is legal and fine C++20 module code, clangd shouldn't have this issue.
-
#clangd is has issues when module import is in a header file, and not the cpp file. This is not a problem for clang, its all in the same translation unit. AFAICT this is legal and fine C++20 module code, clangd shouldn't have this issue.
-
#clangd is has issues when module import is in a header file, and not the cpp file. This is not a problem for clang, its all in the same translation unit. AFAICT this is legal and fine C++20 module code, clangd shouldn't have this issue.
-
Other projects I use every day:
#Matrix spec & clients like #FluffyChat and #nheko
#Bitwarden & #Vaultwarden password manager
#Neovim text editor
#clangd LSPI'd love to encourage these projects to jump ship, and I celebrate those that do. I am much more likely to provide quality contributions if you host on your own forge, or a free one, and I am sure I'm not alone in this.
GitHub is hostile to FOSS and, despite giving away lots of free-of-cost stuff I believe ultimately hurts us.
-
Other projects I use every day:
#Matrix spec & clients like #FluffyChat and #nheko
#Bitwarden & #Vaultwarden password manager
#Neovim text editor
#clangd LSPI'd love to encourage these projects to jump ship, and I celebrate those that do. I am much more likely to provide quality contributions if you host on your own forge, or a free one, and I am sure I'm not alone in this.
GitHub is hostile to FOSS and, despite giving away lots of free-of-cost stuff I believe ultimately hurts us.
-
Other projects I use every day:
#Matrix spec & clients like #FluffyChat and #nheko
#Bitwarden & #Vaultwarden password manager
#Neovim text editor
#clangd LSPI'd love to encourage these projects to jump ship, and I celebrate those that do. I am much more likely to provide quality contributions if you host on your own forge, or a free one, and I am sure I'm not alone in this.
GitHub is hostile to FOSS and, despite giving away lots of free-of-cost stuff I believe ultimately hurts us.
-
Other projects I use every day:
#Matrix spec & clients like #FluffyChat and #nheko
#Bitwarden & #Vaultwarden password manager
#Neovim text editor
#clangd LSPI'd love to encourage these projects to jump ship, and I celebrate those that do. I am much more likely to provide quality contributions if you host on your own forge, or a free one, and I am sure I'm not alone in this.
GitHub is hostile to FOSS and, despite giving away lots of free-of-cost stuff I believe ultimately hurts us.
-
Other projects I use every day:
#Matrix spec & clients like #FluffyChat and #nheko
#Bitwarden & #Vaultwarden password manager
#Neovim text editor
#clangd LSPI'd love to encourage these projects to jump ship, and I celebrate those that do. I am much more likely to provide quality contributions if you host on your own forge, or a free one, and I am sure I'm not alone in this.
GitHub is hostile to FOSS and, despite giving away lots of free-of-cost stuff I believe ultimately hurts us.
-
Random pro-tip: if you want use clangd on project, make sure it builds with clang when generating the
compile-commands.jsonfile.But sometimes the projects don't build with clang (I was recently looking at ipxe), and working with gcc build commands might be enough, at least on x86_64.
But on arm64, a specific flags was passed,-mabi=lp64. You can configure clangd to skip those flags on a per-project basis:
https://github.com/clangd/clangd/issues/734#issuecomment-814978138 -
Random pro-tip: if you want use clangd on project, make sure it builds with clang when generating the
compile-commands.jsonfile.But sometimes the projects don't build with clang (I was recently looking at ipxe), and working with gcc build commands might be enough, at least on x86_64.
But on arm64, a specific flags was passed,-mabi=lp64. You can configure clangd to skip those flags on a per-project basis:
https://github.com/clangd/clangd/issues/734#issuecomment-814978138 -
Random pro-tip: if you want use clangd on project, make sure it builds with clang when generating the
compile-commands.jsonfile.But sometimes the projects don't build with clang (I was recently looking at ipxe), and working with gcc build commands might be enough, at least on x86_64.
But on arm64, a specific flags was passed,-mabi=lp64. You can configure clangd to skip those flags on a per-project basis:
https://github.com/clangd/clangd/issues/734#issuecomment-814978138 -
Random pro-tip: if you want use clangd on project, make sure it builds with clang when generating the
compile-commands.jsonfile.But sometimes the projects don't build with clang (I was recently looking at ipxe), and working with gcc build commands might be enough, at least on x86_64.
But on arm64, a specific flags was passed,-mabi=lp64. You can configure clangd to skip those flags on a per-project basis:
https://github.com/clangd/clangd/issues/734#issuecomment-814978138 -
Random pro-tip: if you want use clangd on project, make sure it builds with clang when generating the
compile-commands.jsonfile.But sometimes the projects don't build with clang (I was recently looking at ipxe), and working with gcc build commands might be enough, at least on x86_64.
But on arm64, a specific flags was passed,-mabi=lp64. You can configure clangd to skip those flags on a per-project basis:
https://github.com/clangd/clangd/issues/734#issuecomment-814978138 -
So... apparently the compile_commands.json generated by #clang with `-MJ compile_commands.json` has invalid syntax so #clangd fails (silently) to load it.
And even after fixing it manually I get a lot of "Unknown argument" errors.
I'm not even working on a big project. This is just a single .cpp file. Not even a header.
It's all tools from the #LLVM project. I'm not doing anything fancy!
This is so frustrating. 🤬 -
So... apparently the compile_commands.json generated by #clang with `-MJ compile_commands.json` has invalid syntax so #clangd fails (silently) to load it.
And even after fixing it manually I get a lot of "Unknown argument" errors.
I'm not even working on a big project. This is just a single .cpp file. Not even a header.
It's all tools from the #LLVM project. I'm not doing anything fancy!
This is so frustrating. 🤬 -
@pythno Try ...
1. Install #clangd but don't setup LSP. This will disable auto completions.
2. Use #codelldb for debugging -> https://igorlfs.github.io/neovim-cpp-dbg -
@pythno Try ...
1. Install #clangd but don't setup LSP. This will disable auto completions.
2. Use #codelldb for debugging -> https://igorlfs.github.io/neovim-cpp-dbg -
@pythno Try ...
1. Install #clangd but don't setup LSP. This will disable auto completions.
2. Use #codelldb for debugging -> https://igorlfs.github.io/neovim-cpp-dbg -
@pythno Try ...
1. Install #clangd but don't setup LSP. This will disable auto completions.
2. Use #codelldb for debugging -> https://igorlfs.github.io/neovim-cpp-dbg -
Anyone here using #clangd and clang-format for #cpp and could help me with a format setting that would make operator chains put one per line?
Imagine this is too long for 1 line:
foo().bar().baz()
I want to chain transformers like so:
foo()
.bar()
.baz()But with LLVM settings, clang-format currently tries to use as few lines as possible, so I get either
foo().bar()
.baz()or
foo()
.bar().baz()depending on where I hit return with auto-formatting enabled
