forked from usethesource/rascal
-
Notifications
You must be signed in to change notification settings - Fork 0
Fixing the loc issues proposal
DavyLandman edited this page Sep 20, 2012
·
1 revision
This proposal tries to resolve all of our issues caused by the way we use loc
s (locations).
loc
s are always encoded. When they are created, used, and printed. This actually makes it more URI compliant. We want PDB to give an error if you create a loc
with unencoded values.
Access to parts of the loc
are always decoded, this assures most users do not need to think about encoding. The same holds for interpolation.
rascal> |file:///test%20space.txt|
loc: |file:///test%20space.txt|
this already works.
rascal> |file:///test space.txt|
error: MalFormedURI(..full locations should always be encoded...)
this is now a parse error at the space.
rascal> |file:///<"test space.txt">|
loc: |file:///test%20space.txt|
at the moment this throws: MalFormedURI("file:///test space.txt")
rascal> l = |file:///test%20space.txt|;
loc: |file:///test%20space.txt|
rascal> l.path
str: "/test space.txt"
this already works.
l.path = "/test t.txt";
loc: |file:///test%20%20t.txt|
this already works.
- We need all code working with
ISourceLocation
to either use thegetInput/OutputStream
or make sure they never decode. - Perhaps we also need to loosen the definition of Locations in the rascal grammar?
- We need to add encoding the all the paths of ISourceLocation creation.
- Looks like PDB already checks for encoding?