- User Since
- May 26 2014, 12:49 PM (281 w, 2 d)
Thu, Oct 10
In Windows you just write a Python script to do this, and this works everywhere, not just on one platform or the other, so bash isn't even necessary and Python is easy to write so I wouldn't really say it's "even harder". If you google for run-clang-format.py you'll find a script that actually branches out and does this in parallel. There's a lot of logic and smarts you could bake into an external tool which can then be used for many different programs, not just clang-format.
Planning to commit this this afternoon unless someone has objections.
Wed, Oct 9
Rebased this onto tip of trunk. I'm *finally* going to submit this.
Mon, Oct 7
Tue, Sep 24
What's the status of this patch, out of curiosity? It doesn't seem there were any objections to the original idea, just that nobody with ownership over clang-format is still actively participating in the review.
Sep 4 2019
Aug 26 2019
Finally got around to trying to commit this.
Aug 19 2019
Ugh nevermind, you can't because of the binary files. Fineeeeee.
I know it's super lame to request this, but would one of you mind submitting on my behalf? I don't have SVN installed and it seems like git llvm push still requires it (unless there is a more modern workflow that doesn't require SVN anymore). If I find myself submitting more and more patches then I'll bite the bullet.
Aug 13 2019
No objections from me on the wording of the layering portion
Jul 16 2019
Apr 29 2019
Apr 19 2019
I just built against trunk with VS 2019 and ran into this exact issue. llvm-tblgen had no command line options. Are more fixes still in the pipeline or was this thought to be sufficient?
Apr 12 2019
Apr 11 2019
Apr 10 2019
Apr 9 2019
Apr 8 2019
Apr 5 2019
Apr 3 2019
Also remove LLDBTriggerable.py
Add the scheduler back but remove the android builder only.
Apr 2 2019
Apr 1 2019
Can't you just write a function that, every time you call it, traces the symbol back to its original compile unit (you can get this from the PdbCompilandSymId), get the CompileUnit item, and ask it for its language? The part that seems unnecessary is the cache.
Is the nature of the PDB different enough that it warrants an entirely new implementation? There's a efw places where we parse decorated / undecorated names, but in general I would imagine most of the stuff is language agnostic no?
Do you have a single PDB with multiple source file languages in it? This seems like it is going to consume a ton of memory if there's one of these for each SymUID
Mar 29 2019
Nice, does this actually have any performance impact? Since the arrays are smaller and have better cache locality.
Mar 28 2019
Mar 26 2019
Mar 21 2019
Mar 20 2019
If we ever wanted more aggressive pruning of dead type information, it probably makes sense to do that as a post-processing step where we re-write the PDB, something like an llvm-pdbutil gc subcommand.