Clang 18+ frontend crash on including a header file

[Sid911]

This issue is related to tcbrindle/flux#174.
Initially tested on :

Ubuntu clang version 19.0.0 (++20240222031214+307409a8872f-1~exp1~20240222151237.1514)
Target: x86_64-pc-linux-gnu
Thread model: posix

Clang 19 backtrace can be accessed here with compiler explorer link to reproduce on clang 18 here

The flux maintainer did patch a workaround in the related PR to the issue by bypassing using the iterator altogether and using internal FLUX_FOR macro but I doubt this compiler behavior is acceptable. I also have experienced this before in last 3 weeks while including some other header library unfortunately my memory is vague about what I was doing so I won't be able to reproduce it.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Siddharth Sinha (Sid911)

This issue is related to https://github.com/tcbrindle/flux/issues/174. Initially tested on : ``` Ubuntu clang version 19.0.0 (++20240222031214+307409a8872f-1~exp1~20240222151237.1514) Target: x86_64-pc-linux-gnu Thread model: posix ``` Clang 19 backtrace can be accessed [here](https://gist.github.com/Sid911/a76b694a6c69656a5fb9957a2dec2551#file-flux_clang19_stacktrace-txt) with compiler explorer link to reproduce on clang 18 [here](https://flux.godbolt.org/z/8e87j7oM6)

The flux maintainer did patch a workaround in the related PR to the issue by bypassing using the iterator altogether and using internal FLUX_FOR macro but I doubt this compiler behavior is acceptable. I also have experienced this before in last 3 weeks while including some other header library unfortunately my memory is vague about what I was doing so I won't be able to reproduce it.

[shafik]

Maybe related: #70601

[tcbrindle]

Another reproducer from the same library: https://flux.godbolt.org/z/P1PGPesoj (via tcbrindle/flux#179)

Interestingly, if we insert an explicit call to the flux::end function before the range-for loop, then compilation succeeds: https://flux.godbolt.org/z/zeK7x1K7W

Clang 16 and 17 compile the code correctly, so this looks to be a regression in 18.1

[tbaederr]

With assertions: https://flux.godbolt.org/z/66Es3chYT

Looks like it's a SourceLocExpr where the PresumedLoc we compute in EvaluateInContext is just invalid.
Not sure if this should just fail or if this should be caught earlier.

[Endilll]

One reduction of this seems to be fixed on post-18 trunk (https://godbolt.org/z/h3a8EPcq7):

template <typename>
concept sequence = true;

template <sequence S>
struct sequence_iterator {
  template <sequence SS>
  friend struct sequence_iterator;

  constexpr sequence_iterator(S) {}
};

constexpr sequence_iterator<int> end() {
  return sequence_iterator{0};
}

[zyn0217]

One reduction of this seems to be fixed on post-18 trunk (https://godbolt.org/z/h3a8EPcq7):

template <typename>

concept sequence = true;



template <sequence S>

struct sequence_iterator {

  template <sequence SS>

  friend struct sequence_iterator;



  constexpr sequence_iterator(S) {}

};



constexpr sequence_iterator<int> end() {

  return sequence_iterator{0};

}

Yeah, the pattern looks like #86769 to me.