Graf Zahl wrote:Have you found out what makes the compiler miscalculate? Adding a patch is fine but this looks a bit like it tries to hide the real bug by ignoring the original value.
It's not that it was miscalculating, it's because the fields simply hadn't been compiled yet.
So, the compilation of classes' and structs' fields is done in a loop until it has made sure all fields have been compiled. This is for reasons that'll be clear soon.
While compiling "ChunkSegment"'s fields, it'll hit "renderContext". This is of type "ChunkSegmentRenderContext", which is in a include file and hasn't been compiled yet; Since it's not compiled yet, its size is unknown.
This is okay, as it'll stop the struct's compilation for now, and let it try again for the next iteration of the loop, where the field's size should already be known - but note that, by this point, the "Size" member is already non-zero.
Some time after that, it'll reach the "Chunk" class. Note that this is the same iteration as before: that means "ChunkSegment" still hasn't been fully compiled yet, and its actual size is not known. Next, it tries to compile the "segments" array. This would normally fail and defer to the next iteration (like "ChunkSegment" did), but it doesn't as ChunkSegment stopped compiling in the middle of the fields, and because of that, the size is non-zero.
As the only way it checks if a type has a known size is by checking if it's not zero, that means it thinks "ChunkSegment" is done compiling prematurely, and miscompiles "Chunk"'s fields.
There's only two ways to fix this as far as I know: Add a way for it to actually know if the type really has a known size, so it can fail and defer to the next iteration (what I did) or completely rewriting that part of the compiler to work recursively instead of the way it does right now. Both are perfectly valid ways to fix it.
Obviously, the latter is not really feasible, as it would require a fairly massive amount of work.
[quote="Graf Zahl"]Have you found out what makes the compiler miscalculate? Adding a patch is fine but this looks a bit like it tries to hide the real bug by ignoring the original value.[/quote]
It's not that it was miscalculating, it's because the fields simply hadn't been compiled yet.
So, the compilation of classes' and structs' fields is done in a loop until it has made sure all fields have been compiled. This is for reasons that'll be clear soon.
While compiling "ChunkSegment"'s fields, it'll hit "renderContext". This is of type "ChunkSegmentRenderContext", which is in a include file and hasn't been compiled yet; Since it's not compiled yet, its size is unknown.
This is okay, as it'll stop the struct's compilation for now, and let it try again for the next iteration of the loop, where the field's size should already be known - but note that, by this point, the "Size" member is already non-zero.
Some time after that, it'll reach the "Chunk" class. Note that this is the same iteration as before: that means "ChunkSegment" still hasn't been fully compiled yet, and its actual size is not known. Next, it tries to compile the "segments" array. This would normally fail and defer to the next iteration (like "ChunkSegment" did), but it doesn't as ChunkSegment stopped compiling in the middle of the fields, and because of that, the size is non-zero.
As the only way it checks if a type has a known size is by checking if it's not zero, that means it thinks "ChunkSegment" is done compiling prematurely, and miscompiles "Chunk"'s fields.
There's only two ways to fix this as far as I know: Add a way for it to actually know if the type really has a known size, so it can fail and defer to the next iteration (what I did) or completely rewriting that part of the compiler to work recursively instead of the way it does right now. Both are perfectly valid ways to fix it.
Obviously, the latter is not really feasible, as it would require a fairly massive amount of work.