This patch adds support in Clang for targets to configure
the relations between address spaces, making it possible
for a target to express which address space conversions
The original RFC is here: http://lists.llvm.org/pipermail/cfe-dev/2019-March/061541.html
However, the design in this patch has deviated from the
It does multiple things to accomplish its goal:
- Moves QualType/Qualifiers accessors which deal with qualifier relations (such as compatiblyIncludes, etc.) to ASTContext, as Qualifiers cannot be made aware of the relations between address spaces on their own.
- Adds APIs to TargetInfo for querying address space relationships:
- isAddressSpaceSuperSetOf is used to ask a target whether an address space is a superspace of another. Implicit conversion from a subspace to a superspace is always allowed, but not the other way around. By default, all address spaces are disjoint.
- isExplicitAddrSpaceConversionLegal is used to ask whether an explicit conversion (e.g. via a cast) is permitted regardless of the address space relations given by the first method. By default, all explicit casts are allowed.
The ASTContext accessors will obey rules for LangASes first,
and then proceed to ask the target.
The reason for adding isExplicitAddrSpaceConversionLegal
is that according to Embedded-C, explicit casting between
all address spaces is permitted, but is undefined behavior
if the address spaces do not overlap.
This default behavior is odd, because there's no reason to
permit AS casts that will always be UB. However, as this has
been the default behavior since ASes were introduced, adding
this interface was the easiest way to keep supporting the
default behavior while also permitting targets to disallow
AS conversions that they do not want to allow.
There are still a few suspected issues with how explicit
casting is handled; in some cases, we do not know whether
we are performing an explicit cast, so we cannot know if
we should ask isExplicitAddrSpaceConversionLegal or