Fix past-end-of-cache handling in includeCache.ExpectFile

The comments state that if ExpectFile() is called, but there are no
remaining items in the cache, it will invalidate the cache. However, the
code would only invalidate the cache if at least one item was still
present, but it didn't match the expected file. In practice, this
wouldn't usually cause issues, since adding a new file would usually
cause an invalid cache earlier on, and even if a new file was added at
the end of the compilation, it would not be in the .d file, so it would
be marked as "changed".

However, in rare circumstances, such as when the include cache would not
be properly generated due to other problems (see #230), this would cause
a crash, when ExpectFile did not invalidate the cache and the file in
question was unchanged, causing an out-of-bounds read from the cache.

This commit fixes this by making ExpectFile behave like documented and
invalidate the cache when there are no remaining entries.

Signed-off-by: Matthijs Kooijman <matthijs@stdin.nl>

Author: matthijskooijman

container_find_includes.go

@@ -213,7 +213,7 @@ func (cache *includeCache) Next() includeCacheEntry {
 // not, or no entry is available, the cache is invalidated. Does not
 // advance the cache.
 func (cache *includeCache) ExpectFile(sourcefile string) {
-	if cache.valid && cache.next < len(cache.entries) && cache.Next().Sourcefile != sourcefile {
+	if cache.valid && (cache.next >= len(cache.entries) || cache.Next().Sourcefile != sourcefile) {
 		cache.valid = false
 		cache.entries = cache.entries[:cache.next]
 	}