Currently ReadComments context mode is required to load & store comments when reading TASTY files. Now that we have an API for accessing the comments ( https://github.com/lampepfl/dotty/pull/6028 ), the users can observe inconsistent behaviour. We should try to make it consistent instead.
When accessing comments for code symbols in inline method bodies, whether the comment is accessible or not depends on where it's defined and current mood of incremental compilation. If the symbol is compiled in the current run, its documentation will be accessible irrelevant of the ReadComments mode. If the symbol is defined in a library (and therefore loaded from a TASTY file), the documentation will be only accessible if ReadComments mode was on when the symbol was being read. Same goes for the situation in which the symbol was compiled in a previous run, and incremental compilation decided to not touch it during current run.
Currently when accessing the symbols through ConsumeTasty API, ReadComments mode is always set, so the comments are always available. However, the mode is not set for TastyDecompiler. The latter may or may not be a problem.
The final problem is what accessing the comments should return. Right now it returns Option[Comment], attempting to throw sometimes if ReadComments was not on when reading TASTY files. It likely should either never throw, or always throw if the comments were not read due to the mode being off. The problem is that right now, as outlined above, there's no reliable way to detect that.
abgruszecki
commented
5 years ago
Currently
ReadCommentscontext mode is required to load & store comments when reading TASTY files. Now that we have an API for accessing the comments ( https://github.com/lampepfl/dotty/pull/6028 ), the users can observe inconsistent behaviour. We should try to make it consistent instead.When accessing comments for code symbols in inline method bodies, whether the comment is accessible or not depends on where it's defined and current mood of incremental compilation. If the symbol is compiled in the current run, its documentation will be accessible irrelevant of the
ReadCommentsmode. If the symbol is defined in a library (and therefore loaded from a TASTY file), the documentation will be only accessible ifReadCommentsmode was on when the symbol was being read. Same goes for the situation in which the symbol was compiled in a previous run, and incremental compilation decided to not touch it during current run.Currently when accessing the symbols through
ConsumeTastyAPI,ReadCommentsmode is always set, so the comments are always available. However, the mode is not set forTastyDecompiler. The latter may or may not be a problem.The final problem is what accessing the comments should return. Right now it returns
Option[Comment], attempting to throw sometimes ifReadCommentswas not on when reading TASTY files. It likely should either never throw, or always throw if the comments were not read due to the mode being off. The problem is that right now, as outlined above, there's no reliable way to detect that.