ToBindingTrapFunctor seems pretty empty to me, so doesn't this always hold? I'm probably just missing details here.

ToBindingTrapFunctor is implemented by TrapEntries.h in the generated headers. This particular assertion fires whenever a final class in schema.yml has a single property (i.e. non-optional, non-repeated). For example uncommenting line 995 in schema.yml (field introducer_int in class ConcreteVarDecl) and regenerating the dbscheme file will then result in

./swift/extractor/SwiftDispatcher.h:34:5: error: static_assert failed due to requirement 'sizeof(codeql::ConcreteVarDeclsTrap) == sizeof (label)' "Binding traps of unknown entities must only have the `id` field (the class should be empty in schema.yml)"
    static_assert(sizeof(Trap) == sizeof(label),
    ^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

which should point in the correct direction.

I still don't get this, because:

template<>
struct ToBindingTrapFunctor<TrapLabel<FileTag>> {
  using type = FilesTrap;
};

pretty much looks like an empty class to me.

ah, sorry, I did not get that that was your doubt.

It's the type nested alias that does the trick. From TrapTagTraits:

template <typename T>
using BindingTrapOf = typename detail::ToBindingTrapFunctor<TrapLabelOf<T>>::type;

so for example BindingTrapOf<swift::VarDecl> will resolbe to typename detail::ToBindingTrapFunctor<TrapLabel<ConcreteVarDeclTag>>::type which in the generated file is defined as ConcreteVarDeclsTrap.

Got it. But then why do this at all and not just:

static_assert(sizeof(E) == sizeof(label),

Sure but that's because there's actual work needed to implement underlying_type it's not just an alias like we have here.

I think that alias is there to hide away an implementation detail, which does the actual work in terms of template specialization.

Would you find it clearer if we wrote something like

  template <typename Label>
  using BindingTrapOf = typename detail::ToBindingTrap<Label>::type;

and then in the code using it did:

  using Trap = BindingTrapOf<decltype(label)>;

or more explicitly

  using Label = TrapLabelOf<E>;
  using Trap = BindingTrapOf<Label>;
  Label label = assignNewLabel(e);
  ...

?

I understand less and less of what this is code is doing. Why is all this indirect mess needed at all? This is going to cause a lot of trouble for anyone who is going to maintain this in the future.

I want something that's just 2 lines of code instead of 12.

Yes, that should probably just be TrapLabel<E>{label}.?

Hmm, no, labels cannot be emitted in place of trap entries. TrapLabelOf<E> which resolves to TrapLabel<TrapTagOf<E>> (for example, TrapLabel<ConcreteVarDeclTag>) denotes a typed trap label, so something that is a # label in the trap file. We need to emit an actual trap (like concrete_var_decls(#1e)) which in C++ is done printing a ConcreteVarDeclsTrap instance.

Just for the record: @redsun82 and I discussed this face-to-face. For now I'm happy with this. I think it would be good to have another detailed look at how this is set up. My main issue is that a lot of the template programming being done here is needed to patch up the macro programming that the Swift compiler forces upon us, which feel rather brittle and difficult to maintain, due to this being split over quite a number of generated and manually implemented files. I wonder if this could be simplified significantly by moving towards more macro programming or moving towards more template programming.