Skip to content

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 locs (locations).

Proposal

locs 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.

Examples

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.

Foreseeable impact

  • We need all code working with ISourceLocation to either use the getInput/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?
Clone this wiki locally