Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix js initializer merging #24050

Merged
merged 4 commits into from
May 11, 2018
Merged

Fix js initializer merging #24050

merged 4 commits into from
May 11, 2018

Conversation

sandersn
Copy link
Member

@sandersn sandersn commented May 11, 2018

Fixes exponential merging behaviour of special js initialisers. Some baselines change because it fixes some previously incorrect merged symbol structure.

I have not tested it with Visual Studio, but it's basically the same as the fix we had working this afternoon, except that it doesn't break any of our existing tests.

Fixes #24015

Still doesn't work correctly for multiple merges
@RyanCavanaugh
Copy link
Member

Porting to 2.8

@RyanCavanaugh
Copy link
Member

Bug is #24015

RyanCavanaugh added a commit to RyanCavanaugh/TypeScript that referenced this pull request May 11, 2018
@RyanCavanaugh
Copy link
Member

Since we don't need this fix in master ASAP, let's get some test cases / asserts added to this PR. I'm running manual VS tests in the 2.8 port branch

billti added a commit that referenced this pull request May 11, 2018
@sandersn
Copy link
Member Author

I added a test case and an assert that immediately catches the problem (1) in compilation (2) in fourslash (3) in interactive VS Code usage, so I think this is ready to go.

@RyanCavanaugh
Copy link
Member

Looks good. Can you add another fourslash test for the other repro we got?

@mhegazy mhegazy merged commit cc36cfc into master May 11, 2018
@mhegazy mhegazy deleted the fix-js-initializer-merging branch May 11, 2018 17:45
@sandersn
Copy link
Member Author

@RyanCavanaugh can you send me the other minified repro? Since we didn't change the definition of getJSInitializerSymbol, and the binder code that creates symbols based on getJSInitializer is a single code path, I don't think it will prove anything new, but the cost of adding a second test is low.

Note that without the fix the assert fires for existing tests too: to wit, the ones that had changed baselines.

@RyanCavanaugh
Copy link
Member

The two repros I have are

// file1.js
blah.prototype = {
    m: "q"
};

// file2.d.ts
declare class blah { }

and

// file1.js
var N = {};
N.X = function() { };

// file2.d.ts
declare namespace N {
    class X { }
}

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.

Symbol table corruption leads to runaway memory usage
3 participants