Идентификатор Visual Studio не определен

Обновлено: 21.11.2024

Я собрал и скомпилировал lua5.3 из исходников, он находится в /usr/local/include, на диске он находится в:

Текст был успешно обновлен, но возникли следующие ошибки:

прокомментировал sean-mcmanus 23 января 2018 г. •

iongion прокомментировал 23 января 2018 г.

Есть только typedef, без тела структуры, он присутствует в W:\SDKs\msys2\usr\local\include\lua.h

Когда я компилирую и устанавливаю lua 5.3:

iongion прокомментировал 23 января 2018 г.

Из этого довольно очевидно, что VSCode не может его найти, но что мне делать?
Сохранить исходники lua-5.3.4 и добавить все файлы *.h в путь поиска?
Я полагаю, что структура, определенная в закрытом API, является распространенным явлением

прокомментировал sean-mcmanus 23 января 2018 г.

Определения типа должно быть достаточно, чтобы избавиться от сообщения об ошибке — похоже, что определение типа не найдено.

iongion прокомментировал 23 января 2018 г.

Странно, так как всплывающая подсказка на первом снимке экрана сообщает, что он нашел его. Если я нажму Ctrl+Hover, я получу следующее:

прокомментировал sean-mcmanus 23 января 2018 г.

Ошибка обнаруживается с помощью нашего механизма символов, а не IntelliSense. Похоже, это ошибка режима clang-x64, который не воспроизводится с помощью msvc-x64.

iongion прокомментировал 23 января 2018 г.

прокомментировал sean-mcmanus 23 января 2018 г. •

Теперь проблема исчезла? Ошибка, которую я видел в режиме clang-x64, была вызвана другой проблемой (size_t не найден), но она работала после того, как я ее исправил.

iongion прокомментировал 24 января 2018 г. •

Извините, @sean-mcmanus, я не совсем понял и поторопился, если я использую $, то он не сможет найти включения для этих проектов подмодулей (lautoc.h и других). Я создал проект https://github.com/iongion/xmoonvg, в котором я также зафиксировал файлы vscode. Когда я кодирую в Windows, я решил эту проблему с помощью «intelliSenseMode»: «msvc-x64» , когда я разрабатываю на Mac или Linux, если я переключаюсь на clang-x64, я все равно получаю проблему.

Ошибка, которую я наблюдал в режиме clang-x64, была вызвана другой проблемой (размер size_t не найден), но она работала после того, как я ее исправил.

Так что, если исправят, можете закрывать тему, а я буду ждать новый релиз 👍

комментарий sean-mcmanus прокомментировал 24 января 2018 г.

Нет, я исправил это, заменив size_t на int в заголовке. Как правило, вы должны использовать msvc-64 только в том случае, если ваш компилятор cl.exe, а не gcc/clang, в любой ОС. Получаете ли вы какие-либо волнистые линии ошибок в заголовке, содержащем typedef? Я посмотрю на ваш репродукционный проект позже.

комментарий sean-mcmanus прокомментировал 24 января 2018 г.

Да, я до сих пор не могу воспроизвести эту ошибку. Я использовал проект xmoonvg, а затем добавил 4 файла заголовков lua и закомментировал 4 файла заголовков, которых у меня не было (lautoc.h/nano*.h"), и IntelliSense находит lua_State. Мне пришлось добавить "$/src" в includePath.

torokati44 прокомментировал 8 февраля 2018 г.

У меня такая же проблема. Многие макросы из заголовка CL/cl.h подчеркнуты и создают запись о проблеме, но я могу просмотреть и перейти к их определениям.

На самом деле я получаю два определения: одно из /usr/include/CL/cl.h и одно из /usr/local/include/CL/cl.h .
Удаление "/usr/local/include" и "$/" из c_cpp_properties.json ничего не меняет (они оба присутствуют в двух местах: в includePath и вbrowse.path).

Fedora 27, VS Code 1.19.3, cpptools 0.14.6.

комментарий sean-mcmanus прокомментировал 8 февраля 2018 г.

torokati44 прокомментировал 8 февраля 2018 г.

Например, если мой код очень простой

Тогда нет проблем. Независимо от того, включаю ли я cl.h или cl.hpp . Я попытаюсь свести более сложный источник к более простой форме, где проблема все еще возникает.

sean-mcmanus прокомментировал 8 февраля 2018 г. •

torokati44 прокомментировал 8 февраля 2018 г. •

О, кажется, я понял!

Это вызывает ошибку для меня:

Если foo.h (или iostream ) включается только после или только перед CL/cl.h (даже несколько раз), маркер проблемы исчезает. Это происходит только в том случае, если один и тот же заголовок включен до и после CL/cl.h .

ОБНОВЛЕНИЕ 1:

ОБНОВЛЕНИЕ 2:

И в последнем случае проблема возникает, только если ОДИН является макросом. Если я заменю его, скажем, const int ONE = 1; , то независимо от того, сколько раз и в какой комбинации я включу foo.h и bar.h , ONE никогда не будет указан как неопределенный.

torokati44 прокомментировал 8 февраля 2018 г. •

То же самое происходит с VS Code 1.18.0-insider и cpptools 0.15.0-insiders.

комментарий sean-mcmanus прокомментировал 8 февраля 2018 г.

torokati44 прокомментировал 8 февраля 2018 г. •

Ну, я не думаю, что это так просто, как "дублировать включение", так как, например, это:

И, наконец, да, я беспокоился о том же.Поскольку исходная проблема описывалась с помощью typedef , а я столкнулся с ней только с макросом, это могут быть две разные проблемы с одинаковыми симптомами.

прокомментировал adarshmk 22 июня 2018 г.

aleeraser прокомментировал 2 августа 2019 г.

Есть новости по этому поводу? Я все еще сталкиваюсь с проблемой.

прокомментировал sean-mcmanus 2 августа 2019 г.

@aleeraser Перейти к определению — это общий симптом, и разные сценарии, вероятно, являются разными основными причинами ошибок. Можете ли вы зарегистрировать новую ошибку с более подробной информацией о воспроизведении? Мы обнаружили/исправили некоторые серьезные ошибки, связанные со сбоем Go to Def в нашем ожидающем выпуске Insider, например. когда используется "использование пространства имен".

прокомментировал aleeraser 5 августа 2019 г. •

@sean-mcmanus спасибо за ответ. Я зарегистрирую новую ошибку как можно скорее. В качестве краткой справки: я работаю над ядром Linux с последними стабильными выпусками, и у меня такое ощущение, что смесь макросов, констант, определений типов и т. д. заставляет vscode как-то сходить с ума (и я не могу винить это).

rhymu8354 прокомментировал 8 ноября 2019 г. •

Я также вижу проблему, о которой сообщалось изначально, встраивание Lua 5.3 в мои программы, написанные на C++. Все макросы, определенные в заголовках Lua, отмечены красными волнистыми линиями, а во всплывающих подсказках указано, что они определены и не определены:

Проблема возникает не в Visual Studio, а только в VSCode, несмотря на то, что структура проекта одинакова, включая пути, и оба они созданы из одних и тех же файлов CMake.

Если потребуется дополнительная информация, я с удовольствием создам MCVE или отвечу на любые вопросы разработчиков. Эта проблема является одной из немногих вещей, которые я видел неправильно с vscode-cpptools в течение длительного времени, поэтому было бы здорово, если бы это можно было исправить.

bcaddy прокомментировал 18 апреля 2020 г.

Кажется, у меня похожая проблема, но я не знаю, как ее решить.

У меня есть этот блок кода в глобальном заголовочном файле

Но везде, где я использую Real, выдается ошибка "Идентификатор Real is undefined"

прокомментировал sean-mcmanus 20 апреля 2020 г.

@bcaddy Что отображается при наведении курсора на ТОЧНОСТЬ? Похоже, что он может быть неопределенным.

bcaddy прокомментировал 21 апреля 2020 г.

Так оно и было. Я неправильно использовал раздел Defines линтера. PRECISION определяется в Makefile, и я предполагал, что линтер будет искать его там

susundberg прокомментировал 21 мая 2020 г.

Похоже, проблема не связана с

Но это нехорошо, так как я бы предпочел иметь «системные включения» перед моими собственными включениями. Для записи проблемный файл - log.h

TLDR; Исправлено путем обращения к вызову макроса include/move после включения файла, содержащего определения.

RedZone908 прокомментировал 16 июля 2020 г.

Было бы неплохо, если бы мы могли решить эту проблему в какой-то момент, чтобы мне не приходилось менять порядок включения.

Прокомментировал Evano 4 ноября 2020 г. •

У меня была такая же проблема в Linux с GCC. Для меня проблема заключалась в том, что код vs был указан на неправильное включение по умолчанию для компилятора. Я думаю, это произошло из-за того, что у меня установлены и GCC 9, и 10, причем 9 используется по умолчанию (тот, на который указывает символическая ссылка gcc).

Я уже знал об этом, но никогда не думал, что это потенциально может быть проблемой для vscode, тем более, что я установил для параметраcompilePath значение /usr/bin/g++-10 . Следующим, что нужно было сделать, чтобы проверить мою теорию, было посмотреть на вставки GCC 10.

GCC 10 указывает на включаемый каталог, специфичный для него самого, а не для какой-либо другой версии. После того, как я добавил /usr/lib/gcc/x86_64-linux-gnu/10/include в мой includePath, проблемы с включением были решены.

По моему мнению,compilePath должен автоматически информировать расширение о включаемых каталогах версии/конфигурации компилятора.

При установке или создании пакета может возникнуть ошибка, подобная следующей:

Это означает, что рецепт не поддерживает вашу целевую операционную систему.

ОШИБКА: Отсутствует готовый пакет¶

При установке пакетов (с помощью conan install или conan create) вы можете получить сообщение об ошибке, подобное следующему:

Это означает, что рецепт пакета czmq/4.2.0@ существует, но по какой-то причине нет предварительно скомпилированного пакета для ваших текущих настроек. Возможно, создатель пакета вообще не собирал и не делился готовыми пакетами, а только загрузил рецепт пакета, или он предоставляет пакеты только для некоторых платформ или компиляторов. Например. создатель пакета создал пакеты по рецепту для Visual Studio 14 и 15, но вы используете Visual Studio 16. Также вы можете проверить свой режим идентификатора пакета, так как он может повлиять на доступные для него пакеты.

По умолчанию Conan не собирает пакеты из исходников. Есть несколько способов обойти эту ошибку:

Вы можете попытаться собрать пакет для своих настроек из исходников, указав в качестве аргумента какую-либо политику сборки, например --build czmq или --build. Если рецепт пакета и исходный код подходят для ваших настроек, ваши двоичные файлы будут собраны локально и готовы к использованию.
Если сборка из исходных кодов не удалась, вы можете создать ответвление исходного рецепта, улучшить его, пока он не будет поддерживать вашу конфигурацию, а затем использовать его. Скорее всего, нужно внести свой вклад в создателя оригинального пакета. Но вы также можете загрузить измененный рецепт и готовые двоичные файлы под своим именем пользователя.

ОШИБКА: неверная настройка¶

Иногда может случиться так, что при указании параметра, отсутствующего по умолчанию, вы получите следующее сообщение:

Это не означает, что такая архитектура не поддерживается conan, просто ее нет в фактических настройках по умолчанию. Вы можете найти в домашней папке пользователя ~/.conan/settings.yml файл настроек, который вы можете модифицировать, редактировать, добавлять любую настройку или любое значение, с любой вложенностью, если это необходимо. См. раздел Настройка параметров .

Если у вашей команды или пользователей одинаковые настройки (вы можете поделиться с ними файлом), все будет работать. Файл settings.yml — это всего лишь механизм, с помощью которого пользователи договариваются об общем написании типичных параметров. Кроме того, если вы считаете, что некоторые настройки будут полезны для многих других пользователей conan, отправьте их как проблему или запрос на внесение изменений, чтобы они были включены в будущие выпуски.

Возможно, что какой-то помощник сборки, например CMake, не поймет новые добавленные настройки, не использует их или даже не сработает. Такие помощники, как CMake, представляют собой простые утилиты для преобразования параметров conan в соответствующий синтаксис системы сборки и аргументы командной строки, поэтому их можно расширить или заменить собственными, которые будут обрабатывать ваши собственные личные параметры.

ОШИБКА: значение параметра не определено¶

При установке или создании пакета может появиться такая ошибка:

Это означает, что рецепт определил параметры = "os", "arch", . но значение для настройки арки не было указано ни в профиле, ни в командной строке. Обязательно укажите для него значение в своем профиле или в командной строке:

Если вы создаете чистую библиотеку C с помощью gcc/clang, вы можете столкнуться с такой ошибкой:

Действительно, для создания библиотеки C нет необходимости определять стандартную библиотеку C++. И если вы укажете значение, вы можете получить несколько пакетов для одного и того же двоичного файла. Что нужно сделать, так это удалить такое подмножество в вашем рецепте:

ОШИБКА: не удалось создать процесс¶

Когда conan устанавливается через pip/PyPI, а python устанавливается по пути с пробелами (как часто бывает в Windows «C:/Program Files…»), conan может не запуститься. Это известная проблема с Python, и ее нельзя исправить с помощью conan. Текущие обходные пути:

Установите python по пути без пробелов
Используйте виртуальные среды. Краткое руководство:

Затем, когда вы будете использовать conan, например, в новой оболочке, вам нужно будет активировать виртуальную среду:

Virtualenvs очень удобен не только для этого обходного пути, но и для поддержания чистоты вашей системы и предотвращения нежелательного взаимодействия между различными инструментами и проектами Python.

ОШИБКА: не удалось удалить папку (Windows)¶

Возможно, что при работе conan генерируются какие-то случайные исключения (некоторые с полными трассировками), связанные с невозможностью удалить одну папку. Могут произойти две вещи:

У пользователя открыт какой-то файл или папка (в файловом редакторе, в терминале), поэтому их нельзя удалить, и процесс завершается сбоем. Обязательно закрывайте файлы, особенно если вы открываете или просматриваете локальный кеш Conan.
В Windows индексатор поиска может открывать и блокировать файлы, создавая случайные, трудно воспроизводимые и раздражающие ошибки. Отключите индексатор поиска Windows для папки локального хранилища conan

ОШИБКА: ошибка при инициализации параметров¶

При установке пакета Conan возникает следующая ошибка:

Возможно, ваша версия Conan устарела. Ошибка связана с использованием default_options в качестве словаря и может быть обработана только Conan >= 1.8. Чтобы исправить эту ошибку, обновите Conan до версии 1.8 или выше.

ОШИБКА: ошибка при запуске Conan Server с несколькими рабочими процессами¶

При запуске gunicorn для запуска conan_server в пустой среде:

Conan Server сначала попытается создать ~/.conan_server/data , ~/.conan_server/server.conf и ~/.conan_server/version.txt. Однако, поскольку несколько рабочих процессов выполняются одновременно, это может привести к конфликту. Чтобы исправить эту ошибку, вы должны запустить:

Эта команда должна быть выполнена перед запуском воркеров. Он ничего не перенесет, но заполнит папку conan_server. Исходное обсуждение этой ошибки находится здесь.

ОШИБКА: Запрошен пакет, но найден несовместимый регистр¶

При установке пакета, который уже установлен, но с использованием другого регистра, произойдет следующая ошибка:

Вы можете находить и использовать рецепты с именами в верхнем и нижнем регистре (мы приветствуем варианты в нижнем регистре), но некоторые ОС, такие как Windows, по умолчанию нечувствительны к регистру, они не могут одновременно хранить оба варианта в кэше Conan. Чтобы решить эту проблему, вам необходимо удалить существующий вариант OpenSSL в верхнем регистре:

ОШИБКА: Несовместимые требования, полученные при разных оценках «требований»¶

Когда для двух разных пакетов требуется один и тот же пакет в качестве зависимости, но с разными версиями, возникает следующая ошибка:

Как видно из следующей ситуации: для conanfile.txt требуются 2 пакета ( baz/1.0.0 и foobar/1.0.0 ), для каждого из которых требуется пакет с именем foo . Однако для baz требуется foo/1.0.0 , а для foobar требуется foo/1.3.0 . Поскольку требуемые версии различаются, это считается конфликтом, и Конан не будет его решать.

Чтобы решить такую коллизию, вы должны выбрать версию для foo и добавить ее в conanfile.txt в качестве явного требования:

Здесь мы выбираем foo/1.3.0, потому что он новее. Теперь мы можем продолжить:

Конан по-прежнему предупреждает нас о конфликте, но поскольку у нас есть зависимости, переопределяющие версию foo, это больше не ошибка.

Одной из наиболее распространенных ошибок JavaScript, с которыми сталкиваются наши клиенты, является [CODE]jQuery не определен[/CODE]. Это может быть довольно серьезной проблемой, если ваше веб-приложение использует jQuery (73% всех сайтов!), поскольку, если jQuery не загружается, это может сделать ваш код JavaScript непригодным для использования.

Каковы распространенные причины того, что jQuery не определен?

Наиболее очевидная причина этой ошибки заключается в том, что вы забыли включить jQuery перед ее использованием, но есть и более тонкие причины, которые вы не заметите, пока не развернете свой сайт в рабочей среде.

1. Ваш jQuery, размещенный в CDN, может быть заблокирован

Если вы используете версию jQuery, размещенную в CDN, такую как размещенные библиотеки Google, эти CDN могут быть заблокированы фильтром или прокси-службой при подключении ваших клиентов. Обычно эта проблема возникает с запросами, исходящими с китайских или индонезийских IP-адресов.

2. Ваш jQuery, размещенный в CDN, не работает или истекло время ожидания

Другим распространенным примером этой ошибки является ненадежная или медленная загрузка CDN, на которой размещен ваш скрипт jQuery. Браузеры обычно имеют тайм-аут около 20–30 секунд для каждого тега скрипта.

Как исправить ошибку jQuery is notdefined?

К счастью, для большинства этих проблем есть простое решение. Вы можете легко предоставить локальную резервную версию jQuery следующим образом:

-- CODE language-html --
// Сначала попробуйте загрузить jQuery из CDN Google

// Возврат к локальной копии jQuery в случае сбоя CDN

Если у вас есть приложение Rails, вы также можете использовать гем jquery-rails, который автоматизирует этот резервный процесс.

Еще один вариант — установить jQuery с помощью npm или другого менеджера пакетов и связать его с остальной частью вашего JavaScript. Для этого сначала запустите [CODE]npm install jquery --save[/CODE], а затем [CODE]import $ from 'jquery'[/CODE].

Является ли jQuery проблемой на моем сайте?

Практически невозможно защититься от всех проблем с JavaScript при разработке приложения, поскольку такие переменные, как браузер, операционная система, страна и интернет-провайдер, могут сильно различаться в рабочей среде.

Вы можете проверить, является ли это проблемой на вашем сайте, с помощью службы мониторинга ошибок JavaScript, такой как Bugsnag. Bugsnag предоставляет исчерпывающие отчеты об ошибках JavaScript, которые обнаруживают эту и все другие ошибки JavaScript.

Начать работу невероятно просто, и вы сразу же начнете получать отчеты об ошибках, содержащие сведения об ошибках пользователя и браузера. Узнайте, как некоторые из наших клиентов используют Bugsnag для отслеживания ошибок JavaScript, например Eventbrite и StubHub. Или начните прямо сейчас и попробуйте бесплатно в течение 14 дней.

Примечание редактора. Этот блог был впервые опубликован в феврале 2014 г. и обновлен для обеспечения точности.

Если вы посмотрите на панель окна журнала ошибок Visual Studio, вы также увидите что-то подобное:

Программа '[3148] iisexpress.exe' завершилась с кодом - 1073741816 ( 0xc0000008 ) 'Указан недопустимый дескриптор' .

Это явно ошибка IISExpress.Стоит отметить, что решение по-прежнему будет запускаться в режиме отладки, но веб-браузер не сможет подключиться к приложению, выдавая следующую постоянную ошибку:

Первое, что вы должны попробовать, это выполнить полную очистку всего решения, а затем попытаться перестроить/отладить его. Если эта предварительная задача не работает для вас, есть много обходных путей, которые могут решить эту проблему: мы предлагаем попробовать их один за другим, останавливаясь только тогда, когда вам удастся это исправить.

Удалите папку \Documents\IISExpress с помощью следующей консольной команды:
rmdir / s / q "%userprofile%\Documents\IISExpress"
Удалите файл applicationhost.config, который находится в папке \.vs\Config\ в корневой папке проекта Visual Studio.
Закройте Visual Studio и перезапустите его с правами администратора (щелкните правой кнопкой мыши Запуск от имени администратора).
Измените случайный URL-адрес веб-сайта проекта: в Visual Studio щелкните правой кнопкой мыши узел проекта в Обозревателе решений, затем выберите Свойства; перейдите на веб-панель, затем измените число в текстовом поле Project Url.
Добавьте системную переменную среды _CSRUN_DISABLE_WORKAROUNDS со значением 1, как показано на следующем снимке экрана (спасибо Хуану М. Элосеги за сообщение об этом в этой теме SO и за изображение):

Если вам удастся решить проблему, сообщите нам, какой из предложенных обходных путей сработал для вас, оставив отзыв в разделе комментариев к этому сообщению.

Читайте также: