For global variables and common blocks there is no way to create entities
through getOrCreateContextDIE(), so no need to obtain the context first.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Ah, looks like the comment was never accurate (& was copy/pasted from various other handling, which is more likely to be accurate in the other places (like types, rather than variables)) when introduced in f6b936bc062e7490cfe956d58d47ba92b46e830f
Mixed feelings about possible implications of making a (albeit NFCI) code change to match a comment rather than changing the comment to match the code. But to make this case consistent with the other cases the comment was copy/pasted from, sure let's go with this
Make getOrCreateCommonBlock() to check for existing entity first, remove outdated comments.
Mixed feelings about possible implications of making a (albeit NFCI) code change to match a comment rather than changing the comment to match the code. But to make this case consistent with the other cases the comment was copy/pasted from, sure let's go with this
Heh, this didn't seem harmful to me by the first look, but now I'm starting thinking that we may get a lot of additional map queries if the parent-child chain (for the context) is long enough.
I guess it is not possible to create a global variable through getOrCreateContextDIE() atm, the same is for fortran's common blocks. So, let's make an exception from the pattern for them.
I'd probably separate these two commits - one's updating a comment to reflect the reality of the code, the other is changing unrelated code (which, while NFCI, is a change & would be easier to track if it breaks buildbots, etc, if it's separate)
feel free to commit the global variable comment change without sending a separate review/etc
As for the common block one - yeah, that sounds OK if it's a reasonable invariant that the scope could never create the entity being created here.