2012-03-12 Баги KDevelop

Материал из YourcmcWiki
Перейти к: навигация, поиск
м
м
 
(не показаны 3 промежуточные версии этого же участника)
Строка 1: Строка 1:
KDevelop всё-таки имеет баги, например я нашёл полтора: [https://bugs.kde.org/show_bug.cgi?id=283356 баг 283356] и [https://bugs.kde.org/show_bug.cgi?id=295766 баг 295766].
+
KDevelop всё-таки имеет баги, например я наступил на полтора: [https://bugs.kde.org/show_bug.cgi?id=295866 баг 295866] и [https://bugs.kde.org/show_bug.cgi?id=295766 баг 295766].
  
 
Второй как бы не совсем баг, но если пытаться скормить в KDevelop что-то безумное типа битрикса, где пипец как много каталогов, он повисает в попытках сделать очередной inotify, на который ему говорит «хрен там» ядро, ибо по дефолту sysctl fs.inotify.max_user_watches = 8192… Я лично считаю, что он в этой ситуации не должен повисать намертво, а должен просить поднять лимит… Но в любом случае этот «полубаг» успешно обходится, собственно, поднятием лимита.
 
Второй как бы не совсем баг, но если пытаться скормить в KDevelop что-то безумное типа битрикса, где пипец как много каталогов, он повисает в попытках сделать очередной inotify, на который ему говорит «хрен там» ядро, ибо по дефолту sysctl fs.inotify.max_user_watches = 8192… Я лично считаю, что он в этой ситуации не должен повисать намертво, а должен просить поднять лимит… Но в любом случае этот «полубаг» успешно обходится, собственно, поднятием лимита.
Строка 15: Строка 15:
 
Смысл в том, что оно пытается делать довольно приличный статический анализ PHP-кода, и запоминает поля, определённые присваиванием. А кроме того, оно пытается предупреждать о некорректных переопределениях (ну например дважды var $x в одном классе). Но из-за этого оно раньше ругалось на переопределение, если сначала видело присваивание, а только потом определение. Это типа зафиксили в баге [https://bugs.kde.org/show_bug.cgi?id=241750 баг 241750], но только криво зафиксили — код почему-то подразумевает, что видит определение именно внутри метода класса, и тупо использует currentContext()->parentContext() (то есть «тело функции» → «тело класса»). Но:
 
Смысл в том, что оно пытается делать довольно приличный статический анализ PHP-кода, и запоминает поля, определённые присваиванием. А кроме того, оно пытается предупреждать о некорректных переопределениях (ну например дважды var $x в одном классе). Но из-за этого оно раньше ругалось на переопределение, если сначала видело присваивание, а только потом определение. Это типа зафиксили в баге [https://bugs.kde.org/show_bug.cgi?id=241750 баг 241750], но только криво зафиксили — код почему-то подразумевает, что видит определение именно внутри метода класса, и тупо использует currentContext()->parentContext() (то есть «тело функции» → «тело класса»). Но:
 
* Присваивание бывает вообще снаружи класса, и тогда parentContext = NULL ⇒ SEGFAULT.
 
* Присваивание бывает вообще снаружи класса, и тогда parentContext = NULL ⇒ SEGFAULT.
* Определение поля — в классе, но не внутри метода, соответственно, и сам «фикс» ошибки переопределения ни фига не работает. Вернее работает, но не всегда, а как повезёт, в зависимости от порядка добавления присваивания и определения. Если сначала написать присваивание внутри метода класса, а ''потом'', после него, определение — не работает.
+
* <s>Определение поля — в классе, но не внутри метода, соответственно, и сам «фикс» ошибки переопределения ни фига не работает. Вернее работает, но не всегда, а как повезёт, в зависимости от порядка добавления присваивания и определения. Если сначала написать присваивание внутри метода класса, а ''потом'', после него, определение — не работает.</s> (на самом деле это не так — не работало для всех классов, кроме первого в файле)
  
 
Хз, может и попробую зафиксить, но не факт, что это окажется легко. То есть, в качестве быстрого хака, если хочется работать, можно просто выпилить весь блок кода, отвечающий за этот фикс, из DeclarationBuilder::declareClassMember (в kdev-php/duchain/builders/declarationbuilder.cpp), но хочется-то зафиксить как надо.
 
Хз, может и попробую зафиксить, но не факт, что это окажется легко. То есть, в качестве быстрого хака, если хочется работать, можно просто выпилить весь блок кода, отвечающий за этот фикс, из DeclarationBuilder::declareClassMember (в kdev-php/duchain/builders/declarationbuilder.cpp), но хочется-то зафиксить как надо.
 +
 +
'''UPDATE''': Зафиксил! :) Отлаживался контрольными принтами, gdb и ++овый шаблонный бред не осилил. [https://bugs.kde.org/attachment.cgi?id=69627 патч]-то всего на +1/-2 строчки (первая не в счёт, ибо идентична), но пока поймёшь, что куда… :) [http://bugsfiles.kde.org/attachment.cgi?id=69627 Скачать патч из багзиллы KDE]. Исходники битрикса погружены успешно, KDevelop можно пробовать дальше.
 
{{wl-publish: 2012-03-12 02:41:29 +0400 | VitaliyFilippov }}
 
{{wl-publish: 2012-03-12 02:41:29 +0400 | VitaliyFilippov }}

Текущая версия на 01:57, 15 марта 2012

KDevelop всё-таки имеет баги, например я наступил на полтора: баг 295866 и баг 295766.

Второй как бы не совсем баг, но если пытаться скормить в KDevelop что-то безумное типа битрикса, где пипец как много каталогов, он повисает в попытках сделать очередной inotify, на который ему говорит «хрен там» ядро, ибо по дефолту sysctl fs.inotify.max_user_watches = 8192… Я лично считаю, что он в этой ситуации не должен повисать намертво, а должен просить поднять лимит… Но в любом случае этот «полубаг» успешно обходится, собственно, поднятием лимита.

А вот первый — действительно баг — KDevelop время от времени валится на некоторых исходниках. Я поотлаживал и нашёл минимальный тест, простой PHP-код, который валит KDevelop :)

<?php
$a = new A();
$a->x = 1;
class A {
    var $x = 1;
}

Смысл в том, что оно пытается делать довольно приличный статический анализ PHP-кода, и запоминает поля, определённые присваиванием. А кроме того, оно пытается предупреждать о некорректных переопределениях (ну например дважды var $x в одном классе). Но из-за этого оно раньше ругалось на переопределение, если сначала видело присваивание, а только потом определение. Это типа зафиксили в баге баг 241750, но только криво зафиксили — код почему-то подразумевает, что видит определение именно внутри метода класса, и тупо использует currentContext()->parentContext() (то есть «тело функции» → «тело класса»). Но:

  • Присваивание бывает вообще снаружи класса, и тогда parentContext = NULL ⇒ SEGFAULT.
  • Определение поля — в классе, но не внутри метода, соответственно, и сам «фикс» ошибки переопределения ни фига не работает. Вернее работает, но не всегда, а как повезёт, в зависимости от порядка добавления присваивания и определения. Если сначала написать присваивание внутри метода класса, а потом, после него, определение — не работает. (на самом деле это не так — не работало для всех классов, кроме первого в файле)

Хз, может и попробую зафиксить, но не факт, что это окажется легко. То есть, в качестве быстрого хака, если хочется работать, можно просто выпилить весь блок кода, отвечающий за этот фикс, из DeclarationBuilder::declareClassMember (в kdev-php/duchain/builders/declarationbuilder.cpp), но хочется-то зафиксить как надо.

UPDATE: Зафиксил! :) Отлаживался контрольными принтами, gdb и ++овый шаблонный бред не осилил. патч-то всего на +1/-2 строчки (первая не в счёт, ибо идентична), но пока поймёшь, что куда… :) Скачать патч из багзиллы KDE. Исходники битрикса погружены успешно, KDevelop можно пробовать дальше.