summaryrefslogtreecommitdiff
path: root/src/scaladoc/scala/tools/nsc/doc/ScaladocGlobal.scala
Commit message (Collapse)AuthorAgeFilesLines
* Javadoc: make parsing of java comments optionalJakob Odersky2016-08-131-2/+6
|
* Retain javadoc comments in scaladocJakob Odersky2016-07-151-0/+3
| | | | | * Hook into java parser to generate doc comments * Generate empty trees for java implementation bodies
* Remove unused imports and other minor cleanupsSimon Ochsenreither2015-12-181-4/+0
| | | | | | | | | | - Language imports are preceding other imports - Deleted empty file: InlineErasure - Removed some unused private[parallel] methods in scala/collection/parallel/package.scala This removes hundreds of warnings when compiling with "-Xlint -Ywarn-dead-code -Ywarn-unused -Ywarn-unused-import".
* Update javadoc tag to new scaladoc tags.Masato Sogame2014-07-151-0/+1
|
* Removing unused code.Paul Phillips2013-10-021-1/+0
| | | | | | | Most of this was revealed via -Xlint with a flag which assumes closed world. I can't see how to check the assumes-closed-world code in without it being an ordeal. I'll leave it in a branch in case anyone wants to finish the long slog to the merge.
* SI-7624 Fix a few remaining -Xlint warnings ...Simon Ochsenreither2013-08-151-1/+0
| | | | | in various places. This includes actors, compiler (mostly some new macro parts) continuations, partest, scaladoc, scalap.
* Address TODOs around SymbolLoaders and SymbolTable.Grzegorz Kossakowski2013-07-301-20/+2
| | | | | | | | | | | | | | | | | | | | | | SymbolTable refactoring introduced some TODOs that were supposed to be addressed after M5 release. The reason I couldn't address those problems right away was a conflict with our plans to modularize Scaladoc and interactive. However, we decided to delay that work until after M5 is released so addressing TODOs is not blocked anymore. This commit introduces the following changes: * Eclipse project definitions for interactive and scaladoc depend on scala-compiler project so they are builded against latest version of the compiler (quick) instead of STARR. This aligns our Eclipse project definitions with build.xml structure. * Introduce GlobalSymbolLoaders class which wires dependencies of SymbolLoaders with assumption of dependency on Global. * Switch to GlobalSymbolLoaders in BrowsingLoaders, interactive Global and ScaladocGlobal; this eliminates all TODO comments introduced before
* Refactor the cake so SymbolTable does not depend on GlobalGrzegorz Kossakowski2013-07-271-3/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is rather large commit so I'll first explain the motivation behind it and then go through all changes in detail explaining the choices I made. The motivation behind this refactoring was to make SymbolTable unit testable. I wanted a lightweight way of initializing SymbolTable and then writing unit tests for subtyping algorithm, various functionality related to Symbols, etc. All of that should be possible by precisely controlling what we test, e.g., create types and symbols by hand and not have them defined in source code as we normally do in partest (functional) tests. The other motivation was to reduce and clarify dependencies we have in the compiler. Explicit dependencies lead to cleaner design. Also, explicit and reduces dependencies help incremental compilation which is a big problem for us in compiler's code base at the moment. One of the challenges I faced during that refactoring was cyclic dependency between Platform and SymbolLoaders. Platform depended on `SymbolLoaders.SymbolLoader` because it would define a root loader. SymbolLoaders depended on Platform for numerous reasons like deferring decision how to load a given symbol based on some Platform-specific hooks. I decided to break that cycle by removing methods related to symbol loading from Platform interface. One could argue, that better fix would be to make SymbolLoaders to not depend on Platform (backend) concept but that would be much bigger refactoring. Also, we have a new concept for dealing with symbol loading: Mirrors. For those reasons both `newClassLoader` and `rootLoader` were dropped from Platform interface. Note that JavaPlatform still depends on Global so it can access phases defined in Global to implement `platformPhases` method. Both GenICode and BCodeBodyBuilder have some Platform specific logic that requires casting because pattern matcher doesn't narrow types to give them a proper refinement. Check the changes for details. Some logging utilities has been moved from Global to SymbolTable because they are accessed by SymbolTable. Since Global inherits from SymbolTable this should be a source compatible change. The SymbolLoaders has dependency on `compileLate` method defined in Global. The purpose behind `compileLate` is not clear to me but the dependency looks a little bit dubious. At least we made that dependency explicit. ScaladocGlobal and Global defined in interactive has been adapted in a way that makes them compile both with quick.comp and 2.11.0-M4 so my refactorings are not blocking the modularization effort.
* Remove dependency on typer phase in ClassfileParser.Grzegorz Kossakowski2013-07-271-0/+10
| | | | | | | | | | | | | | | | | ClassfileParser depends on forcing infos during typer phase. It's not entirely clear why this is needed (git blame doesn't help much) but I decided to preserve the logic. Therefore, I introduced an abstract method called `lookupMemberAtTyperPhaseIfPossible` which preserves the original semantics but is implemented outside of ClassfileParser so the ClassfileParser itself doesn't need to depend on typer phase and phase mutation utilities. I removed `loaders` override in `test/files/presentation/doc`. I would have to update it to implement the `lookupMemberAtTyperPhaseIfPossible` method. However, the override doesn't seem to be doing anything useful so I just removed it.
* Moved scaladoc code into src/scaladoc.Paul Phillips2013-03-091-78/+21
| | | | | | This leverages the preceding several commits to push scaladoc specific code into src/scaladoc. It also renders some scanner code more comprehensible.
* Moved scaladoc sources into separate directory.Paul Phillips2013-03-091-0/+106
This change is not externally visible. It moves the scaladoc sources into src/scaladoc and adds an ant target for building them. The compilation products are still packaged into scala-compiler.jar as before, but with a small change to build.xml a separate jar can be created instead.