-
-
Notifications
You must be signed in to change notification settings - Fork 385
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixed compiler-cache on Windows when there are non-ASCII characters in file path #2733
Conversation
055f63b
to
818ae83
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #2733 +/- ##
==========================================
- Coverage 67.68% 67.67% -0.02%
==========================================
Files 234 236 +2
Lines 22285 22327 +42
==========================================
+ Hits 15083 15109 +26
- Misses 6017 6030 +13
- Partials 1185 1188 +3
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Note for the future me: https://stackoverflow.com/a/921981/1655275
|
29303d8
to
dffa743
Compare
dffa743
to
7e878a8
Compare
7e878a8
to
d594ab1
Compare
d594ab1
to
cff613f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤯 Our test suite is becomings stronger and stronger 🚀
Still, it doesn't catch exactly the bug reported in the issue, but YES |
Please check if the PR fulfills these requirements
See how to contribute
before creating one)
our contributing guidelines
UPGRADING.md
has been updated with a migration guide (for breaking changes)configuration.schema.json
updated if new parameters are added.What kind of change does this PR introduce?
As reported in #2671, the compile cache is not reused on a Windows machine if a non-ASCII character is present in the path.
EDIT: This is due to a weird encoding used by GCC in writing the
.d
file. It seems the file is written the default encoding with ANSI "codepages". This patch leverages the MultiByteToWideChar API to properly decode the .d files.What is the current behavior?
Already compiled files are not reused on a Windows machine if a non-ASCII character is present in the path.
What is the new behavior?
Already compiled files are reused on a Windows machine if a non-ASCII character is present in the path.
Does this PR introduce a breaking change, and is titled accordingly?
No
Other information
Fix #2671