Quoted reflection missing features list

[nicolasstucki]

• Flags (PR Rework reflect Flags #10622)
  • Add Deferred, Infix, JavaStatic, Method, NoInit and Transparent
  • Remove ModuleClass
  • Rename Object to Module
• SymbolMethods
  • Add enclosingClass and enclosingMethod? (look in SourceCode)
  • Change signature to def pos: Option[Position] (PR Update reflect.Symbol position API #10656)
  • Add def hasAnnotation(sym: Symbol): Boolean and def getAnnotation(sym: Symbol): Option[Term] (PR Rework reflect annotations API #10643)
  • Rename classMethod to declaredMethod (PR Update reflect Symbol declarations API #10645)
  • Rename typeMembers to memberTypes (PR Update reflect Symbol declarations API #10645)
  • Rename members to declarations (PR Update reflect Symbol declarations API #10645)
  • Rename method to memberMethod (PR Update reflect Symbol declarations API #10645)
  • Add declaredType and declaredTypes (PR Update reflect Symbol declarations API #10645)
• Add NameTyped as super type of TermRef and TypeRef (PR Add NameTyped, AndOrType, LambdaType and MethodOrPoly #10630)
• Add AndOrType as super type of AndType and OrType (PR Add NameTyped, AndOrType, LambdaType and MethodOrPoly #10630)
• Add MethodOrPoly as super type of MethodType and PolyType (PR Add NameTyped, AndOrType, LambdaType and MethodOrPoly #10630)
• Add SourceFile to docs of Reflection (PR Add NameTyped, AndOrType, LambdaType and MethodOrPoly #10630)
• Add IfMethods.isInline and MatchMethods.isInline (PR Add isInline to IfMethods and MatchMethods #10625)
• Add Position.apply(source, start, end) and remove equivalent reporting API (PR Add constructor for reflect Position #10629)
• Change signature to def sourceCode: Option[String] in PositionMethods (PR Rework reflect SourceFile abstraction #10626)
• Change signature to def content: Option[String] in SourceFileMethods (PR Rework reflect SourceFile abstraction #10626)
• Replace Source.path with SourceFile.current: SourceFile and remove Source (PR Rework reflect SourceFile abstraction #10626)
• Try to represent SummonFrom in the compiler as as {x => x match { case ... }} and remove SummonFrom (see issue Represent summonFrom using a partial function #10624)
• Define Printer type class for show: tree.show(using Printer.Tree) (Extractors), tree.show(using Printer.Short), tree.show(using Printer.Ansi) (PR Rework reflect show API #10661)

[abgruszecki]

I still think we should do something about SourceFile#jpath. In particular, I think that in Tasty Inspector, this method should return precisely the path contained in Tasty files. Which brings the question, what format should the paths in those files have. There's a platform-indepedent format here: Windows paths can be normalised to use / as the separator. Since we can normalise paths, I think we should do that - otherwise, to understand the Tasty files, the user will need to normalise the paths themselves, because they won't know whether they came from Windows or a normal another OS.

This, in turn, means that from the perspective of Tasty Inspector, there's no reason to make SourceFile#jpath return a Java Path. Question is, what does staging see there? An absolute path, or a relative one?

/cc @nicolasstucki @smarter

[nicolasstucki]

It should be a relative path. The documentation still needs to be updated. It is the path that is kept in the TASTy. More details can be found on #10430.

[abgruszecki]

So is it always a relative path?

[abgruszecki]

Also asking, since I found out that after all associatedFile is set when loading symbols from Tasty. I think it makes sense to make jpath always be the relative path, and also to expose associatedFile, which is an absolute path to the file from which a symbol was loaded.