dexonsmith planned changes to this revision.
dexonsmith added a comment.

In D89749#2353651 <https://reviews.llvm.org/D89749#2353651>, @v.g.vassilev 
wrote:

> Thanks for the patch!! This is a super hot place for us (mostly due to 
> boost). I will try it on our end and let you know!

Great!

In D89749#2353602 <https://reviews.llvm.org/D89749#2353602>, @teemperor wrote:

> Maybe arc didn't correctly apply the patch, but this causes a few LLDB tests 
> to fail on my machine:
>
>   lldb-api :: 
> commands/expression/import-std-module/queue/TestQueueFromStdModule.py
>   lldb-api :: 
> commands/expression/import-std-module/list/TestListFromStdModule.py
>   lldb-api :: 
> commands/expression/import-std-module/forward_list-dbg-info-content/TestDbgInfoContentForwardListFromStdModule.py
>
> From the backtrace this seems like the ASTImporter needs to be updated:

Thanks for doing that legwork, I'll take a look.

> The tests are just loading a Clang module and then trying to import some 
> Decls into another ASTContext, so I don't think the error here is specific to 
> LLDB. We just don't have any ASTImporter tests that exercise modules.

I'll add one.

> FWIW, if you quickly want to see if your SourceManager changes break LLDB, 
> then you can just set the LIT_FILTER to "Modules" and run `check-lldb` as 
> LLDB's use of Clang modules are the only place where we have any valid 
> SourceLocations within LLDB.

This is helpful, thanks. I also need to deal with whatever entitlements 
`check-lldb` needs (new machine since the last time and I remember it being 
non-trivial) but I'll figure that out.

> 1. The `I - 1` everywhere when translating `SLocEntryLoaded` values to a 
> `LoadedSLocEntryTable` index is a bit cryptic. [...]

Great comment; I think the way I'll do this is to create a simple wrapper type 
that degrades to `Optional<unsigned>`.

> 2. If we have this as an Optional, we might as well make the sentinel value 
> `std::numeric_limits<unsigned>::max()` instead of 0 in `SLocEntryLoaded`. 
> Then we can just all values as-is without translating them to an index.

Could do, but there's a tradeoff since then a `resize` operation can't/doesn't 
use zero-initialization. As a result I have a (weak) preference for a 
0-sentinel (probably my next patch will keep that semantic), but I'm open to 
changing it.

> 3. Now that the primary purpose of `SLocEntryLoaded` is storing indices and 
> not the loaded status, maybe something like `SLocEntryIndices` would be a 
> better name?

Good idea.

> 4. Do you still have your benchmarking values (or some estimates) for this? 
> I'm just curious how much memory this actually saves.

I'll find some numbers if Vassil hasn't shared his by the time I've fixed the 
patch.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D89749/new/

https://reviews.llvm.org/D89749

_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to