Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang/lib/Tooling/NodeIntrospection.cpp | ||
---|---|---|
60 | This is a slight change in behaviour, The old implementation used the operator< on a std::shared_ptr. |
clang/lib/Tooling/NodeIntrospection.cpp | ||
---|---|---|
60 | Why is that less than ideal? Does the ordering need to be stable? |
clang/lib/Tooling/NodeIntrospection.cpp | ||
---|---|---|
60 | It's not strictly necessary that the ordering is stable. but when printing the contents of the map it would be nice if there was some obvious ordering. This also (partially) mimics the behaviour of the comparison for std::pair<SourceRange, SharedLocationCall>. |
clang/lib/Tooling/NodeIntrospection.cpp | ||
---|---|---|
60 | seems like a strange tradeoff to me for the LLVM codebase - we have lots of unstable maps & don't try to make them nicer for printing - especially if that would come at any performance cost, like doing string comparisons. Does the SourceRange+SharedLocationCall need stability? |
clang/lib/Tooling/NodeIntrospection.cpp | ||
---|---|---|
60 | The purpose behind this functionality is partly based on getting clang-query to show how to get display what source location accessors can be used for specific nodes(http://ce.steveire.com/z/V3k6Rl). As this is for a user facing and not a particularly hot path, I think its worth a couple extra cycles to give stability. |
clang/lib/Tooling/NodeIntrospection.cpp | ||
---|---|---|
60 | Oh. If this is user-facing then in must be stable/deterministic (for reproducibility, testing, etc). |
Indeed, I just this evening discovered the need for this to be stable across runs for testing.
This is a slight change in behaviour, The old implementation used the operator< on a std::shared_ptr.
That in turns boils down to a comparison on the raw pointer, which is less than ideal.