lifetime of `trivial_abi` parameters on the caller side

[zygoloid]

Our documentation for trivial_abi doesn't specify the lifetime of the version of the parameter on the caller side. This affects a case such as:

struct __attribute__((trivial_abi)) sso_string {
  int size;
  char *data = is_sso() ? sso : new char[size];
  char sso[24];

  bool is_sso() const { return size < 24; }

  sso_string(const char *str) : size(__builtin_strlen(str)) {
    __builtin_memcpy(data, str, size + 1);
  }
  sso_string(const sso_string &str) : size(str.size) {
    __builtin_memcpy(data, str.data, size + 1);
  }
  ~sso_string() { if (!is_sso()) delete data; }
};

This is a classical example of a type that is not trivially relocatable. However, (other than trivial_abi implying __is_trivially_relocatable) this type might still satisfy the rules for trivial_abi: when passed into a function, the data pointer may point to a different object's sso buffer, but that's OK so long as the original object is still within its lifetime.

What do we want to happen here? I suppose we have a few options:

• Intentionally support such types. We'd need a way to annotate the above type to say "this is trivial_abi, but is not trivially-relocatable".
• Somewhat-support such types. This is the status quo, as far as I can tell: the caller-side parameter object exists throughout the call, so calls work. However, we also make __is_trivially_relocatable(sso_string) evaluate to true, so std::vector<sso_string> does not work.
• Intentionally do not support such types. Document that the caller-side parameter's lifetime ends before the call.

I think the third option is probably best. While the above is "clever", I don't think it's the kind of thing we intended for trivial_abi to support.

[zygoloid]

@rjmccall This seems likely to be relevant to your interests in particular.

[rjmccall]

This type would immediately miscompile if used as a return type, so it's not a use of trivial_abi we want to encourage, even if we do decide that the temporary is guaranteed to outlive the call. And I doubt that a trivial-ABI-but-not-trivially-relocatable attribute would be a good use of anyone's time.

As for the narrow technical question about lifetimes, I guess I fall on the side of thinking the storage can immediately disappear after relocation. If the call isn't inlined, it's not likely to matter, but I could see it making some small difference after inlining. And since arguably there isn't an object there anymore, it's really weird to insist that the storage stick around.