John W. Peterson

cppclean seems to be clever enough to determine that you can have a `std::shared_ptr` to a forward-declared type `X`, which is good. Unfortunately, if the name is hidden behind an...

cppclean thinks forward declaration is not used, but it is.

5

cppclean master reports: ``` cppclean_test2.h:4: 'Foo::Bar' not used ``` for the following code snippet. I think it may be getting tricked by the `using namespace` declaration into thinking that the...

While trying to adaptively refine a mixed-dimension mesh, I hit the following assert in `find_neighbors()` ``` Stack frames: 8 0: libMesh::print_trace(std::ostream&) 1: libMesh::MacroFunctions::report_error(char const*, int, char const*, char const*) 2:...

Test whether we need to call build_constraint_matrix() recursively

3

The hypothesis is that libmesh now expands all "recursive" constraints before calling this function, and therefore it should not need to be called recursively. This PR tests whether that is...

XDR supports gaps in Node numbering but not Elem numbering

3

There does not seem to be a fundamental reason why we couldn't support having gaps in Elem numbering in a manner similar to the way gaps in Node numbering is...

Currently we call `exII::ex_get_var_tab()` from `ExodusII_IO_Helper::read_elemental_var_values()`, but we only use the table locally within that function... it isn't saved in the class. This information could be useful in some situations,...

UnstructuredMesh::copy_nodes_and_elements() requires matching _n_parts

13

We have a case where we're hitting the following assert https://github.com/libMesh/libmesh/blob/06410d04d134290b911558d1382b559220edfa57/src/mesh/unstructured_mesh.C#L79 in `UnstructuredMesh::copy_nodes_and_elements()` via a call to `ReplicatedMesh::stitch_meshes()` while running in parallel (np=4), because the mesh being "attached" in this...

This isn't documented at all in the script, and it would probably be more correct to use the output of ``` libmesh-config --cxx ``` instead of whatever is set (or...

Fix -Wimplicit-fallthrough warnings in libHilbert

4

The libHilbert code has thousands of the following warnings: ``` ../../../../contrib/libHilbert/include/Hilbert/SetLocation.hpp:51:81: warning: this statement may fall through [-Wimplicit-fallthrough=] #define SETBIT p->racks()[ir]|=im; if ((*lr&jm)==0) p->racks()[ir]^=im; jm

The idea is to keep C++ exceptions support optional; currently they are essential to the way that `Elem::contains_point()` works so that's not ideal. See also the [discussion](https://github.com/libMesh/libmesh/pull/2717#issuecomment-703836224) on #2717.