-
Notifications
You must be signed in to change notification settings - Fork 29.9k
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
src: use wide string for findPackageJson onWindows #55861
base: main
Are you sure you want to change the base?
Changes from 7 commits
d0e4106
8b20a68
de6fba1
dd8ceac
a4f6830
fd7a3f5
2ad8502
c295818
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
console.log('check non-ascii'); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. During testing, it became evident that the occurrence of the error described in issue #55773 is influenced by the character encoding used by the user. For instance, users working with CP1252 are unlikely to encounter any errors, regardless of the characters they use. In contrast, users with encodings like CP932 are more prone to experiencing errors. Take the character "月" as an example, which is represented in UTF-8 as: In CP932, the byte 88 is interpreted as the leading byte of a 2-byte character, potentially causing issues. The key takeaway is that to ensure accurate regression testing, it might be necessary to test the runtime environment with character encodings other than CP1252. I also looked for other tests that might include regression testing against Windows-specific character encodings but couldn’t find any. If you have any good ideas, I’d appreciate your input. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. From what I understand, you’re looking for something along these lines: const stdoutExec = execSync('@chcp 932 >nul & \"' + process.execPath + '\" \"' + nonAsciiPath + '\"',
{ encoding: 'utf8'});
assert.strictEqual(stdoutExec, 'check non-ascii\n'); However, I wanted to point out that this code does not fail when run on the main branch on my local machine. Because of this, it might not be ideal to use this approach directly without further investigation. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thank you for your response. For instance, the following minimal C++ code reproduces the same error: int main() {
std::string path = "\x88";
std::filesystem::path file(path);
} This code alone triggers the same issue. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I am currently investigating whether it is possible to change the system's character encoding within a cctest. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,12 @@ | ||
'use strict'; | ||
|
||
const common = require('../common'); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Common must be the first import. FWIW running There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. sorry for the lint error. |
||
const path = require('path'); | ||
const { test } = require('node:test'); | ||
const assert = require('node:assert'); | ||
|
||
test('Running from a directory with non-ASCII characters', async () => { | ||
const nonAsciiPath = path.resolve(__dirname, '../fixtures/全角文字/index.js'); | ||
const { stdout } = await common.spawnPromisified(process.execPath, [nonAsciiPath]); | ||
assert.strictEqual(stdout, 'check non-ascii\n'); | ||
}); |
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.
These macros are unnecessary. Also,
str.ToString()
makes an unnecessary copy, even tho, the function isconst std::string&
.str.ToStringView()
would remove the unnecessary copy here.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.
I modified the code to avoid using macros and to use std::string_view instead.