Make types returned by NEW_TYPE immutable

[fingolfin]

We already do that in HPC-GAP.

However, I am slightly worried that this might break some package which might try to modify a type object. Perhaps @alex-konovalov can run this PR through the full set of package tests somehow (if there is a way to do that w/o too much work, that is!)

@stevelinton any thoughts about this?

[olexandr-konovalov]

@fingolfin I have a special parametrised Jenkins build for such purposes - all it requires is to specify the PR number as a parameter (and it runs tests on Linux, macOS and Windows!). I will check this PR - you can invite me to review it so it will be on my radar.

[stevelinton]

I'm not convinced this change does anything much. MakeImmutable applied to a positional object (which a type is) just resets the IsMutableObj bit in the type (which is not set anyway) and calls PostMakeImmutable on the object.

You can only change a type through ![] and I can see no library code that does that. Any package that modifies types "by brute force" in this way, probably deserves whatever it gets :-)

[olexandr-konovalov]

This has some impact on packages, indeed - the log reports:

LoadAllPackages test failed: 3 configurations successful out of 4
Additionally, 1 packages crashed during loading

I will look for more details in the log later.

[codecov]

Codecov Report

Merging #2395 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #2395      +/-   ##
==========================================
+ Coverage   74.01%   74.01%   +<.01%     
==========================================
  Files         484      484              
  Lines      245371   245377       +6     
==========================================
+ Hits       181615   181625      +10     
+ Misses      63756    63752       -4

Impacted Files	Coverage Δ
src/c_type1.c	83.43% <100%> (+0.02%)	⬆️
hpcgap/src/c_type1.c	81.31% <100%> (+0.01%)	⬆️
hpcgap/lib/hpc/stdtasks.g	64.96% <0%> (+1.02%)	⬆️

[olexandr-konovalov]

@fingolfin I will run tests again with the newer version of this PR

[stevelinton]

I remain unsure why this change will do anything at all. If it does cause changes, can we try and understand why before we merge anything.

[fingolfin]

I fully agree and added the DO NOT MERGE LABEL.

[olexandr-konovalov]

I've triggered a new Jenkins test this morning to check this PR with the latest selection of packages. Will post updates from the test logs later today.

[olexandr-konovalov]

I've re-run tests with a new selection of packages, and don't see any problems any more.