-
Notifications
You must be signed in to change notification settings - Fork 1.1k
[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
Conversation
Also eliminates the need for comment processing to be part of the `DocASTPhase`, so this should be put into a DocMiniPhase
19cdee3
to
4970192
Compare
4970192
to
e1745ec
Compare
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") |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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 :)
@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. |
Superseded by #1502 |
This PR solves the
@usecase
annotation, todo:@usecase
code@usecase
codectx.docbase
Iterator
(c8b3504)IterableLike
(7d5bd7c)$Coll
expansions (d561cb9)@usecase
after typingisExpanded: Boolean