[Lldb-commits] [PATCH] D64777: Fix CreateFunctionTemplateSpecialization to prevent dangling poiner to stack memory

[Raphael Isemann via Phabricator via lldb-commits]

teemperor added inline comments.


================
Comment at: packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/main.cpp:1
+template <typename T>
+struct M {};
----------------
shafik wrote:
> labath wrote:
> > JDevlieghere wrote:
> > > labath wrote:
> > > > teemperor wrote:
> > > > > JDevlieghere wrote:
> > > > > > Clang format?
> > > > > Pretty sure that file is clang-formatted (at least my clang-format doesn't modify this file)
> > > > We have a .clang-format file for the test directory which effectively disables clang-formatting. So depending on how you run clang-format, the invocation might be completely ignored.
> > > > 
> > > > The .clang-format was put there before the Great Reformat to avoid it messing with the line numbers in tests. Maybe the time has come to do something about it...
> > > Sounds like a good idea. Most test should be using the `// break here` anyway, and removing the special `.clang-format` might flush out the ones that don't. 
> > I'm afraid that won't be enough. All of these tests were using `// break here` comments, but that wasn't enough because
> > ```
> > some(very, long, statement) // break here
> > ```
> > breaks at a slightly different place than
> > ```
> > some(very,
> >   long, statement) // break here
> > ```
> > Also, things like step-in/over are affected by how lines are broken up, and sometimes even comment it self is so long it doesn't fit ("please break on this line to inspect the state of foo"). However, I think we could do something via some combination of telling clang-format to not break certain comments (there's a way to set a regex to match non-breakable comments), increasing the line length, and making the comments themselves much shorter...
> Ahhh that makes sense, I was going to reply the same way @teemperor did.
Oh, I was totally unaware of that. That probably means I should double-check if some of my tests were actually clang-formatted :)


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64777/new/

https://reviews.llvm.org/D64777