Use the overloaded names infrastructure for structs

[fitzgen]

When we aren't using --enable-cxx-namespaces, we can end up with
conflicting struct symbol names that we need to disambiguate the same
way we disambiguate overloaded functions.

Fixes #267.

r? @emilio

[fitzgen]

Again, canceling this CI build until the one that fixes Travis CI lands, which is taking forever...

[emilio]

This wont work reasonably well I fear.

[emilio]

For function overloads this is fine, but for structs it's not, since we can't disambiguate them when we refer to them. I think this logic belongs to canonical_name, and indeed I think it worked at some point (see the namespacing and parent_canonical_name logic), it just needs to be tuned so it works again.

[emilio]

I think the culprit to fix this is fixing is_toplevel to check a different thing in real_canonical_path to look at the parent name more often.

[fitzgen]

I think the culprit to fix this is fixing is_toplevel to check a different thing in real_canonical_path to look at the parent name more often.

What do you suggest checking instead? I almost feel like we shouldn't allow C++ namespaces to be optional... Although that would require even more refactoring in SM bindings...

[emilio]

@fitzgen my point is that we use is_toplevel for two different things, one for which we want to ignore namespaces if they're not enabled (whitelisting, because if we don't consider them toplevel they won't get generated), and one for which we don't (naming, because if we do consider them toplevel we don't mangle the name correctly).