commit f9787c953a4630cf2d7b1444c650ee210f5dbf90
author Rosica Dejanovska <rosica@google.com> Wed Jun 22 12:14:57 2022 -0700
committer Copybara-Service <copybara-worker@google.com> Wed Jun 22 12:15:38 2022 -0700
tree ff05f8ffb8ddc27c7c93e72f4bce1b810d568cff
parent 2708a5fa5cfafaa08d7a038abbfa0b809a581829

Mark implicit class template specialization record decl `Item`s as top level

Intro:
* For implicit template specialization decls, we generate top level `Item`s (even when the decl is in a namespace)
* We use the `enclosing_namespace_id` field to fully qualify types in our bindings, eg in the generated binding `pub fn processT(test_namespace_bindings::T t)`, we obtained the `test_namespace_bindings` qualifier through the `enclosing_namespace_id` field.

Problem:

Currently crubit will take an implicit template specialization decl that belongs to a namespace and will generate a (top level) `Item` that has the field `enclosing_namespace_id` set to the parent namespace's `id`. Later on when the type is spelled out (eg, when generating code for a type alias) crubit uses the provided `enclosing_namespace_id` to construct the fully qualified identifier. This is wrong, because, as mentioned above, the generated `Item` is top level.

Eg:
```
namespace ns {
  template<typename T> struct MyStruct{T t;};
  using Alias1 = MyStruct<int>;
}
```
gets converted to
```
pub mod ns {
  // DOESN'T WORK: extra ns identifier; __CcTemplateInstN2ns8MyStructIiEE is top level
  pub type Alias1 = crate::ns::__CcTemplateInstN2ns8MyStructIiEE;
}
struct __CcTemplateInstN2ns8MyStructIiEE {
  pub t: i32,
}
```

The fix in this cl is simple: we know that implicit class template specialization `Item`s are top level, and as such we set their `enclosing_namespace_id` to `None`.

after this cl the generated bindings are:
```
pub mod ns {
  // WORKS!!!
  pub type Alias1 = crate::__CcTemplateInstN2ns8MyStructIiEE;
}
struct __CcTemplateInstN2ns8MyStructIiEE {
  pub t: i32,
}
```

PiperOrigin-RevId: 456577112