Compiler refuses to generate a getter if omitting struct fields would leave a nested struct empty

[cameel]

Description

The compiler refuses to generate a getter for a struct if omitting all dynamic array and/or mapping fields would leave it empty. There's however a case where this happens even if the outer struct would not actually be empty. That's the case when the fields are omitted only in a nested struct. Currently the compiler reports this as an error but I think that in this case it should just omit the whole nested struct instead.

Steps to Reproduce

contract C {
    struct T { mapping(uint => uint) m; }
    struct S { uint i; T t; }
    S public x;
}

Error: Internal or recursive type is not allowed for public state variables.
 --> test.sol:4:5:
  |
4 |     S public x;
  |     ^^^^^^^^^^

Environment

• Compiler version: 0.8.10

[chriseth]

I'm not sure about this. I would prefer to "fail early" - the rules about how getters look like are already very complicated and we might get into the danger of people thinking that all the fields are there while they are not. What I'm saying is that if we generate errors more often, then people will write their own getters for complicated structures and actually see what is being returned and what not.

[cameel]

Right. I suggested making it consistent with current behavior that people are already familiar with but overall I'd much prefer errors to silently omitting fields. If that's an option I'm all for it.

Maybe we could drop this skipping mechanism altogether in a breaking release? And maybe require user to explicitly acknowledge this behavior by listing fields that he's ok with being skipped?