Open OmnipotentEntity opened 9 years ago
This is most certainly a bug. It's a little bit hard to debug since I'm not sure how to reproduce the issue. The problem seems to be that the parent of a Method node isn't set correctly (only classes should be parents of methods, not namespaces). It would be great if you could produce a small failing test case.
I'll do my best.
Ok, here is a minimal example of this issue:
template<typename T>
struct Foo {
int baz(T const& t) const { }
};
template<typename T, int N>
class Bar { };
template<typename T, int N>
struct Foo<Bar<T, N>> {
int baz(Bar<T, N> const& a) const;
};
template<typename T, int N>
int Foo<Bar<T, N>>::baz(Bar<T, N> const& a) const { }
Whereas this works:
template<typename T>
struct Foo {
int baz(T const& t) const { }
};
template<typename T, int N>
class Bar { };
template<typename T, int N>
struct Foo<Bar<T, N>> {
int baz(Bar<T, N> const& a) const { }
};
Command:
cldoc generate -std=c++11 -- --output html ./min.cpp
Ok, I found the issue which is that cldoc doesn't yet have support for partial template specializations. I'll have to take a deeper look into how to properly implement this.
Ugh, I knew I should have tested every single damn part before reporting. I had originally pared this down from the StarArray.hpp file, which meant I eventually wound up with the file named StarArray-it10.hpp. I figured that filename wouldn't matter, so I didn't test it.
Files ending in .cc or .cpp work with the given test code. Files ending in .h or .hpp don't.
I think that's something else. cldoc only generates documentation for public API. If there is no header (i.e. declaration) of a symbol associated to the definition of it, then it will skip that symbol.
That's actually good information for me. That means essentially that I don't need to run this on .cpp files at all?
The following patch fixes symptoms of the problem, probably not the reason. The reason as it seems to me, is that the method definition is processed in the global context, with self.parent being equal to Root or Namespace, not the Class. I'm not sure that this doesn't lead to mistakes in doc generation, but at least it doesn't explode.
diff --git a/cldoc/nodes/method.py b/cldoc/nodes/method.py
index f910241..3e1208f 100644
--- a/cldoc/nodes/method.py
+++ b/cldoc/nodes/method.py
@@ -40,7 +40,7 @@ class Method(Function):
return self._override
# Lookup in bases, recursively
- bases = list(self.parent.bases)
+ bases = list(getattr(self.parent, "bases", []))
mname = self.name
self._override = []
This is indeed not the cause of the problem, and fixing it like that would just hide the underlying issues. The actual issue is that cldoc does not handle the partial specialization node kind (it actually outputs this also at the top normally). Since the template specialization class is not being registered, it will not be found when resolving the parent of the method which then results in the scope just above (in this case the namespace).
Just chiming in to say that I'm also getting this, manifesting as
AttributeError: 'Root' object has no attribute 'bases'
For now, I've patched locally as per @amorozov's suggestion (thanks). Thanks for keeping us updated.
What's the state of this? Reffering to both this issue and the project in general...
Hi there,
I'm setting up cldocs on a largish (120k sloc) codebase. Partway through I got this traceback:
The command line issued is too long to be pasted here but can be found at http://pastebin.com/JxWf9hRB
The contents of StarCircle.hpp can be found at http://pastebin.com/yxnpNEK7
When documenting just StarCircle it completes without issue. So does StarClock.hpp (the next file). Unfortunately, I don't have any ideas on what steps to take beyond this.
Is this a bug, or am I doing something wrong?