Skip to content
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

Support DocDef in reflection trees #7993

Open
scabug opened this issue Nov 22, 2013 · 8 comments
Open

Support DocDef in reflection trees #7993

scabug opened this issue Nov 22, 2013 · 8 comments

Comments

@scabug
Copy link

scabug commented Nov 22, 2013

It would be great if reflection could add support for DocDef Nodes (scala.tools.nsc.ast.Trees#DocDef). The use case is source code generation. Being able to add doc comments would make tree based (e.g. quasi quote based) source code generation more feasible. We could use this in Slick, but it should be useful in other cases as well, like adding assisting comments when printing out trees generated by macros for visualization or debugging in the IDE.

@scabug
Copy link
Author

scabug commented Nov 22, 2013

Imported From: https://issues.scala-lang.org/browse/SI-7993?orig=1
Reporter: @cvogt
Affected Versions: 2.11.0-M7
Blocks #6267, #8904

@scabug
Copy link
Author

scabug commented Nov 28, 2013

@cvogt said:
We decided on using an annotation instead and letting the pretty printer use that to generate comments. Adding DocDef nodes would easily get in the way of existing tree processors.

@scabug
Copy link
Author

scabug commented Jan 14, 2016

@szeiger said:
@xeno-by, can this issue be closed or is the original request still on the table?

@SethTisue
Copy link
Member

anyone know the status on this? I feel like this came up recently, but can't remember where/why.

@harpocrates
Copy link

The situation is actually a little more dire than just not being able to create methods with docstrings: it is impossible to match on a DocDef too. Consider the simple macro in this StackOverflow question. The quasiquote pattern matching is idiomatic yet it will fail with sbt doc (but not sbt compile).

My particular use case is fixing shadaj/slinky#380 (which I'm fairly certain is the same issue).

Even if the full power of DocDef stays hidden, it seems pretty important to be able to unwrap doc'ed trees to get their undoc'ed variants (which can be pattern matched with quasiquotes).

@lauraaraviciute
Copy link

Hi guys, is there any update on this?
I think on a project I have come up with the same problem. We are working with scalaz and are using the following conventions:

  type OurState[T] = State[X, T]

  def doSomething(...): OurState[Unit] = {
    (for {
      x <- get[X].liftM[OptionT]

And are getting errors when generating scaladoc:

* What went wrong:
Execution failed for task ':paygrid-core:scaladoc'.
> Document failed because of an internal documenter error (Document failed with 3 errors; see the documenter error output for details.); see the error output for details.
[ant:scaladoc]..: error: value liftM is not a member of scalaz.State[com..state.X,...com..state.X]
[ant:scaladoc]         x <- get[X].liftM[OptionT]

@SethTisue
Copy link
Member

@lauraaraviciute Nobody is working on this, to my knowledge.

But it isn't obvious to me from the error message you've included whether it's actually the same problem.

@lauraaraviciute
Copy link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants