reference path with quotes doesnot have same result as in old compiler

[sheetalkamat]

New compiler:
tsc tests\baselines\reference\project\quotesInFileAndDirectoryNames\node\m'ain.d.ts

Error:
tests/baselines/reference/project/quotesInFileAndDirectoryNames/node/m'ain.d.ts(1,1): File 'tests/baselines/reference/project/quotesInFileAndDirectoryNames/node/li.ts' not found.

Old compiler:
No error

Note we either need to fix the reference path resolution for the quotes, or fix the declaration emitter to handle the quotes correctly in reference path

[mhegazy]

quotes in file names are accepted by the file system so there is no reason to disallow them.

[sheetalkamat]

Old compiler could parse the below reference as li'b/class'A.d.ts

/// <reference path='li'b/class'A.d.ts' />
declare class ClassC extends test.ClassA {
}

New one parses this as li

@mhegazy we want to behave like old compiler here right? Or should user be writing the reference as "li'b/class'A.d.ts" instead?

[mhegazy]

@sheetalkamat "Li'b/class'A" looks more correct.

[DanielRosenwasser]

Doesn't this basically mean that 'reference' tags are limited to a 'path' attribute? Kind of defeats the purpose of even having made it a tag.

[mhegazy]

@DanielRosenwasser makes sense. Then maybe we should check for valid XML attribute.

[CyrusNajmabadi]

That’s not legal XML, so we shouldn’t support it. However, it’s also a breaking change, so we must support it.

         -- Cyrus

From: Sheetal Nandi [mailto:notifications@github.com]
Sent: Friday, August 22, 2014 3:23 PM
To: Microsoft/TypeScript
Subject: Re: [TypeScript] reference path with quotes doesnot have same result as in old compiler (#474)

Old compiler could parse the below reference as li'b/class'A.d.ts

/// <reference path='li'b/class'A.d.ts' />

declare class ClassC extends test.ClassA {

}

New one parses this as li

@mhegazyhttps://github.com/mhegazy we want to behave like old compiler here right? Or should user be writing the reference as "li'b/class'A.d.ts" instead?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/474#issuecomment-53128355.

[DanielRosenwasser]

Then let's "deprecate" that style by parsing it the right way, and falling back to the old behavior if that fails. When we have to default to the old behavior, issue a warning.

The biggest problem is that we don't have a good dichotomy for warnings and errors - so really we'd like to warn in the parser, but instead we fail hard as soon as we issue any sort of diagnostic in the parser.

[DanielRosenwasser]

Because it seems like a bug in the old compiler, and even if it was intentional, I don't believe it was right. If we're entirely certain that no attributes will be added, then by all means, it doesn't matter, but it just gives more weight to suggestions like #488.