[HLSL] SourceLocation for HLSLAttributedResourceType is imprecise
- Dominant language
- LLVM
- Stars
- 40.5k
- Forks
- 18.7k
- PR merge metrics
- PR metrics pending
Description
Consider a type alias as follows:
```hlsl
using ResourceIntAliasT = __hlsl_resource_t [[hlsl::resource_class("UAV")]] [[hlsl::contained_type(int)]];
```
Currently, the source location in the AST for this is a bit odd ([godbolt](https://hlsl.godbolt.org/z/qb7Wef1YT)):
```
TypeAliasDecl 0x152059d30 col:7 referenced ResourceIntAliasT '__hlsl_resource_t [[hlsl::resource_class(UAV)]] [[hlsl::contained_type(int)]]'
```
The `HLSLAttributedResourceType` itself should span from column 27 through 105, and the `TypeAliasDecl` should thus be from column 1 through 105. However, we're actually getting the `HLSLAttributedResourceType`'s location as columns 53-85. These are the beginning of the `resource_class` and `contained_type` identifiers respectively.
I think there are multiple problems here:
- In `clang::CreateHLSLAttributedResourceType` in `SemaHLSL`, we're finding `LocBegin` and `LocEnd` based only on `AttrList` and not taking into account the actual type decl. To fix this we probably need to modify `ConvertDeclSpecToType` in `SemaType.cpp` to pass along the location of the type decl itself (ie, `DS.getBeginLoc()` or so).
- In `SemaHLSL::handleResourceTypeAttr` we're creating an `AttributeCommonInfo` with `AL.getLoc()` instead of `AL.getRange()`, so the `SourceLocation`s of our attributes only point at the beginning.
- Even with `AL.getRange()` we're skipping the namespace and the attribute brackets. This may be unavoidable, but if so the end of the range being 103 would certainly be better than the 85 we see today.
Contributor guide
Assessment
This issue has not been assessed yet.