The background here is that I found this patch in one of my old WIP branches. The next patch in the series was going to define LLDB_API to __attribute__((visibility("default"))) on the non-windows path (and make everything else hidden), but I have no idea why I wanted to do that. I mean, it does not sounds like an *un*reasonable thing to do, but am not going to do unless I find some benefit to it (maybe it saves size?)

So what happens now if you define LLDB_IN_LIBLLDB? Does dllexport explode if used in a static library?

Before this change, it was very easy to build liblldb as a static library (just don't define IMPORT_LIBLLDB and EXPORT_LIBLLDB). After this change, this is no longer possible on Windows (but it still works fine everywhere else). Is this intentional?

This breaks tests on windows: http://45.33.8.238/win/52841/step_7.txt

Breaks a few tests on windows too: http://45.33.8.238/win/52616/step_7.txt

This breaks a bunch of tests on Mac: http://45.33.8.238/macm1/25623/step_7.txt

Could use a short comment on how to use it ("build in one build dir with propellor_phase = 1, run perf, ...") maybe.

Since this is changing serialization format you might have to do something like https://reviews.llvm.org/rGb8b7a9dcdcbc as well (see https://reviews.llvm.org/D73202 for background). I doubt that's the cause of mstorsjo's repro given that LLVM_APPEND_VC_REV is on by default, but it seems like a good thing to do in the reland regardless.

(Reverted for now.)

This breaks tests on windows: http://45.33.8.238/win/52389/step_11.txt

The test fails on Windows: http://45.33.8.238/win/52360/step_11.txt

Seems to not fail every time though.

This seems to break tests: http://45.33.8.238/macm1/25367/step_10.txt

Cool.

Nice! lgtm. One bikeshed comment about naming below (in two places, but about the same name).

That was easy :) Thanks!

That's referring to the fact that once we allocate new DirectoryLookup with SpecificBumpPtrAllocator, address of that object won't change (unlike with std::vector). This means that we can take the address and use it without worrying about invalidation.

1. which is stable thanks to the bump-ptr-allocation strategy. I don't understand this. In each slab, that's true, but why is it true between objects allocated in different slabs?
2. This increases numbers of TUs compiled for LexTests by over 10%. Is there no way around that Frontend dep?

This broke check-clangd: http://45.33.8.238/linux/64747/step_9.txt (maybe triggered by the revert for D116919 which broke check-clang-tools.)

Looks like this breaks tests: http://45.33.8.238/linux/64726/step_8.txt

Thanks for the patch!

Thanks!

Should we just land this and see what (if any) breaks?

For "why 100": My repro worked with 10, so I figured if I put in ten times that nobody should ever hit this again. Looks like that didn't work out 😓

lg!

Not sure what happened here but this change added back a whole bunch of old code. I reverted this in 085f078307bac264301b07f6e47e2a04e90a6f1d . Please carefully check git diff origin/main before committing next time :)

Thanks for noticing that. It's back and happy now.

Still broken on windows: http://45.33.8.238/win/51764/step_4.txt

Breaks building on windows: http://45.33.8.238/win/51774/step_4.txt

Thanks for the patch! This looks roughly right to me.

If this code is truly dead, this looks fine to me.

Looks like this broke check-llvm: https://lab.llvm.org/buildbot/#/builders/109/builds/28397

Thanks!

reverted in 770ef94097c02205b3ec9e902f1d6a9c99b5189c. thanks!

This breaks tests on macOS: http://45.33.8.238/macm1/23920/step_7.txt