Prevent collision of imported type with exported declarations in current module #31231
Conversation
|
This behavior seems correct; I’m surprised at the behavior asserted by #7591. Let’s see what breaks? @typescript-bot test this |
|
Heya @andrewbranch, I've started to run the extended test suite on this PR at 1d07dde. You can monitor the build here. It should now contribute to this PR's status checks. |
|
@collin5 thanks for your patience here! Can you rebase/merge against master so we can see a proper RWC diff? The source branch is too old for me to be able to figure out if this change is actually affecting things. From reviewing #7591, it does seem like this behavior was intentional, but it’s incredibly unintuitive. I’d personally love to see it removed but we’ll have to see how it goes in our internal test suite and get others on the team to weigh in whether it’s worth a technically breaking change. |
|
Ok, I searched closer through the baselines and found that this legitimately creates errors in
In total, there are 9 errors. @DanielRosenwasser @RyanCavanaugh thoughts? |
|
@andrewbranch rebased. Thank you. |
|
@typescript-bot user test this |
|
Heya @andrewbranch, I've started to run the parallelized community code test suite on this PR at 4b08941. You can monitor the build here. It should now contribute to this PR's status checks. |
|
The user suite test run you requested has finished and failed. I've opened a PR with the baseline diff from master. |
|
User tests only turn up failures in VS Code: https://github.com/collin5/TypeScript/pull/1/files#diff-0e62d568d28b82cee9e66b2b8fafd290R7 |
| @@ -30089,6 +30089,7 @@ namespace ts { | |||
| // Based on symbol.flags we can compute a set of excluded meanings (meaning that resolved alias should not have, | |||
| // otherwise it will conflict with some local declaration). Note that in addition to normal flags we include matching SymbolFlags.Export* | |||
| // in order to prevent collisions with declarations that were exported from the current module (they still contribute to local names). | |||
| symbol = getMergedSymbol(symbol.exportSymbol || symbol); | |||
There was a problem hiding this comment.
Just to fill in some historical context here: I was curious why this was needed when #7583 and #7591 only deal with the flags on the local symbol. Dug around a bit and found #16766. If you look at the changes in the binder there, information about the export used to be attached to the local symbol when it was exporting a type, namespace, or value, but #16766 removed that info for types and namespaces. So, the info we need for this function here used to exist on the local symbol, but now we have to go to the export symbol to get it. This implementation appears correct (although I wonder if #16766 would have been done differently if the flags had been used here).
andrewbranch
added
the
Update Docs on Next Release
|
I hate to be the https://xkcd.com/1172/ person but this is actually something I liberally use to work around // a.ts
export interface A {}
// index.ts
import { A } from './a'
export type A = ANo big deal, it'll just take some, uh, intensive codemodding. The best way of dealing with this and correctly be able to elide type-only reexports with |
Fixes #31031