Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Handle linebreaks consistently in code fixes and refactorings #21158

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

Merged
merged 7 commits into from
Jan 19, 2018

Conversation

amcasey
Copy link
Member

@amcasey amcasey commented Jan 12, 2018

Don't store it on the context; do look in the EditorSettings before falling back on the LanguageServiceHost.

There's probably a bunch of renaming to do before this goes in.

NOTE: The code change is in the first commit.

Fixes #18291
Fixes #18445

@amcasey amcasey requested review from RyanCavanaugh and a user January 12, 2018 01:48
});
}

function getCombinedCodeFix(scope: CombinedCodeFixScope, fixId: {}, formatOptions: FormatCodeSettings): CombinedCodeActions {
synchronizeHostData();
Debug.assert(scope.type === "file");
const sourceFile = getValidSourceFile(scope.fileName);
const newLineCharacter = getNewLineOrDefaultFromHost(host);
Copy link
Contributor

Choose a reason for hiding this comment

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

we should mark this function as deprecated, and replace all its uses as well.

Copy link
Member Author

Choose a reason for hiding this comment

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

It appears to be internal. Can we just delete it?

Copy link
Member Author

Choose a reason for hiding this comment

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

Actually, the remaining callers look pretty legitimate. Is there another method they should call instead?

Copy link
Contributor

Choose a reason for hiding this comment

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

removign it should be fine then.

Copy link
Member Author

Choose a reason for hiding this comment

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

I'm confused. This method appears to have callers. Why are we deprecating/removing it?

Copy link
Contributor

Choose a reason for hiding this comment

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

looking at this again, seems like in every call to this method, we have an insufficient public API. for instance, in getDocCommentTemplateAtPosition, seems like the public API should take a FormatCodeSettings just like getCodeFixesAtPosition does.
I do not think this is related to this PR per se, but this is something that we should fix for the long term. unfortunately we can not remove the getNewLineOrDefaultFromHost as you noted without breaking our public API, but we should add optional FormatCodeSettings in places where we use it to allow the host to override the value.

Copy link
Member Author

Choose a reason for hiding this comment

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

@mhegazy Can you please confirm that the latest commit (d97dec8) is what you had in mind (not counting a bug about reviewing callers of getNewLineOrDefaultFromHost)?

Copy link
Contributor

Choose a reason for hiding this comment

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

👍

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks! Filed #21289.

@amcasey
Copy link
Member Author

amcasey commented Jan 12, 2018

Name suggestions for RefactorOrCodeFixContext are welcome since it doesn't really relate to either and doesn't cover their intersection. I was thinking of something along the lines of LazyTextChangesContext, but I thought that might be confusing.

Edit: moot

@amcasey
Copy link
Member Author

amcasey commented Jan 12, 2018

I'm also hoping there's a more idiomatic way to express the conversion from RefactorOrCodeFixContext to TextChangesContext.

Edit: moot

@@ -24,8 +24,8 @@ verify.applyCodeActionFromCompletion("b", {
source: "/a",
description: `Import 'foo' from module "./a"`,
// TODO: GH#18445
Copy link

Choose a reason for hiding this comment

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

Could you remove the TODOs too?

Copy link
Member Author

Choose a reason for hiding this comment

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

Done


export function getNewLineFromContext(context: RefactorOrCodeFixContext) {
const formatSettings = context.formatContext.options;
return formatSettings ? formatSettings.newLineCharacter : context.host.getNewLine();
Copy link

Choose a reason for hiding this comment

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

The newLineCharacter property is declared optional, so this should return context.host.getNewLine() if that's undefined.
Although it looks like getNewLine() is also optional -- see getNewLineOrDefaultFromHost.

Copy link
Member Author

Choose a reason for hiding this comment

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

Updated

@@ -78,7 +78,7 @@ namespace ts.refactor.annotateWithTypeFromJSDoc {
return Debug.fail(`!decl || !jsdocType || decl.type: !${decl} || !${jsdocType} || ${decl.type}`);
}

const changeTracker = textChanges.ChangeTracker.fromContext(context);
const changeTracker = textChanges.ChangeTracker.fromContext(toTextChangesContext(context));
Copy link

@ghost ghost Jan 12, 2018

Choose a reason for hiding this comment

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

It looks like every call to fromContext calls toTextChangesContext first -- would be easier to just do that in fromContext, and probably inline toTextChangesContext.
This would mean we don't need a TextChangesContext type, just RefactorOrCodeFixContext -- and you could rename RefactorOrCodeFixContext to TextChangesContext.

Copy link
Member Author

Choose a reason for hiding this comment

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

Great idea!

@amcasey amcasey force-pushed the NewlineConsistency branch from f46e0cd to db3f7c5 Compare January 17, 2018 23:19
@amcasey
Copy link
Member Author

amcasey commented Jan 17, 2018

Straight rebase to resolve conflicts. Will address comments in subsequent commits.

sourceFile: SourceFile;
symbolName: string;
formatContext: ts.formatting.FormatContext;
Copy link

Choose a reason for hiding this comment

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

Looks like this could be moved to ImportCodeFixContext.

Copy link
Member Author

Choose a reason for hiding this comment

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

It looks like every consumer of SymbolContext ands it with TextChangesContext anyway, so I'll just make it a subtype.

Copy link
Member Author

Choose a reason for hiding this comment

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

Do you know why SymbolContext exists? Is it to prevent certain functions from accessing certain members of ImportCodeFixContext?

Copy link

Choose a reason for hiding this comment

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

It's just there to indicate that we don't need everything from ImportCodeFixContext.

Copy link
Member Author

Choose a reason for hiding this comment

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

That seems excessive to me, but not worth changing at the moment.

@amcasey amcasey merged commit ebbb3a4 into microsoft:master Jan 19, 2018
@amcasey amcasey deleted the NewlineConsistency branch January 19, 2018 00:02
@microsoft microsoft locked and limited conversation to collaborators Jul 3, 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.

2 participants