================
@@ -386,6 +386,10 @@ def __contains__(self, other):
# same file, in between lines
if self.start.line < other.line < self.end.line:
return True
+ # between columns in one-liner range
+ elif self.start.line == other.line == self.end.line:
----------------
DeinAlptraum wrote:
Clarification because I probably expressed myself inaccurately:
On C-side, in `SourceLocation.h` we implement `operator==`, `operator<=` both
as direct comparisons on the raw encoding (`SourceLocation::getRawEncoding()`).
This is not file-sensitive.*
On the C/Python _bindings_ side, we already expose `clang_equalLocations`,
which looks like this:
```
unsigned clang_equalLocations(CXSourceLocation loc1, CXSourceLocation loc2) {
return (loc1.ptr_data[0] == loc2.ptr_data[0] &&
loc1.ptr_data[1] == loc2.ptr_data[1] &&
loc1.int_data == loc2.int_data);
}
```
This _is_ file sensitive. The problem arises because this function is used
already to implement `SourceLocation.__eq__` on the Python bindings side. This
means that the internal `SourceLocation::operator==` is inconsistent with the
bindings' `SourceLocation.__eq__` (the latter is file-sensitive, the former is
not). The C-bindings are not affected by this as they do not implement
`CXSourceLocation::opreraor==` or `CXSourceLocation::opreraor<=`.
*Note that this is not obvious from the code (at least to me) and I'm not
familiar with the C side yet, so I tested this manually in Python, by exposing
these operators to the Python bindings (pls don't judge me)
https://github.com/llvm/llvm-project/pull/101802
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
