Slava Pestov af11149550 SIL: Implement the [serialized] vs [serializable] distinction ...

This generalizes a hack where re-abstraction thunks become fragile on contact
with fragile functions.

The old policy was:

- [fragile] functions always serialized
- [reabstraction_thunk] transitively referenced from fragile always serialized

The new policy is:

- [serialized] functions always serialized
- [serializable] functions transitively referenced from serialized functions
  are always serialized
- Most kinds of thunks can now be [serializable], allowing them to be shared
  between serialized and non-serialized code without any issues, as long as the
  body of the thunk is sufficiently "simple" (doesn't reference private
  symbols or performs direct access to resilient types)

2017-03-29 20:09:35 -07:00

510 B

Raw Blame History

View Raw