Rename type parameters when they are shadowed.

[dragomirtitian]

Fixes #61334

Temporary fix. This solution will rename the type parameters. While this solution is valid it is a solution that is incompatible with what a different implementation of declaration emit could produce. This solution always renames the type parameters if they are shadowed even if this is not necessary. A correct solution would only rename them if there was an inference fallback that required access to one of the shadowed parameters.

export class A<T = any> {
  public readonly ShadowedButDoesNotRequireRenaming = <T>(): T => {
      return null as any
  }
}

export function needsRenameForShadowing<T>() {
  type A = T
  return function O<T>(t: A, t2: T) {
  }
}

The first example does not require renaming as the outer T is not used in the field type. This example could be emitted by an external tool as well. The second example does require renaming , but it can't be emitted by an external tool anyway so it's not a problem if we rename the type parameters.

I am working on a fix that does this, but it does seem important to have a fix that emits a valid declaration file.

[jakebailey]

@typescript-bot pack this

[typescript-bot]

Starting jobs; this comment will be updated as builds start and complete.

Command	Status	Results
pack this	✅ Started	✅ Results

[typescript-bot]

Hey @jakebailey, I've packed this into an installable tgz. You can install it for testing by referencing it in your package.json like so:

{
    "devDependencies": {
        "typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/164902/artifacts?artifactName=tgz&fileId=367DAA8289E2EC98AE8431B56A8D0D1624A7EC95EBF119690972DA4D79D4695B02&fileName=/typescript-5.9.0-insiders.20250304.tgz"
    }
}

and then running npm install.

---

There is also a playground for this build and an npm module you can use via "typescript": "npm:@typescript-deploys/pr-build@5.9.0-pr-61342-2".;

[weswigham]

Our contexts for shadowing/not in the full checker are approximate as well - we over-rename in many areas already. It's basically expected. What's not is rewriting any input nodes (ie, if we know we're keeping a node the user wrote, then we know that name is locked in and we have to issue an accessibility error when we try to reference it and can't reach it instead). Now, this does technically rewrite an input node, but only in areas the full checker path would have anyway, historically, so it's probably fine. It's not like it's a "semantic" rewrite, either - it's purely symbolic.

[jakebailey]

@typescript-bot cherry-pick this to release-5.8

[typescript-bot]

Starting jobs; this comment will be updated as builds start and complete.

Command	Status	Results
cherry-pick this to release-5.8	✅ Started	✅ Results

[typescript-bot]

Hey, @jakebailey! I've created #61345 for you.