Auto-generate stub files for unit tests

[yadij]

No description provided.

[yadij]

For simplicity in the script, and flexibility with stub macro used - header files should be marked up with the stub detail (eg. int foo(); //STUB_RETVAL(0) )

Script supports pre-compiler #if conditional definitions, namespaces, and class methods/members.
It does not yet support sub-class definitions needing stubs.

Stubbed function/methods also need to be defined without parameter names to avoid "unused parameter" errors when compiling the stub.

For this ETag.stub.cc vs tests/stub_ETag.cc is:

@@ -1,3 +1,4 @@
+/* Generated automatically by scripts/mk-stub.awk DO NOT EDIT */
 /*
  * Copyright (C) 1996-2026 The Squid Software Foundation and contributors
  *
@@ -7,11 +8,11 @@
  */
 
 #include "squid.h"
-#include "ETag.h"
 
 #define STUB_API "ETag.cc"
 #include "tests/STUB.h"
 
+#include "ETag.h"
 int etagParseInit(ETag *, const char *) STUB_RETVAL(0)
 bool etagIsStrongEqual(const ETag &, const ETag &) STUB_RETVAL(false)
 bool etagIsWeakEqual(const ETag &, const ETag &) STUB_RETVAL(false)

[kinkie]

nice idea!

[rousskov]

Generating stubs may be a good idea, but we should not pollute primary code with STUB parts and use AWK to process them.

[yadij]

Generating stubs may be a good idea, but we should not pollute primary code with STUB parts and use AWK to process them.

Well, you are welcome to roll your own custom C++ parser to generate stubs if you really want to. Seems like a lot of unnecessary work though.

[yadij]

One other thing I have been wondering about is making the markup look like this:

  void foo(); // STUB: {}
  int bar(); // STUB: {return 0;}
  bool isFoo(); // STUB: {return false;}

... which is a bit more self-documenting than what we have now.

[kinkie]

One other thing I have been wondering about is making the markup look like this:

  void foo(); // STUB: {}
  int bar(); // STUB: {return 0;}
  bool isFoo(); // STUB: {return false;}

... which is a bit more self-documenting than what we have now.

also looks good!
My main concern is the requirement to not have variable names in declarations, as those are good for documenting

How about using [[maybe_unused]] in the generated stubs?

https://en.cppreference.com/w/cpp/language/attributes/maybe_unused.html

[rousskov]

Well, you are welcome to roll your own custom C++ parser to generate stubs if you really want to. Seems like a lot of unnecessary work though.

There are much better alternatives than the one proposed in this PR and the one proposed in the above comment.

[yadij]

Well, you are welcome to roll your own custom C++ parser to generate stubs if you really want to. Seems like a lot of unnecessary work though.

There are much better alternatives than the one proposed in this PR and the one proposed in the above comment.

All the approaches I am aware of for stub generation come down to parsing the C/C++, or some form of new markup. If you have something else, please provide some actionable response.

[yadij]

One other thing I have been wondering about is making the markup look like this:

  void foo(); // STUB: {}
  int bar(); // STUB: {return 0;}
  bool isFoo(); // STUB: {return false;}

... which is a bit more self-documenting than what we have now.

also looks good! My main concern is the requirement to not have variable names in declarations, as those are good for documenting

How about using [[maybe_unused]] in the generated stubs?

https://en.cppreference.com/w/cpp/language/attributes/maybe_unused.html

Yes, that attribute could be used when naming is needed.
I mentioned the situation to highlight the compile error as a known an expected outcome.

[kinkie]

also looks good! My main concern is the requirement to not have variable names in declarations, as those are good for documenting
How about using [[maybe_unused]] in the generated stubs?
https://en.cppreference.com/w/cpp/language/attributes/maybe_unused.html

Yes, that attribute could be used when naming is needed. I mentioned the situation to highlight the compile error as a known an expected outcome.

I would expect the attribute to be needed in the definition, not in the declaration.
If so, it's a feature of the generator and will not pollute the original file. Have you tried it?