Skip to content

fix(semantic): correctly resolve binding for return type of functions#6388

Merged
graphite-app[bot] merged 1 commit intomainfrom
10-09-fix_semantic_correctly_resolve_binding_for_return_type_of_functions
Nov 26, 2024
Merged

fix(semantic): correctly resolve binding for return type of functions#6388
graphite-app[bot] merged 1 commit intomainfrom
10-09-fix_semantic_correctly_resolve_binding_for_return_type_of_functions

Conversation

@overlookmotel
Copy link
Member

@overlookmotel overlookmotel commented Oct 9, 2024

Fixes #6387.

@github-actions github-actions bot added the A-semantic Area - Semantic label Oct 9, 2024
Copy link
Member Author

overlookmotel commented Oct 9, 2024

@graphite-app
Copy link
Contributor

graphite-app bot commented Oct 9, 2024

Your org has enabled the Graphite merge queue for merging into main

Add the label “0-merge” to the PR and Graphite will automatically add it to the merge queue when it’s ready to merge. Or use the label “hotfix” to add to the merge queue as a hot fix.

You must have a Graphite account and log in to Graphite in order to use the merge queue. Sign up using this link.

@overlookmotel overlookmotel requested a review from Dunqing October 9, 2024 16:03
@codspeed-hq
Copy link

codspeed-hq bot commented Oct 9, 2024

CodSpeed Performance Report

Merging #6388 will create unknown performance changes

Comparing 10-09-fix_semantic_correctly_resolve_binding_for_return_type_of_functions (f3850eb) with main (b0e1c03)

Summary

🆕 30 new benchmarks

Benchmarks breakdown

Benchmark main 10-09-fix_semantic_correctly_resolve_binding_for_return_type_of_functions Change
🆕 codegen[checker.ts] N/A 24.7 ms N/A
🆕 codegen_sourcemap[checker.ts] N/A 77.5 ms N/A
🆕 isolated-declarations[vue-id.ts] N/A 406.4 ms N/A
🆕 lexer[RadixUIAdoptionSection.jsx] N/A 24.2 µs N/A
🆕 lexer[antd.js] N/A 22.3 ms N/A
🆕 lexer[cal.com.tsx] N/A 5.5 ms N/A
🆕 lexer[checker.ts] N/A 13.3 ms N/A
🆕 lexer[pdf.mjs] N/A 3.6 ms N/A
🆕 linter[RadixUIAdoptionSection.jsx] N/A 2.5 ms N/A
🆕 linter[cal.com.tsx] N/A 1.1 s N/A
🆕 linter[checker.ts] N/A 2.6 s N/A
🆕 minifier[antd.js] N/A 151 ms N/A
🆕 minifier[react.development.js] N/A 1.4 ms N/A
🆕 minifier[typescript.js] N/A 242.3 ms N/A
🆕 parser[RadixUIAdoptionSection.jsx] N/A 78.7 µs N/A
🆕 parser[antd.js] N/A 106.9 ms N/A
🆕 parser[cal.com.tsx] N/A 24.8 ms N/A
🆕 parser[checker.ts] N/A 53.5 ms N/A
🆕 parser[pdf.mjs] N/A 17.4 ms N/A
🆕 semantic[RadixUIAdoptionSection.jsx] N/A 98.3 µs N/A
... ... ... ... ...

ℹ️ Only the first 20 benchmarks are displayed. Go to the app to view all benchmarks.

@overlookmotel
Copy link
Member Author

...or at least I think it's a fix. @Dunqing could you please help me with this one?

Questions:

  1. There are various TS types which contain FormalParameters:
  • TSCallSignatureDeclaration
  • TSMethodSignature
  • TSConstructSignatureDeclaration
  • TSFunctionType
  • TSConstructorType

None of these function types have a body, so I assume we're OK to skip the extra call to resolve_references_for_current_scope for them, right?

  1. Is the func.params.kind != FormalParameterKind::Signature check required for Function and ArrowFunctionExpression? Or can their params never have kind: FormalParameterKind::Signature anyway?

  2. How/where would I add tests for this?

@Dunqing
Copy link
Member

Dunqing commented Oct 10, 2024

Questions:

  1. There are various TS types which contain FormalParameters:
  • TSCallSignatureDeclaration
  • TSMethodSignature
  • TSConstructSignatureDeclaration
  • TSFunctionType
  • TSConstructorType

None of these function types have a body, so I assume we're OK to skip the extra call to resolve_references_for_current_scope for them, right?

Right

  1. Is the func.params.kind != FormalParameterKind::Signature check required for Function and ArrowFunctionExpression? Or can their params never have kind: FormalParameterKind::Signature anyway?

Skipping func.params.kind != FormalParameterKind::Signature is ok

  1. How/where would I add tests for this?

I think as long as there are no test failures, it’s fine, so we don’t need to add tests for it.

@overlookmotel overlookmotel force-pushed the 10-09-fix_semantic_correctly_resolve_binding_for_return_type_of_functions branch from ed93641 to faa41c7 Compare October 10, 2024 10:09
@overlookmotel overlookmotel requested a review from Dunqing October 10, 2024 10:10
@overlookmotel
Copy link
Member Author

  1. Is the func.params.kind != FormalParameterKind::Signature check required for Function and ArrowFunctionExpression? Or can their params never have kind: FormalParameterKind::Signature anyway?

Skipping func.params.kind != FormalParameterKind::Signature is ok

Great. I've removed that.

  1. How/where would I add tests for this?

I think as long as there are no test failures, it’s fine, so we don’t need to add tests for it.

But #6387 was a bug, and this PR fixes it. So there should have been a test failing before, but there wasn't. So I think we should add one. I just don't know where to put it. Can you point me in right direction please?

@Dunqing
Copy link
Member

Dunqing commented Oct 10, 2024

But #6387 was a bug, and this PR fixes it. So there should have been a test failing before, but there wasn't. So I think we should add one. I just don't know where to put it. Can you point me in right direction please?

Oh, sorry, I didn't notice that. We have two ways to write semantic tests:

  1. The snapshot-based tests, you can add a test here, and then run https://github.com/oxc-project/oxc/blob/c822b48d4f7eedf4db803d158cfe7bcde24c25ea/crates/oxc_semantic/tests/main.rs#L158-L172

  2. The integration test, you can add here

Either way is ok. I prefer the first way because I can see what scopes/symbols have in the test code

@Dunqing
Copy link
Member

Dunqing commented Nov 25, 2024

Let me add tests to it

@github-actions github-actions bot added the C-bug Category - Bug label Nov 26, 2024
@Dunqing Dunqing marked this pull request as ready for review November 26, 2024 15:38
@Dunqing Dunqing requested a review from Boshen as a code owner November 26, 2024 15:38
@Boshen Boshen added the 0-merge Merge with Graphite Merge Queue label Nov 26, 2024
Copy link
Member

Boshen commented Nov 26, 2024

Merge activity

  • Nov 26, 10:41 AM EST: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
  • Nov 26, 10:47 AM EST: A user added this pull request to the Graphite merge queue.
  • Nov 26, 10:53 AM EST: A user merged this pull request with the Graphite merge queue.

@Boshen Boshen force-pushed the 10-09-fix_semantic_correctly_resolve_binding_for_return_type_of_functions branch from dd514ba to f3850eb Compare November 26, 2024 15:43
@graphite-app graphite-app bot merged commit f3850eb into main Nov 26, 2024
@graphite-app graphite-app bot deleted the 10-09-fix_semantic_correctly_resolve_binding_for_return_type_of_functions branch November 26, 2024 15:53
@overlookmotel
Copy link
Member Author

Thank you very much for cleaning up the mess I left!

@oxc-bot oxc-bot mentioned this pull request Dec 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

0-merge Merge with Graphite Merge Queue A-semantic Area - Semantic C-bug Category - Bug

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Return type of function incorrectly resolved

3 participants