That works right up until it doesn't. For example, if you have two interacting places where the compiler has guessed what to do, maybe the compiler resolves the interaction in the wrong way. It's the same problem that arises if you don't commit after merging into a Git repository (which, by the way, is possible but takes explicit opt-in): it keeps on working fine up until two previous merges conflict with each other.
I much prefer Rust's approach, which is to fail out but also make it extremely easy to apply the fix the compiler has guessed.
1. The compiler doesn't usually exactly know the right thing to do. E.g. in this case presumably the error should be something like "You need to order the files so that each file doesn't depend on anything further down the list." The compiler doesn't know what that order should be (maybe in this case it could figure it out, but the point is more general than just this instance).
2. Sometimes the compiler might be able to figure out what you meant but you still did it wrong. If you accept wrong code then pretty soon people will start thinking that it is right, and then you have to support it forever. This is closely related to the thoroughly disproven "Robustness Principle", which actually leads to systems that are really not robust. HTML parsing is a good example (though mostly fixed today).
I much prefer Rust's approach, which is to fail out but also make it extremely easy to apply the fix the compiler has guessed.