hahnjo wrote:
I tried to craft a test here, but declaration unloading in `clang-repl` is not
powerful enough (yet) to show a (user-visible) consequence of the problem.
On a high level, the problem should be triggered by:
```
clang-repl> template <typename T> struct A { void f() { } };
clang-repl> A<int>().f();
clang-repl> %undo
clang-repl> A<int>().f();
```
In principle, the `%undo` should remove the implicit template instantiation of
`f` which is then subsequently re-instantiated. This is currently not
implemented in `clang-repl` (we just re-use the first instantiation, which is
wrong in case there are more lines in between that could influence the
instantiation). With debug statements, I can verify that `f` is in
`UndefinedButUsed`, but `getUndefinedButUsed` filters it out.
The slightly more complex
```
clang-repl> template <typename T> struct A { void f() { } };
clang-repl> A<int>().f();
clang-repl> %undo
clang-repl> %undo
clang-repl> template <typename T> struct A { void f() { } };
clang-repl> A<int>().f();
```
ie unloading the entire class doesn't work either for the same reason, we never
actually treat the instantiated member function. (Subsequently this leads to
the entire `clang-repl` crashing after printing `definition with same mangled
name '_ZN1AIiE1fEv' as another definition`...)
https://github.com/llvm/llvm-project/pull/73955
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
