14

所以我用谷歌搜索了一下，但除了稀疏之外没有其他信息：

-Yrangepos                     Use range positions for syntax trees.

行。而且我知道如果我想在宏中捕获源片段，我需要使用它。

现在我的两个问题是：

  • 为什么默认情况下不启用？
  • 使用它是否有任何副作用（例如增加类文件大小）？
4

2 回答 2

5

当 makro 拼写为 Burmak(r)o 时引入-Yrangepos的问题是由您的用例引起的。

A-X选项表示永久性，而 a-Y可能随时消失，这意味着它可能成为默认行为。

也许它没有因为错误和崩溃。

在Moors 撰写的团队会议上：

范围位置 [马丁]

尊重范围位置 - ide 中的衰减与类型器或解析器中的转换不尊重范围位置有关

  • 每次签入更改 - 自动检查范围位置
  • range position = 不仅仅是一个位置点，而是开始和结束，包含在树节点中（RangePosition 是 Position 的子类）
  • CompilationUnit 中有 RangePositions 的地图

不变量：

  • 子节点的范围位置包含在父节点的范围pos中
  • 无重叠（透明范围位置除外）
  • rangepos 覆盖整个程序

问题：

  • 模板
  • 为了

检查文件包含职位

rangeposition(start,point,end).focus == offsetposition(point) // 脱离非重叠不变式

2012年，PR验证-Yrangepos频繁失败；它已修复，但变成了夜间验证以减少资源。

休伯特提供了这些笔记：

关于rangepos的一些事情：

  • 如果您尝试使用 'scalac -Ybrowse:typer -Yrangepos FILE.scala' 运行任何代码，您会看到大多数树都有范围位置。
  • 有些人没有，是的，这有点不幸，但我们正在努力改进这一点 - 实际上，每当你在 Yrangepos 模式下发现这样的情况时，它可能是一个错误。从 2.9 到 2.10.0-snapshots，情况有了显着改善。
  • 句法树通常被分配偏移位置（这是你可能遇到的，但我必须看一个例子）
  • 对于编译器，我们只关心范围位置是否对（包括）typer 有效。在那之后，我们不在乎。根据我所见，您在 refcheck 之后运行您的工具，这可能会干扰 refcheck 中发生的一些转换，这些转换可以操纵/分配范围或偏移位置。

切换到范围位置似乎很容易，因为基本数学，但仍然存在像这样的错误，表明在合成或重组树时分配位置涉及额外的劳动。

尽管表示编译器需要范围位置，但它们并不是批处理编译的关键路径。有了更多资源来提高稳健性，也许他们可以翻转开关。

于 2017-09-07T08:35:00.147 回答
1

我只能猜测scalac默认情况下出于性能原因不使用范围位置。

在常规编译中，位置仅用于错误报告和将行号信息保存到类文件中。偏移位置足以做到这一点，所以没有必要做所有操作范围位置所需的工作。

我认为范围位置除了简单的编译速度之外不会产生任何其他成本。

于 2017-09-03T15:46:16.857 回答