source_location 18.x regression from 8c2b0d4175dcfe669a43d0173fd00ed3 #81155

AaronBallman · 2024-02-08T16:06:11Z

This was found internally at Intel from some customer code. The original test case was stripped down to:

template <bool> using enable_if_t = int;
template <class Ty> Ty Returns_exactly() noexcept;
struct InvokeBase {
  template <class Fx, class... Args>
  static auto Call(Fx func, Args... args) -> decltype(func(args...));
};
template <class Fx1, class Fx2 = Fx1, bool = false> struct Invoke;
template <class Fx1, class Fx2> struct Invoke<Fx1, Fx2, false> : InvokeBase {};
template <int> struct F { };
template <class...> struct InvocableR;
template <class Rx, class Callable, class... Args>
struct InvocableR<Rx, Callable, Args...> : 
  F<noexcept(Invoke<Rx>::Call(Returns_exactly<Rx>(), Returns_exactly<Callable>()))> {
  static constexpr bool value = false;
};
template <class Rx, class... Args> constexpr bool IsInvocableRV = InvocableR<Rx, Args...>::value;
template <class, class... Types> class FuncClass {
public:
  template <class Fx> using EnableIfCallable = enable_if_t<IsInvocableRV<Fx, Types...>>;
};
template <class> struct FuncImpl;
template <class Ret, class... Types> struct FuncImpl<Ret(Types...)> {
  using type = FuncClass<Ret, Types...>;
};
template <class FTy> class function {
  using Base = typename FuncImpl<FTy>::type;

public:
  template <class Fx, typename Base::template EnableIfCallable<Fx> = 0> function(Fx) {}
};

struct codeloc {
  static constexpr codeloc current_location(const char *name = __builtin_FUNCTION()) {
    return codeloc();
  }
  constexpr codeloc() {}
};
class buff {
public:
  buff(buff &, codeloc = codeloc::current_location());
};
void Help(function<void(buff)>) {
}
void Test() {
  Help([](buff) {});
}

https://godbolt.org/z/qao5jhv1e

And with help from @Endilll it was further reduced to:

struct buff {
  buff(buff &, const char * = __builtin_FUNCTION());
};

template <class Ty>
Ty declval();

template <class Fx>
auto Call(buff arg) -> decltype(Fx{}(arg));

template <typename>
struct F {};

template <class Fx>
struct InvocableR : F<decltype(Call<Fx>(declval<buff>()))> {
  static constexpr bool value = false;
};

template <class Fx, bool = InvocableR<Fx>::value>
void Help(Fx) {}

void Test() {
  Help([](buff) {});
}

https://godbolt.org/z/3n3K46WT8

It's possibly worth noting that the behavior may be different on Windows than on Linux.

CC @cor3ntin

llvmbot · 2024-02-08T16:06:40Z

@llvm/issue-subscribers-c-20

Author: Aaron Ballman (AaronBallman)

This was found internally at Intel from some customer code. The original test case was stripped down to: ``` template <bool> using enable_if_t = int; template <class Ty> Ty Returns_exactly() noexcept; struct InvokeBase { template <class Fx, class... Args> static auto Call(Fx func, Args... args) -> decltype(func(args...)); }; template <class Fx1, class Fx2 = Fx1, bool = false> struct Invoke; template <class Fx1, class Fx2> struct Invoke<Fx1, Fx2, false> : InvokeBase {}; template <int> struct F { }; template <class...> struct InvocableR; template <class Rx, class Callable, class... Args> struct InvocableR<Rx, Callable, Args...> : F<noexcept(Invoke<Rx>::Call(Returns_exactly<Rx>(), Returns_exactly<Callable>()))> { static constexpr bool value = false; }; template <class Rx, class... Args> constexpr bool IsInvocableRV = InvocableR<Rx, Args...>::value; template <class, class... Types> class FuncClass { public: template <class Fx> using EnableIfCallable = enable_if_t<IsInvocableRV<Fx, Types...>>; }; template <class> struct FuncImpl; template <class Ret, class... Types> struct FuncImpl<Ret(Types...)> { using type = FuncClass<Ret, Types...>; }; template <class FTy> class function { using Base = typename FuncImpl<FTy>::type;

public:
template <class Fx, typename Base::template EnableIfCallable<Fx> = 0> function(Fx) {}
};

struct codeloc {
static constexpr codeloc current_location(const char *name = __builtin_FUNCTION()) {
return codeloc();
}
constexpr codeloc() {}
};
class buff {
public:
buff(buff &, codeloc = codeloc::current_location());
};
void Help(function<void(buff)>) {
}
void Test() {
Help( {});
}

https://godbolt.org/z/qao5jhv1e

And with help from @<!-- -->Endilll it was further reduced to:

struct buff {
buff(buff &, const char * = __builtin_FUNCTION());
};

template <class Ty>
Ty declval();

template <class Fx>
auto Call(buff arg) -> decltype(Fx{}(arg));

template <typename>
struct F {};

template <class Fx>
struct InvocableR : F<decltype(Call<Fx>(declval<buff>()))> {
static constexpr bool value = false;
};

template <class Fx, bool = InvocableR<Fx>::value>
void Help(Fx) {}

void Test() {
Help( {});
}

https://godbolt.org/z/3n3K46WT8

It's possibly worth noting that the behavior may be different on Windows than on Linux.

CC @<!-- -->cor3ntin 
</details>

llvmbot · 2024-02-08T16:06:42Z

@llvm/issue-subscribers-clang-frontend

Author: Aaron Ballman (AaronBallman)

This was found internally at Intel from some customer code. The original test case was stripped down to: ``` template <bool> using enable_if_t = int; template <class Ty> Ty Returns_exactly() noexcept; struct InvokeBase { template <class Fx, class... Args> static auto Call(Fx func, Args... args) -> decltype(func(args...)); }; template <class Fx1, class Fx2 = Fx1, bool = false> struct Invoke; template <class Fx1, class Fx2> struct Invoke<Fx1, Fx2, false> : InvokeBase {}; template <int> struct F { }; template <class...> struct InvocableR; template <class Rx, class Callable, class... Args> struct InvocableR<Rx, Callable, Args...> : F<noexcept(Invoke<Rx>::Call(Returns_exactly<Rx>(), Returns_exactly<Callable>()))> { static constexpr bool value = false; }; template <class Rx, class... Args> constexpr bool IsInvocableRV = InvocableR<Rx, Args...>::value; template <class, class... Types> class FuncClass { public: template <class Fx> using EnableIfCallable = enable_if_t<IsInvocableRV<Fx, Types...>>; }; template <class> struct FuncImpl; template <class Ret, class... Types> struct FuncImpl<Ret(Types...)> { using type = FuncClass<Ret, Types...>; }; template <class FTy> class function { using Base = typename FuncImpl<FTy>::type;

public:
template <class Fx, typename Base::template EnableIfCallable<Fx> = 0> function(Fx) {}
};

struct codeloc {
static constexpr codeloc current_location(const char *name = __builtin_FUNCTION()) {
return codeloc();
}
constexpr codeloc() {}
};
class buff {
public:
buff(buff &, codeloc = codeloc::current_location());
};
void Help(function<void(buff)>) {
}
void Test() {
Help( {});
}

https://godbolt.org/z/qao5jhv1e

And with help from @<!-- -->Endilll it was further reduced to:

struct buff {
buff(buff &, const char * = __builtin_FUNCTION());
};

template <class Ty>
Ty declval();

template <class Fx>
auto Call(buff arg) -> decltype(Fx{}(arg));

template <typename>
struct F {};

template <class Fx>
struct InvocableR : F<decltype(Call<Fx>(declval<buff>()))> {
static constexpr bool value = false;
};

template <class Fx, bool = InvocableR<Fx>::value>
void Help(Fx) {}

void Test() {
Help( {});
}

https://godbolt.org/z/3n3K46WT8

It's possibly worth noting that the behavior may be different on Windows than on Linux.

CC @<!-- -->cor3ntin 
</details>

cor3ntin · 2024-02-18T16:26:40Z

I spent some time looking into this, I confirm the bug but I struggle finding a solution, or an exact root cause.
Considering __builtin_FUNCTION value dependent causes AddTemplateOverloadCandidate (for Call) to fail.

I was not able to find where we look at value dependence of default values

In llvm#78436 we made some SourceLocExpr dependent to deal with the fact that their value should reflect the name of specialized function - rather than the rtemplate in which they are first used. However SourceLocExpr are unusual in two ways - They don't depend on template argumente - They morally depend on the context in which they are used (rather than called from). It's fair to say that this is quite novels and confuses clang. In particular, in some cases, we used to create dependent SourceLocExpr and never subsequently transform them, leaving dependent objects in instantiated functions types. To work around that we avoid replacing SourceLocExpr when we think they could remain dependent. It's certainly not perfect but it fixes a number of reported bugs, and seem to only affect scenarios in which the value of the SourceLocExpr does not matter (overload resolution). Fixes llvm#106428 Fixes llvm#81155

In llvm#78436 we made some SourceLocExpr dependent to deal with the fact that their value should reflect the name of specialized function - rather than the rtemplate in which they are first used. However SourceLocExpr are unusual in two ways - They don't depend on template arguments - They morally depend on the context in which they are used (rather than called from). It's fair to say that this is quite novels and confuses clang. In particular, in some cases, we used to create dependent SourceLocExpr and never subsequently transform them, leaving dependent objects in instantiated functions types. To work around that we avoid replacing SourceLocExpr when we think they could remain dependent. It's certainly not perfect but it fixes a number of reported bugs, and seem to only affect scenarios in which the value of the SourceLocExpr does not matter (overload resolution). Fixes llvm#106428 Fixes llvm#81155 Fixes llvm#80210 Fixes llvm#85373 --------- Co-authored-by: Aaron Ballman <aaron@aaronballman.com>

AaronBallman added c++20 clang:frontend Language frontend issues, e.g. anything involving "Sema" regression rejects-valid labels Feb 8, 2024

cor3ntin mentioned this issue Jul 14, 2024

Unexpected std::source_location::file_name() result in combination with lambda and std::function #98748

Closed

cor3ntin changed the title ~~Potential 18.x regression from 8c2b0d4175dcfe669a43d0173fd00ed3~~ source_location 18.x regression from 8c2b0d4175dcfe669a43d0173fd00ed3 Jul 14, 2024

cor3ntin mentioned this issue Sep 1, 2024

[Clang] Workaround dependent source location issues #106925

Merged

cor3ntin closed this as completed in #106925 Sep 4, 2024

cor3ntin closed this as completed in 4bccb01 Sep 4, 2024

cor3ntin mentioned this issue Sep 4, 2024

[Clang] Workaround dependent source location issues (#106925) #107212

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

source_location 18.x regression from 8c2b0d4175dcfe669a43d0173fd00ed3 #81155

source_location 18.x regression from 8c2b0d4175dcfe669a43d0173fd00ed3 #81155

AaronBallman commented Feb 8, 2024 •

edited by Endilll

Loading

llvmbot commented Feb 8, 2024

llvmbot commented Feb 8, 2024

cor3ntin commented Feb 18, 2024

source_location 18.x regression from 8c2b0d4175dcfe669a43d0173fd00ed3 #81155

source_location 18.x regression from 8c2b0d4175dcfe669a43d0173fd00ed3 #81155

Comments

AaronBallman commented Feb 8, 2024 • edited by Endilll Loading

llvmbot commented Feb 8, 2024

llvmbot commented Feb 8, 2024

cor3ntin commented Feb 18, 2024

AaronBallman commented Feb 8, 2024 •

edited by Endilll

Loading