Singletons without structs do not generate tables in the ABI

[nsjames]

It seems that unless you use a struct within a singleton it does not generate tables:[] in the ABI.

Doing something like this in the code leads to an empty tables array.

using _owners = singleton<"owners"_n, name>;

abi output:

"tables": [],
"ricardian_clauses": [],
"variants": [],

However, if you do something like this, then the table shows up.

TABLE test {
   uint64_t test;
};
using _test = singleton<"test"_n, test>;

abi output:

"tables": [
        {
            "name": "test",
            "type": "test",
            "index_type": "i64",
            "key_names": [],
            "key_types": []
        }
    ],
"ricardian_clauses": [],
"variants": [],

[nsjames]

A little more information.

The _owners table with the name as row type is valid for usage within the contract, and also works externally if I manually specify the table in the ABI.

For instance, adding this to the tables array:

{
  "name": "owners",
  "type": "name",
  "index_type": "i64",
  "key_names": [],
  "key_types": []
}

[dimas1185]

currently eosio_abigen_visitor::VisitDecl takes T from singleton<Singletone, T> to create a table type but it supposed to be singleton<Singletone, T>::row.
Fix is to change the type T -> singleton<Singletone, T>::row in abigen.add_table. However in that case we change cases where T was a table making it a table inside a table because of the definition row { T value; uint64_t primary_key() {} }. So what is generic solution? Do we want singleton<Singletone, T>::row for non-POD type and T for POD type?

[dimas1185]

final solution is just to add table in the way @nsjames suggested above for _owners example. see #178