[clang] Assertion hit in CallExpr::getBeginLoc(): assert(HasFirstArg) fails
#130272
Comments
|
#117841 is the PR that introduced the problem. |
|
@llvm/issue-subscribers-clang-frontend Author: Jan Kokemüller (jiixyj)
I'm getting an assertion hit in `CallExpr::getBeginLoc()`:
A snippet of the stacktrace (I can send you the full one on request): The problematic code in 286
287 bool next_arg(std::string_view& current_arg, argument_input_iterator& in, ldgr::util::any_sentinel s)
288 {
289 ++in;
290 if (in == s) { // <----- it crashes here
291 throw args_parse_error{std::format("option '--{}' needs an argument", long_name_)};
292 }
293 return this->set_result(current_arg, in, *in);
294 } This leads to the following function: template <std::sentinel_for<It> S>
bool operator==(this input_iterator_ref self, const S& s)
{
return *self.it_ == s;
}i.e. a comparison operator with an explicit object parameter. @HighCommander4 : I've seen that you have done some work in this area -- maybe this is another special case that must be added? I can try to create a minimal example. At the moment I can workaround the crash by adding |
|
Can you provide a minimal reproducer, preferably w/ a godbolt link demonstrating the crash? |
Note that a more recent PR, #126868, made I left the assertion in to try to flush out remaining edge cases and produce a better begin location in those cases as well. It sounds like you've stumbled onto such an edge case. I'm happy to investigate it given a reproducer. |
|
Thank you! I've managed to reduce it down to this example that uses a conversion operator with an explicit this parameter: struct A {};
struct B {
operator A(this B);
} _ = A(B{});https://godbolt.org/z/Ye9PvExhf |
|
...and a less minimal one, but one that should actually compile correctly: struct C {};
template <typename D> struct A {
operator C(this D);
};
struct B : A<B> {};
auto _ = C(B{});https://godbolt.org/z/Pe868YfnT |
|
Thanks for the reproducer! So the The
Such I don't think we care about the However, it's not immediately clear how I can tell that a given |
I don't think we need to strictly distinguish these peculiar expressions, perhaps we could simply validate the number of arguments when computing the source location and skip the refining logic if no arguments are otherwise available. I.e. remove the assertion anyway. |
There are cases where the assertion legitimately does not hold (e.g. CallExpr::CreateTemporary()), and there's no readily available way to tell such cases apart. Fixes llvm#130272
Makes sense, thanks! Sent out #130725. |
There are cases where the assertion legitimately does not hold (e.g. CallExpr::CreateTemporary()), and there's no readily available way to tell such cases apart. Fixes llvm#130272
…BeginLoc() (#130725) There are cases where the assertion legitimately does not hold (e.g. CallExpr::CreateTemporary()), and there's no readily available way to tell such cases apart. Fixes llvm/llvm-project#130272
I'm getting an assertion hit in
CallExpr::getBeginLoc():A snippet of the stacktrace (I can send you the full one on request):
The problematic code in
args.cppm:This leads to the following function:
i.e. a comparison operator with an explicit object parameter.
@HighCommander4 : I've seen that you have done some work in this area -- maybe this is another special case that must be added?
I can try to create a minimal example. At the moment I can workaround the crash by adding
&& getNumArgs() > 0to theifstatement.The text was updated successfully, but these errors were encountered: