[Clang] Workaround dependent source location issues #106925
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
llvmbot
added
clang
|
@llvm/pr-subscribers-clang Author: cor3ntin (cor3ntin) ChangesIn #78436 we made some SourceLocExpr dependent to However SourceLocExpr are unusual in two ways
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. Fixes #106428 Full diff: https://github.com/llvm/llvm-project/pull/106925.diff 2 Files Affected:
diff --git a/clang/lib/Sema/SemaExpr.cpp b/clang/lib/Sema/SemaExpr.cpp
index 95f53dfefbcc52..d80d5fb516bc64 100644
--- a/clang/lib/Sema/SemaExpr.cpp
+++ b/clang/lib/Sema/SemaExpr.cpp
@@ -5441,11 +5441,24 @@ struct EnsureImmediateInvocationInDefaultArgs
// Rewrite to source location to refer to the context in which they are used.
ExprResult TransformSourceLocExpr(SourceLocExpr *E) {
- if (E->getParentContext() == SemaRef.CurContext)
+ DeclContext *DC = E->getParentContext();
+ if (DC == SemaRef.CurContext)
return E;
- return getDerived().RebuildSourceLocExpr(E->getIdentKind(), E->getType(),
- E->getBeginLoc(), E->getEndLoc(),
- SemaRef.CurContext);
+
+ // FIXME: During instantiation, because the rebuild of defaults arguments
+ // is not always done in the context of the template instantiator,
+ // we run the risk of producing a dependent source location
+ // that would never be rebuilt.
+ // This usually happen during overload resolution, or in contexts
+ // where the value of the source location does not matter.
+ // However, we should find a better way to deal with source location
+ // of function template.
+ if (!SemaRef.CurrentInstantiationScope ||
+ !SemaRef.CurContext->isDependentContext() || DC->isDependentContext())
+ DC = SemaRef.CurContext;
+
+ return getDerived().RebuildSourceLocExpr(
+ E->getIdentKind(), E->getType(), E->getBeginLoc(), E->getEndLoc(), DC);
}
};
diff --git a/clang/test/SemaCXX/source_location.cpp b/clang/test/SemaCXX/source_location.cpp
index 6b3610d703e716..34177bfe287fc3 100644
--- a/clang/test/SemaCXX/source_location.cpp
+++ b/clang/test/SemaCXX/source_location.cpp
@@ -929,3 +929,63 @@ void test() {
}
}
+
+namespace GH106428 {
+
+struct add_fn {
+ template <typename T>
+ constexpr auto operator()(T lhs, T rhs,
+ const std::source_location loc = std::source_location::current())
+ const -> T
+ {
+ return lhs + rhs;
+ }
+};
+
+
+template <class _Fp, class... _Args>
+decltype(_Fp{}(0, 0))
+__invoke(_Fp&& __f);
+
+template<typename T>
+struct type_identity { using type = T; };
+
+template<class Fn>
+struct invoke_result : type_identity<decltype(__invoke(Fn{}))> {};
+
+using i = invoke_result<add_fn>::type;
+static_assert(__is_same(i, int));
+
+}
+
+#if __cplusplus >= 202002L
+
+namespace GH81155 {
+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) {});
+}
+
+}
+
+#endif
|
cor3ntin
force-pushed
the
corentin/fix_source_loc
branch
from
19a10bb
to
b561f06
Compare
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
cor3ntin
force-pushed
the
corentin/fix_source_loc
branch
from
b561f06
to
6544062
Compare
|
@AaronBallman btw, backporting that would be nice... |
AaronBallman
approved these changes
Sep 3, 2024
shafik
reviewed
Sep 4, 2024
| // However, we should find a better way to deal with source location | ||
| // of function templates. | ||
| if (!SemaRef.CurrentInstantiationScope || | ||
| !SemaRef.CurContext->isDependentContext() || DC->isDependentContext()) |
There was a problem hiding this comment.
Are we sure the DC is always not a nullptr?
There was a problem hiding this comment.
Yes, there is always a declaration context (the top one being that of the translation unit)
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/66/builds/3457 Here is the relevant piece of the build log for the reference |
cor3ntin
added a commit
to cor3ntin/llvm-project
that referenced
this pull request
Sep 4, 2024
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>
tru
pushed a commit
to cor3ntin/llvm-project
that referenced
this pull request
Sep 10, 2024
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>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In #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
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 #106428
Fixes #81155
Fixes #80210
Fixes #85373