Skip to content

Conversation

@Bashamega
Copy link
Contributor

@github-actions
Copy link
Contributor

github-actions bot commented Nov 2, 2025

Thanks for the PR!

This section of the codebase is owned by @saschanaz - if they write a comment saying "LGTM" then it will be merged.

/** [MDN Reference](https://developer.mozilla.org/docs/Web/API/WebGLRenderingContext/getError) */
getError(): GLenum;
/** [MDN Reference](https://developer.mozilla.org/docs/Web/API/WebGLRenderingContext/getExtension) */
getExtension(name: string): any;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any idea why this got moved up? @saschanaz

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because this PR is now merging signature while originally this was using additionalSignatures, which has ordering difference. But the different order doesn't seem to affect TS behavior, while I thought it would matter, or at least it did at some point (microsoft/TypeScript#1860 (comment)). Maybe that changed.

@jakebailey, any idea?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could flip things around in the emitter.

/** [MDN Reference](https://developer.mozilla.org/docs/Web/API/WebGLRenderingContext/getError) */
getError(): GLenum;
/** [MDN Reference](https://developer.mozilla.org/docs/Web/API/WebGLRenderingContext/getExtension) */
getExtension(name: string): any;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because this PR is now merging signature while originally this was using additionalSignatures, which has ordering difference. But the different order doesn't seem to affect TS behavior, while I thought it would matter, or at least it did at some point (microsoft/TypeScript#1860 (comment)). Maybe that changed.

@jakebailey, any idea?

method getExtension {
signatures {
_ {
param extensionName type="\"ANGLE_instanced_arrays\""
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW you can also do

Suggested change
param extensionName type="\"ANGLE_instanced_arrays\""
param extensionName type=#""ANGLE_instanced_arrays""#

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which one would you prefer @saschanaz?

Copy link
Contributor

@saschanaz saschanaz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Going to the right direction

Copy link
Contributor

@saschanaz saschanaz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, assuming @jakebailey is okay with the overload ordering.

@Bashamega
Copy link
Contributor Author

I have fixed the ordering issue @saschanaz

@saschanaz
Copy link
Contributor

I don't like the last change and canceling my approval. Let's ask Jake first?

@Bashamega
Copy link
Contributor Author

Sure @saschanaz
I can revert it if you want

@saschanaz
Copy link
Contributor

saschanaz commented Nov 3, 2025

That will bring my approval back 👍

@Bashamega
Copy link
Contributor Author

I have reverted it @saschanaz

@Bashamega
Copy link
Contributor Author

Hey @saschanaz
I wrote some unit tests, and all came back working. We can merge now, I think

@saschanaz
Copy link
Contributor

Let's ask Jake first?

This.

// TypeScript should infer: ANGLE_instanced_arrays | null
assertType<ANGLE_instanced_arrays | null>(ext_ANGLE_instanced_arrays);

const ext_EXT_blend_minmax = gl.getExtension("EXT_blend_minmax");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Meh, one is enough, we don't have to cover every overload.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done


const ext_ANGLE_instanced_arrays = gl.getExtension("ANGLE_instanced_arrays");
// TypeScript should infer: ANGLE_instanced_arrays | null
assertType<ANGLE_instanced_arrays | null>(ext_ANGLE_instanced_arrays);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This won't work if ext_ is any

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you clarify?
It is never any

Copy link
Contributor

@saschanaz saschanaz Nov 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The intention of the test is to check it's not any. But if it becomes any this still won't fail.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Try giving "ANGLE_illegal" instead for getExtension.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this isn't a correct way to test this, unfortunately. If this is any, it's legal to cast to anything.

Removed multiple unused WebGL extension assertions.
@Bashamega
Copy link
Contributor Author

I have added more types @saschanaz

@saschanaz
Copy link
Contributor

Cool, thanks!

@jakebailey
Copy link
Member

Isn't it critical that the overloads are ordered most specific to least specific?

@Bashamega
Copy link
Contributor Author

Isn't it critical that the overloads are ordered most specific to least specific?

I think that changed since I wrote tests, and they worked

@jakebailey
Copy link
Member

I would be very surprised if so, given we are supposed to walk top to bottom.

How much work is it to avoid this? Is it challenging? (I am not asking for it to be changed yet)

@Bashamega
Copy link
Contributor Author

I tried to avoid it but @saschanaz didn't like the proposed solution
This was the solution ae72c10

Another solution is to just use overrideSignature like the original

@saschanaz
Copy link
Contributor

Isn't it critical that the overloads are ordered most specific to least specific?

I thought so but it works nonetheless. I thought you would know why...

@Bashamega Bashamega closed this Nov 6, 2025
@Bashamega Bashamega deleted the method-signature branch November 6, 2025 03:49
@Bashamega Bashamega restored the method-signature branch November 6, 2025 03:50
@Bashamega Bashamega reopened this Nov 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants