This will call func() on an object that was retrieved from the file
serialized.data (all of it happens at runtime). The part that blocks us
from implementing it is Sema: all the lookup hooks require a predefined
set of identifiers.
Attached patch creates a last resort, dynamic lookup: if that hook
(implemented by an abstract interface) has been provided, it will get
its chance to look up a symbol but only if all the other language
foreseen lookups have failed (i.e. with lowest precedence).
We believe that the cost for clang is minimal, but for us the benefit
would be huge. Any chance that I may check it in? Of course better ideas
and / or suggestions for naming improvements are very welcome
This will call func() on an object that was retrieved from the file
serialized.data (all of it happens at runtime).
Cool!
The part that blocks us
from implementing it is Sema: all the lookup hooks require a predefined
set of identifiers.
Attached patch creates a last resort, dynamic lookup: if that hook
(implemented by an abstract interface) has been provided, it will get
its chance to look up a symbol but only if all the other language
foreseen lookups have failed (i.e. with lowest precedence).
We believe that the cost for clang is minimal, but for us the benefit
would be huge. Any chance that I may check it in? Of course better ideas
and / or suggestions for naming improvements are very welcome
This can have other uses as well, e.g. resolving names even if the header is missing.
This currently will only work for id-expressions, I'm assuming you are planning to handle failed namespace lookups, typename lookups, etc. ?
(implemented by an abstract interface) has been provided, it will get
its chance to look up a symbol but only if all the other language
foreseen lookups have failed (i.e. with lowest precedence).
This can have other uses as well, e.g. resolving names even if the header is missing.
This currently will only work for id-expressions, I'm assuming you are planning to handle failed namespace lookups, typename lookups, etc. ?
Err, we don't have a use case for those (yet). Does that mean unless we
implement namespace, typename etc you don't want to see the patch in? Or
is it okay with you as is?
It's fine by me as it is.
The others can still be added to
DynamicLookup later, by whoever needs it.
Well, I would rather see this patch handling the general case (e.g., in Sema::LookupName) rather than just id-expressions, since we don’t want to have to augment every lookup in Sema with a similar “if (DynamicLookup && DynamicLookup->PerformLookup(R, S))” statement. Did you try that and run into problems?
