Detect file name case issues for import

[arBmind]

This fixes #9786

[andrewrk]

Can you share what the user experience is like now when this issue occurs?

[arBmind]

stage1:

PS C:\C\Zig\path_demo\src> C:\C\Zig\repo\stage1\bin\zig.exe test main.zig
.\main.zig:6:17: error: import of 'My_types.zig' mismatches real path: 'C:\C\Zig\path_demo\src\my_types.zig'
const MyType3 = @import("My_types.zig").MyType; // capital M
                ^

stage2:

PS C:\C\Zig\path_demo\src> C:\C\Zig\repo\stage2\bin\zig.exe test main.zig                                                                      
warning(module): real path C:\C\Zig\path_demo\src\my_types.zig != imported path My_types.zig
main.zig:6:25: error: unable to load 'My_types.zig': ErrorImportPathMismatch
const MyType3 = @import("My_types.zig").MyType; // capital M
                        ^

[arBmind]

@andrewrk I can relate to your arguments and agree with the goal. This was not easy to achieve, as we cannot easily return data with the error codes. For the stage1 we already had the path. I changed the message, but did not bother to shorten the file paths here. For stage2 we have two places.

1. File fn getSource uses the source of File to return the real path. I also added logic to remove the path if they are equal. This should give us nice messages for 99% of all use cases.
2. For fn embedFile there was no convenient way. So I created a EmbedFileResult struct like ImportFileResult next door. But I use it to return the real path in case of an error.

As these are my first steps in Zig, I might have messed up some ideas. Feedback is always welcome.

[arBmind]

It seems this PR is stuck. @Vexu and @andrewrk don't seem to like my way of implementation and don't accept my explanations. I have long run out of ideas on how to usefully improve this PR or be more convincing explaining my implementation strategy.

How can we move forward from here? Do we still want this or should we just abandon it to restore peace of mind for all of us?

[andrewrk]

How can we move forward from here? Do we still want this or should we just abandon it to restore peace of mind for all of us?

Just leave it, one of us will take it from here. Thanks for your efforts :+1:

[andrewrk]

Closing this PR because it is not mergeable. The issue #9786 is still open to track the problem, and the code from this PR can be referenced just as easily with it closed.