Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[P2] Tests: boxed Number getter characterization expects obsolete receiver identity

Open Beginner friendly
  • Is something wrong?
#2,887 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
1/5
Estimated time
Under an hour
Newbie friendliness
78/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
csharp, typescript
Domain
compilers, testing

Research direction

Read PrototypeOverlayTests.InheritedPrimitiveAccessors_PreserveExistingReceiverIdentity and its compiled-only expected output. Change the getter receiver identity expectation from false to true while preserving the existing program and other checks. Run the focused test with SHARPTS_VERIFY_COMPILED=1; it is done when both execution modes produce 42\ntrue true 17\nfalse.

Written by the indexing model from the issue text.

Description

bug priority: P2

PrototypeOverlayTests.InheritedPrimitiveAccessors_PreserveExistingReceiverIdentity retains a compiled-only expected output for an older boxed Number getter limitation. Current compiled execution matches Node and the interpreter, so the old expectation fails the test.

The unchanged existing program is:

const values: any = new Number(1);
let getReceiver: any;
let setReceiver: any;
let assigned: any;
Object.defineProperty(Number.prototype, "overlayAccessor", {
    get: function(this: any): any { getReceiver = this; return 42; },
    set: function(this: any, value: any): void { setReceiver = this; assigned = value; },
    configurable: true
});
console.log(values.overlayAccessor);
values.overlayAccessor = 17;
console.log(getReceiver === values, setReceiver === values, assigned);
console.log(Object.prototype.hasOwnProperty.call(values, "overlayAccessor"));
delete (Number.prototype as any).overlayAccessor;

Node, checked interpretation and the current compiled test all produce:

42
true true 17
false

The test currently expects this for compiled mode:

42
false true 17
false

The method's comment documents the historical difference. The expected getter-identity value should now be true in both execution modes while retaining the whole program, setter/assignment checks and own-property check.

Evidence: the exact original C# raw literal (14 CRLF lines, no trailing newline; SHA-256 362E6690D0A195A2A78134A81498AF9FA99CE6D50CD1F197CE92723FEE75BF0C) passed TypeScript strict admission, then produced the full correct output in Node and checked interpretation. Each process exited 0, drained both streams, stayed within its 20-second deadline, and had empty stderr. The normal compiled test in the focused run with SHARPTS_VERIFY_COMPILED=1 reached whole-output equality and reported the same complete actual output, under test ID 8b726f31-b369-8c16-5fbb-5a51d591563e.

Measured against unchanged production at local commit a010e9d8fa850574deb67db8e51590d50293ac3f with only the new #2825 public regression added. Runtime SHA-256 87AA6212165C9908394D1E9E1C5E481FE3F9772FCB408A3BFDDC65003375FD80; source/input/runtime package guards were retained. This identifies a stale test expectation; it does not identify an introducing commit or request a compiler behavior change. Encountered while validating #2825, whose String.prototype fix is separate.

Dominant language
C#
Stars
156
Forks
4
Avg merge
4h 52m
Merged PRs (30d)
45

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from nickna/SharpTS

All issues in nickna/SharpTS

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.