The changes in this file shouldn't be in the patch as they were only added to allow for easy testing in debug mode.

This data type doesn't seem to be used anywhere after the move to the sorted array list, remove.

Use uint16_t instead.

uint16_t

I would probably rename this to LineartAdjacentEdge.
This is because I think Item is a bit fuzzy and this can't or shouldn't really be used for anything else than looking up adjacent edge loops.

Why do you cast to int here? The variables are already integers?
Doesn't seem like there are any warnings for removing these casts on my machine either.

I would add a comment here to clarify that this function returns true if p1 is smaller than p2.

The cmp in the function name made me first think that this would return true if p1 == p2.
So I think it is good to clarify this.

This seems unrelated to this patch?

Same as above.

I think moving this struct and the add_loose_edge function to be just above lineart_identify_loose_edges would be better.
This is so they are somewhat close together and they are then also nicely grouped together.

You should split this method into two.

Now it takes way too long to figure out what it does because of the massive if statements.
Especially because the function is just either adding an edge to a dynamic array or joining two arrays.
You could split out the memory allocation into a helper function of course.

But now I feel that these should be two functions. One for joining two edge arrays (the reduce function) and one for adding and loose edge to an array.

It think this comment should be expanded. Now it doesn't really tell the reader why.

Something like:

/* Because the Edge Neighbour array contains loop edge pairs, we only need to process the first edge in the pair.
 * Otherwise we would add the same edge that the loops represent twice. */

Move this into the if statement below.
I would also probably rename them to f1 and f2.
Perhaps ff1, and ff2 would be better as well?
Basically I think that having numbers instead of "right" and "left" shortened to r and l is easier to understand at a glance.

Same reasoning as above. Why doesn't this handle the mesh boundary case?
Explain it in the comment! :)

You don't need this else after the return statement above.
Remove it.

Just declare the array this points to as view_vector and pass it with &view_vector to the functions below.
No need to create a helper pointer like this.

I would rename these three variables, here and in the code where they are used:
en -> edge_nabr
ai -> adj_e
lt -> mlooptri (as it is named in other parts of the loading code

I would drop the _use suffix here.

I think ai_use -> adj_e is clear enough.
(same for the other _use variables in the code.

Keep these (start/end) PIL_ call behind G.debug_value == 4000 if statements if you want to keep them.

These are not vertices, but edges?

As the old object load function doesn't exist anymore, we can rename this back to object_load, right?
That way you don't need to update comments in the code referring to the old function as well.

I would rename this to crease_threshold as this is not a boolean but a threshold.

v1 and v2 are unsigned, so if not including the (int) there then the result of that equation won't actually be negative? (I didn't confirm this, it's just when I was trying to see where the problem is in the cmp function, might not need this after all.)

I'm doing this so view_vector being a pointer can also point to rb->view_vector when it's ortho camera. This way we don't need to copy or recalculate. And code can be the same.

I'll rename to lineart_geometry_object_load_single for now, because I want to have it distinguishable so it creates less problem on other branches when I pick commits. Maybe later when everything is in we can do a final clean up for names like this?

I think here actual_crease is better.

Looks like we don't (int) so removed.

Then rename vv to view_vector_persp

It shouldn't matter what you have in the other branches as you deleted the old function.
So if you try to pull in this change you will get conflicts either way.

I don't think that implementing "hacks" for stuff that is not in the master branch is a good solution either.

Perhaps just crease_angle ?