When working with invalid code, we would try to dereference a nullptr
while deducing template arguments in some dependend code operating on a
lambda with invalid return type.
Details
- Reviewers
hokein - Commits
- rGd462aa5a619a: [clang] Fix a nullptr dereference bug on invalid code
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang/test/SemaCXX/subst-func-type-invalid-ret-type.cpp | ||
---|---|---|
3 | A common practice is to avoid depending on STL in tests. I think we need to pull out (even simplify?) std::result_of implementation if it is needed for reproducing the crash. |
clang/test/SemaCXX/subst-func-type-invalid-ret-type.cpp | ||
---|---|---|
3 | I've noticed that pattern, but can't tell why this is. Is it documented somewhere? |
PTAL
clang/test/SemaCXX/subst-func-type-invalid-ret-type.cpp | ||
---|---|---|
3 | Anyway, I updated the change to not require type_traits. Turned out to be simpler than expected ;-) |
Thanks.
clang/test/SemaCXX/subst-func-type-invalid-ret-type.cpp | ||
---|---|---|
3 |
I did try to find some documentation about this before making the previous comment, but didn't find any. Depending on the clang builtin includes is legitimate, but depending on the stand library is more complicated, it would hurt hermeticity of the test -- you may not always get the exact behavior you intend to test (as it may depend on the stand library versions, host environment etc). |
A common practice is to avoid depending on STL in tests. I think we need to pull out (even simplify?) std::result_of implementation if it is needed for reproducing the crash.