Currently, the ordering of files is non-deterministic.
ie. When you pass slicec a set of files to compile, the order you pass them in is completely discarded.
This PR changes this behavior, so slicec preserves the order of files; this makes compilation more deterministic, and repeatable.
It does this at two levels:
When performing file resolution (so taking command line input and finding the files on disk), we use a HashMap. Now we use a Vec. So we will resolve files in the order that the user supplied them.
The files field of CompilationState is a HashMap, now it's a Vec. So we will parse the files in the order they were resolved, we will validate the files in the order they were resolved, etc. (The keys of the map were just file.relative_path, so it was also just redundant information... the path is already stored in the SliceFile itself.)
The only downside is we now have to use Vec::iter().find() when looking for a file, instead of HashMap::get().
Currently, the ordering of files is non-deterministic. ie. When you pass
sliceca set of files to compile, the order you pass them in is completely discarded. This PR changes this behavior, soslicecpreserves the order of files; this makes compilation more deterministic, and repeatable.It does this at two levels:
HashMap. Now we use aVec. So we will resolve files in the order that the user supplied them.filesfield ofCompilationStateis aHashMap, now it's aVec. So we will parse the files in the order they were resolved, we will validate the files in the order they were resolved, etc. (The keys of the map were justfile.relative_path, so it was also just redundant information... the path is already stored in theSliceFileitself.)The only downside is we now have to use
Vec::iter().find()when looking for a file, instead ofHashMap::get().