Обнаружил, что компилятор некорректно обрабатывает директиву line. Сразу небольшой пример:

class Class
{
  Foo() : void
  {
    def a = 1;
    
#line 100 "C:\\Temp\\foo.txt"
    def b = 1;
#line default
  }
}

внутри блока line не работают хинты и автокомплит.

Компилятор присваивает всем элементам внутри директивы line значение location, указывающее на внешний файл. Интеграция использует локальные координаты каретки (line/column) для поиска выражения для автокомплита. Для этого интеграция перебирает выражения внутри метода, сопоставляя кординаты каретки и координаты из location выражений. Поскольку выражения внутри блока line имеют позиции, указывающие на внешний файл, поиск выражений внутри блока закачивается неудачей.

Из за некорректной обработки директивы также не работает автодополнение и хинты для серверных блоков внутри aspx страниц <% %>. ASP.NET парсит aspx страницу, выделяя серверные блоки, формирует из них виртуальный исходник и скармливает компилятору уже его, а не сырой aspx файл. Фактически компилятор и интеграция работают с виртуальным исходником, а студия на лету маппирует координаты между ним и aspx файлом. Для маппинга координат используются директивы line.

Поэтому некорректная обработка директив line не дает реализовать автокомплит и хинты для выражений, содержащихся <% %> блоков aspx файлов. Черт с ними с хинтами, но автокомплит думаю очень нужен, особено при использовании статически типизованных mvc представлений .

Для исправления нужно хранить позицию, задаваемую директивой line в отдельном свойстве класса Located. Это свойство (ExternalLocation) следует использовать только при генерации меток для pdb файла и при формировании текста сообщений об ошибках. Во всех остальных случаях следует использовать Location, указывающий на позиции в исходном файле. Кстати, метки для pdb файла формировались некорректно, из за этого не работали брекпоинты внутри блоков <% %> — это я уже исправил.

И самый главный вопрос — как думаете, стоит этим сейчас заняться, или фича никому не интересна?

p.s. Нужно еще продумать, что делать со свойством ExternalLocation при модификации кода макросами. Сейчас макросы могут подкручивать локации выражений, нужно ли это делать и для ExternalLocation? — пока я думаю, что этого делать не нужно.