Skip to content

Conversation

@RyanCavanaugh
Copy link
Member

Fixes #8633 and dozens of other reportings of this easily-detected error case

@DanielRosenwasser
Copy link
Member

Why are we only checking between base/derived? Basically any value-side reference to a class should be an error before its declaration.



==== tests/cases/compiler/baseTypeWrappingInstantiationChain.ts (2 errors) ====
class C<T1> extends CBase<T1> {
Copy link
Member

Choose a reason for hiding this comment

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

Can you reorder these classes to fix the error? I'd rather keep types and symbols around for tests that are not meant to exercise the new error.

Copy link
Member

Choose a reason for hiding this comment

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

And probably some of the other tests too.

Copy link
Contributor

Choose a reason for hiding this comment

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

+1

@mhegazy
Copy link
Contributor

mhegazy commented Jun 8, 2016

👍

@RyanCavanaugh RyanCavanaugh merged commit 33f72c7 into microsoft:master Jul 29, 2016
@mihailik
Copy link
Contributor

mihailik commented Jul 29, 2016

Does this cover the ordering across files when used with -outFile? That is, Derived and Base are in different files, but when compiled into the single output the order can go a wrong way — is that also reported?

Also what about this case, will it be (incorrectly) reported as an error?

function some() {
  class Derived extends Base {
  }

  return new Derived(); 
}

class Base { }

Textually Derived is preceding the Base here, but it won't be cause any problems during execution.

My logic suggests ordering warnings should only apply if Derived and Base are top-level or namespace-level classes.

@RyanCavanaugh
Copy link
Member Author

RyanCavanaugh commented Jul 29, 2016

Yep, this fix uses the function isBlockScopedNameDeclaredBeforeUse which knows how to handle both outFile ordering and "evaluated later" scenarios correctly. It's the same function we use to detect improper ordering / use of let variables so that logic should be pretty well ironed-out by now.

@microsoft microsoft locked and limited conversation to collaborators Jun 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants