Fix #12758: Add markup laguages

[olabetskyi]

No description provided.

[firewave]

This maybe requires all negative language checks to be replaced with positive ones.

[olabetskyi]

This maybe requires all negative language checks to be replaced with positive ones.

Yeah I've thought about it

[danmar]

@firewave a customer had problems when scanning a qml project. There was an assertion error when Language was None.

I think some kind of test should be added when the qml file is not handled properly.

[olabetskyi]

@firewave a customer had problems when scanning a qml project. There was an assertion error when Language was None.

I think some kind of test should be added when the qml file is not handled properly.

It's actually the oposite. It wasn't None. It was set as C++ by default and when we call setLang function to change language for markup file it fails.

[firewave]

I think some kind of test should be added when the qml file is not handled properly.

Yes, a test case would be good to see what is actually going on. This feels like another bandaid fix.

Also QML needs more test coverage.

I promised to provide a PR to disable the asserts for the release but I forgot. But somehow it is good that we expose these issues. Ignoring them is not good and just makes things worse down the line.

[firewave]

This maybe requires all negative language checks to be replaced with positive ones.

I still had a branch with such changes but while reviewing it I no longer was sure if that is a good change. It would dependent on the code. So we should not touch that unless we need to.

Making it a tri-state would make things much more complicated.

Currently we are treating markup as C so that means all code which is isC() == true would be executed. So introducing an additional language would cause none of that code to be executed which will most likely lead to unexpected results.

I think the markup stuff needs to be handled differently and much easier.

[firewave]

Ah - I see the actual problem.

The user specified --language which causes the Settings::enforcedLanguage to be applied in the constructor. Thus the subsequent TokenList::setLang() call fails.

I did consider this and wanted to add the language to the constructor but something was preventing that at the time.

I will look into providing a much less intrusive fix.

[firewave]

See #6425.

[firewave]

Closing in favor of #6425.