RFR (2nd round) 8071627: Code refactoring to override == operator of Symbol*

Erik Helin erik.helin at oracle.com
Thu May 28 11:12:10 UTC 2015

On 2015-05-28, John Rose wrote:
> On May 27, 2015, at 10:02 AM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
> > 
> > One note about methodHandles.   Since they have nontrivial copy constructors, they should be passed as const references to prevent copy constructor calls.
> I would love to have a robust enough C++ linter to be able to issue and check for rules like, "this type should not implicitly call its copy constructor".  I know some of those "gotchas" can be defended against using new C++11 features ("explicit"), but by no means all of them.  Linting for Symbol*::operator== is one of them that will never (?) be supported by the core language.

What about clang-tidy [0]? I haven't used it myself but it certainly
looks powerful enough, see some examples regarding contructors in the
slides at [1]. You could also probably implement a
RecursiveASTVisitor [2] using the clang framework to do the analysis.

We should use clang + llvm more :)


[0]: http://clang.llvm.org/extra/clang-tidy.html
[1]: http://llvm.org/devmtg/2014-04/PDFs/Talks/clang-tidy%20LLVM%20Euro%202014.pdf
[2]: http://clang.llvm.org/docs/RAVFrontendAction.html

> — John

More information about the hotspot-dev mailing list