Description of problem: ClangFormat plugin is missing a patch for LLVM. You can read it in the build description of Qt Creator: https://github.com/qt-creator/qt-creator/blob/master/README.md#clang-format Version-Release number of selected component (if applicable): How reproducible: Activate the ClangFormat plugin and restart Qt Creator. You get a warning. Steps to Reproduce: 1. 2. 3. Actual results: The indention with the ClangFormat plugin has glitches. Expected results: Works like the binaries distributed by the Qt Project. Additional info:
@llvm maintainers: Opinions about carrying https://code.qt.io/cgit/clang/llvm-project.git/commit/?h=release_130-based&id=42879d1f355fde391ef46b96a659afeb4ad7814a ?
Because with Qt Creator 8 there is no link dependency anymore on LLVM except libFormat and it is normally linked statically so you could link Qt Creator with an patched static version of libFormat.
Any update on the bug? I would use the flatpak but QtCreator is still not supporting the integration of the host system.
Tom, what do you say?
This patch needs to go upstream first, before we can consider backporting it.
(In reply to Tom Stellard from comment #5) > This patch needs to go upstream first, before we can consider backporting it. This patch will not go upstream. It provides a special case for Qt Creator. So what else do you propose?
(In reply to Marco Bubke from comment #6) > (In reply to Tom Stellard from comment #5) > > This patch needs to go upstream first, before we can consider backporting it. > > This patch will not go upstream. It provides a special case for Qt Creator. > So what else do you propose? Can we restart the discussion upstream and try to find a solution for this problem?
(In reply to Marco Bubke from comment #6) > (In reply to Tom Stellard from comment #5) > > This patch needs to go upstream first, before we can consider backporting it. > > This patch will not go upstream. It provides a special case for Qt Creator. > So what else do you propose? If you mean by upstream libFormat in LLVM there was already a discussion with the maintainer. I was not involved into it but AFAIK he does wanted that feature. It was not about if the feature was useful but indentation for an IDE was seen by him out of scope. But I was not involved into that topic directly.
What about patch libFormat only for Qt Creator and link it statically?
(In reply to Marco Bubke from comment #8) > (In reply to Marco Bubke from comment #6) > > (In reply to Tom Stellard from comment #5) > > > This patch needs to go upstream first, before we can consider backporting it. > > > > This patch will not go upstream. It provides a special case for Qt Creator. > > So what else do you propose? > > If you mean by upstream libFormat in LLVM there was already a discussion > with the maintainer. I was not involved into it but AFAIK he does wanted > that feature. It was not about if the feature was useful but indentation for > an IDE was seen by him out of scope. But I was not involved into that topic > directly. I read through the review linked in the patch: https://reviews.llvm.org/D53072 and I didn't really see any strong objections. But also the patch in that review is different than the one that is actually being used. I would recommend resubmitting the patch and starting the discussion again. Please add me as a subscriber if you decide to do this. > What about patch libFormat only for Qt Creator and link it statically? How would we do this?
>> What about patch libFormat only for Qt Creator and link it statically? > How would we do this? Giving it a quick look, one could bundle clang with qt-creator, just build libformat as a static library, and then link against that one when building the clangformat plugin. Not particularly excitied to bundle clang though, having it upstream would definitely be better.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 37 development cycle. Changing version to 37.
I've bundled a patched libClangFormat.
FEDORA-2022-b42fa09266 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-b42fa09266
FEDORA-2022-b42fa09266 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-b42fa09266` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-b42fa09266 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-b42fa09266 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.