Skip to content

[doc] Add support for usecases #1472

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

Closed
wants to merge 11 commits into from

Conversation

felixmulder
Copy link
Contributor

@felixmulder felixmulder commented Aug 24, 2016

This PR solves the @usecase annotation, todo:

  • Symbols for @usecase code
  • Typecheck @usecase code
  • Make result available in ctx.docbase
  • Fix test failure when documenting Iterator(c8b3504)
  • Fix test failure when documenting IterableLike (7d5bd7c)
  • Move cooking of doc strings into dotty (currently in dottydoc)
  • Make sure that strings are properly cooked - i.e. no missing $Coll expansions (d561cb9)
  • Strip @usecase after typing
  • Stop double expansion - isExpanded: Boolean
  • Stop expanding in dottydoc
  • Clean up

@felixmulder felixmulder force-pushed the topic/dottydoc-usecases branch from 19cdee3 to 4970192 Compare August 27, 2016 13:49
@felixmulder felixmulder changed the title [WIP, dottydoc] Add support for usecases [dottydoc] Add support for usecases Aug 27, 2016
@felixmulder felixmulder changed the title [dottydoc] Add support for usecases [doc] Add support for usecases Aug 27, 2016
@felixmulder felixmulder force-pushed the topic/dottydoc-usecases branch from 4970192 to e1745ec Compare August 27, 2016 14:48
@felixmulder
Copy link
Contributor Author

This is ready for review - @odersky perhaps?

@@ -171,6 +171,7 @@ class ScalaSettings extends Settings.SettingGroup {
val Ybuildmanagerdebug = BooleanSetting("-Ybuild-manager-debug", "Generate debug information for the Refined Build Manager compiler.")
val Ycompletion = BooleanSetting("-Ycompletion-debug", "Trace all tab completion activity.")
val Ydocdebug = BooleanSetting("-Ydoc-debug", "Trace all scaladoc activity.")
val Ydocrun = BooleanSetting("-Ydoc-run", "Current run should be treated as a docrun, enables `@usecase` annotations in comments")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is that option needed anytime one wants to do docs with @usecase? In that case it should not be a -Y option, we need something less obscure then? I am not sure why we need the option at all.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wanted a uniform way of discerning if we're doing a documentation run - ergo the flag. But perhaps it should just be -docrun.

The reason we "need" it is because when I'm typing the usecases in typedClassDef I do:

if (ctx.settings.Ydocrun.value)
  typedUsecases(body1.map(_.symbol), self1.symbol)

My fear was that without this check, the class would get additional members on a normal run. But if that's not the case, the check can be removed - the flag too and the lazy val isUsecase can be changed to just check if the symbol's name ends in $doc.

WDYT @odersky ?

@@ -1190,6 +1192,9 @@ class Typer extends Namer with TypeAssigner with Applications with Implicits wit
val self1 = typed(self)(ctx.outer).asInstanceOf[ValDef] // outer context where class members are not visible
val dummy = localDummy(cls, impl)
val body1 = typedStats(impl.body, dummy)(inClassContext(self1.symbol))

typedUsecases(body1.map(_.symbol), self1.symbol)(localContext(cdef, cls).setNewScope)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@odersky: using a fresh scope here, also got rid of the flags and changed the lazy val to a def. So if this is correct - then this PR should be good to go :)

@odersky
Copy link
Contributor

odersky commented Sep 5, 2016

@felixmulder I agree with your changes, but think nevertheless usecases should only be typechecked in a docrun. A usecase might be ill-typed, but a normal compiler run should treat this as just a comment. Let's discuss how to best achieve this.

@felixmulder
Copy link
Contributor Author

Superseded by #1502

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

Successfully merging this pull request may close these issues.

2 participants