-
Notifications
You must be signed in to change notification settings - Fork 789
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
Quickfix for #9 and #10 #87
Conversation
Let's get to the bottom of the root causes for the problem. To start with, what happens when "," occurs in a type name? For example, as I understand it the names in an fsc.exe generated on-disk .DLL do not get escaped. However it seems from the above that "," gets escaped in System.Reflection.* qualified names.. However, the code for ILTypeRef.QualifiedName isn't escaping "," at all. Perhaps it should be. But ILTypeRef.QualfiiedName and friends are used qiute a bit in the codebase, so we have to be careful here. I'm also aware that "," in type names is used in F# as a special indicator in mangled names for statically parameterized types, see PrettyNaming.demangleProvidedTypeName/mangleProvidedTypeName. These encodings/decodings are set in stone now since they are part of binary compatibility for F#. Given this, it could be that the use of "," in type names should just be disallowed, and that the best fix is just to add "," to IllegalCharactersInTypeAndNamespaceNames. This would be a breaking change, though given that there are bugs in this area already I'd be OK with that. (BTW one consistent problem in the F# compiler codebase is that we didn't use the F# type system enough to track invariants of strings. For exampe, there's no real reason that QualifiedName and BasicQualfiedName couldn't return a type "QualifiedName" that tracks that the string has been normalized/escaped according to particular rules. We could have avoided bugs if we'd used the F# type system a bit more.) |
mhm, I'm not a big fan of making the /cc @haf |
BTW: Adding |
@dsyme does this look like an appropriately general fix at this point? |
Perhaps - I need to look at it more though - am planning to do so. Leave it open for now. |
#250 looks like a much better fix. |
The FSI has an issue with
,
in identifiers.reported in #9:
reported in #10:
Both issue are caused by an encapsulated identifier in modB (see https://github.com/forki/visualfsharp/compare/Microsoft:fsharp4...forki:fsicomma?expand=1#diff-ee96c09c03afcf797a979eb48d7f7f09L1725).
We ask for
***.1,@***
but the dictionary inmodB
has only a value for***.1\,@***
.My fix encapsulates the
,
and this fixes both issues.I know this is not the correct fix, but it's a start and I'd like to get this in.
GetTypeAndLog
? Are there other chars that need to be encapsulated?