KDevelop can't load project: "too large document"?

[René J.V. Bertin]

On Wednesday December 06 2017 12:26:26 Matthew Woehlke wrote:

> >         connect(job, &CMakeServerImportJob::result, this, [this, job](){
> >             if (job->error() == 0) {
> >                 manager->integrateData(job->projectData(), job->project());
> >             } else {
> >                 failedConnection(job->error());
> >             }
> >         });
> 
> No luck. It appears that failing to parse the JSON is an unrecoverable
> error. That is, I see no code to cope with that occurrence, and indeed,

The suggested patch above assumes that the cmake server job still emits the result signal but with an error set (which apparently is not unheard of or else there would have been one of those "graceful" ASSERTs on job->error().
I didn't check whether that assumption was correct.

> (I'm building RelWithDebInfo, so I
> assume and expect asserts are not enabled).

(You can also use a custom build type and set the exact compiler options you want via CFLAGS and CXXFLAGS in the environment. That way you're sure you won't get the benefit of all the advanced error handling implemented via asserts ;) )

> The above doesn't *seem* to be necessary with this patch, but I might be
> wrong about that.

No, if errors signalled via a JSON document are indeed handled my suggestion shouldn't be required to handle this particular situation. 

> Handling an error from the *server* appears to be handled. The patch
> hijacks this by synthesizing a response that looks like a server error,
> and passing that back up the stack instead of the "real" response which
> could not be parsed.

OK, so what's the end result of this? Is the project imported using the older importer, or do you just get a failure message? If the latter, you might be able to implement a combined fix by setting the server import job's error flag to a non-zero value and making sure CMakeServerImportJob::result is emitted as soon as possible. With the patch above you should then trigger the fallback importer.
(Sorry for not checking this any further, I've got my head wrapped around other things ATM.)

> 3.10.1. I still think KDevelop should handle this more gracefully,
> though; failing to load the project *and* getting stuck in a state that
> the load can't even be canceled is... less than optimal :-).

Indeed, because as long as Qt's JSON classes have a fixed size limit this error can occur with any big enough project. (The rebooted QtWebKit project for instance, which now uses cmake).

Cancelling a project import was never a good idea in KDevelop and AFAIK not officially supported.

R