| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
charCodeAt's doc said "Unicode value", which is ambiguous and actually describes codePointAt's behavior. codePointAt's doc led with "UTF-16 encoded code point", obscuring that it returns the full Unicode code point value (handling surrogate pairs), which is what actually distinguishes it from charCodeAt. charCodeAt now says it returns the UTF-16 code unit at the index; codePointAt now says it returns the Unicode code point value, per MDN and the issue discussion. Fixes microsoft#49561 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
There was a problem hiding this comment.
Copilot wasn't able to review any files in this pull request.
💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.
Sorry, something went wrong.
|
Shoaib Khan (@techreign) please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information. @microsoft-github-policy-service agree [company="{your company}"]
Contributor License Agreement Contribution License AgreementThis Contribution License Agreement (“Agreement”) is agreed to by the party signing below (“You”),
|
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
What was wrong
String.prototype.charCodeAt's JSDoc said it returns the "Unicode value" of
the character, which is ambiguous and actually describes what
codePointAt does. Meanwhile codePointAt's JSDoc led with "the code
point value of the UTF-16 encoded code point", which buries the fact that
it returns the full decoded Unicode code point (surrogate pairs handled),
the very thing that distinguishes it from charCodeAt. Per MDN:
position (decoding a surrogate pair if one starts there).
The repo's src/lib/*.d.ts paths from the original issue have since moved
under the Go-port restructuring; the current source of truth for these
declarations is tsc/internal/bundled/libs/lib.es5.d.ts (charCodeAt) and
tsc/internal/bundled/libs/lib.es2015.core.d.ts (codePointAt). The
hereby lib task only copies these files into built/local, it does not
generate them, so they're the correct place to fix.
What changed
"UTF-16 encoded code point", and keeps the existing surrogate-pair detail
(undefined semantics preserved, no behavior/signature change).
Doc comments only, no code or signature changes.
Fixes #49561
How it was verified
files into built/local, confirming the fix propagates through the
repo's lib-copy task without errors.
(no generated output is committed; built/ is gitignored).
Go modules only, so neither tool applies to these .d.ts files; I did
not run the full Go build/test suite per the task scope (docs-only
change, no compiler behavior affected).
Disclosure
This PR was authored with Claude Code, operated by me (the account owner
who forked and opened this PR). I read and reviewed the diff before
opening this PR, chose this specific issue deliberately, and will handle
CLA acceptance and any review feedback myself.