…ossible to feasibly implement the invokation of arrays of finalizable structs, due to the inability to know which elements in the array, which may, or may not have been, initialized to begin with. There is also no way to know what the actual length of the array is, you can know how much memory was allocated for it, but not whether there was ever a reference to that point in the array. The destructors for structs in classes are still called as they were previously, which is immediately after the body of the outer class's finalizer.

…nter to a struct. Also removed the need for a separate array of struct infos by storing the pointer to it at the end of the page for structs allocated by the GC that have finalizers.

…y initial implementation of the type info being moved to the end of the page.

…it with TypeInfo_Struct.

I also made the runtime entirely responsible for managing the type info of a finalizable struct. Previously the GC first had to retrieve this info before calling the runtime to do the finalization, even though it's the runtime that determined where to put the type info.

…e GC, and if so, have the GC run it's finalizers rather than calling the finalizer directly.

…ocation was incorrectly being treated as if it did.

…callStructDtorsDuringGC to core.memory.

Also fixed a minor issue with an import.

Also fixed the BlkInfo calculations to account for the sentinal bytes.

…EDPAD

- remove TypeInfo from gc.setAttr/setBita
- assumeSafeAppend now calls struct destructors, checks whether the array is really shrinked
- remove rt_ prefix from internal functions
- add tests

optimize by not calling TypeInfo.next again and again
remove type info argument from GC.setAttr/setBits

…ossible to feasibly implement the invokation of arrays of finalizable structs, due to the inability to know which elements in the array, which may, or may not have been, initialized to begin with. There is also no way to know what the actual length of the array is, you can know how much memory was allocated for it, but not whether there was ever a reference to that point in the array. The destructors for structs in classes are still called as they were previously, which is immediately after the body of the outer class's finalizer.

…nter to a struct. Also removed the need for a separate array of struct infos by storing the pointer to it at the end of the page for structs allocated by the GC that have finalizers.

…y initial implementation of the type info being moved to the end of the page.

…it with TypeInfo_Struct.

I also made the runtime entirely responsible for managing the type info of a finalizable struct. Previously the GC first had to retrieve this info before calling the runtime to do the finalization, even though it's the runtime that determined where to put the type info.

…e GC, and if so, have the GC run it's finalizers rather than calling the finalizer directly.

…ocation was incorrectly being treated as if it did.

…callStructDtorsDuringGC to core.memory.

Also fixed a minor issue with an import.

Also fixed the BlkInfo calculations to account for the sentinal bytes.

…EDPAD

- remove TypeInfo from gc.setAttr/setBita
- assumeSafeAppend now calls struct destructors, checks whether the array is really shrinked
- remove rt_ prefix from internal functions
- add tests

optimize by not calling TypeInfo.next again and again
remove type info argument from GC.setAttr/setBits

Trimmed the trailing whitespace on a couple of lines in rt/lifetime.d.

Fix Issue 2834 - The GC will now call destructors on heap allocated structs