[ refactor ] ScopedSnocList: Swap Scope on SnocList (Phase 2)

[GulinSS]

Introduces the actual swap of List on SnocList for Scope.

Should this change go in the CHANGELOG?

• If this is a fix, user-facing change, a compiler change, or a new paper
  implementation, I have updated CHANGELOG_NEXT.md (and potentially also
  CONTRIBUTORS.md).

[GulinSS]

@spcfox prepared a report of building packages.

TLDR; all builds reached complete step of compilation. 🎉

[GulinSS]

@mjustus
@gallais

Kindly asking for the review! 🙏

[gallais]

Be aware that it may take a while!

Next week is the TYPES conference
The week after that is the CALCO/MFPS joint conferences

We may be able to meet after that but then annual leave may kick in (I'll be away late June to early July).

[GulinSS]

@gallais a reminder at the middle/end of July probably after annual leave

[gallais]

We're meeting tomorrow for a first go at this PR.

[GulinSS]

@gallais
@mjustus

should we solve these conflicts or better wait the review?

[mjustus]

I think solving merge conflicts later is the better approach. We tend to do some refactoring during review (e.g. PR #3593) when we spot opportunities that are too tempting to ignore but those shouldn't be too difficult to merge. I am sure Guillaume and I can help resolving conflicts once we are done reviewing.

EDIT: wrong PR number.

[GulinSS]

hm, I've tried to track the changes but this commit is unclear for me. Could you put more info there?

@gallais
@mjustus

[gallais]

That last one is ongoing changes that are not thematically linked beyond being part of the review as a whole.
We reset the commit before each new session, moving pure refactoring commits past it and then add it back
on with all the stuff we've accumulated during the day to it.

[GulinSS]

@gallais
@mjustus

FYI Not-so-trivial rebase may occur here

[spcfox]

FYI Not-so-trivial rebase may occur here

I can help with that

[GulinSS]

@gallais
@mjustus

Might be better to merge current refactor progress "as is"?

[gallais]

The new academic year is about to start so unfortunately I don't think I'll be able to come back to this for a while.

[GulinSS]

The new academic year is about to start so unfortunately I don't think I'll be able to come back to this for a while.

I mean I could take the branch, make a rebase, and finally propose all these changes to merge at this pr. What do you think?

[GulinSS]

I've collected commits from mjustus@3578f70, then added holes to make it compilable as is to see the needed surface to fix. Applied trivial fixes. Working on filling holes.

[GulinSS]

Short list of all test errors ATM:

idris2/basic/basic055
base/data_bits001
contrib/list_alternating
chez/channels008
chez/chez004
chez/integers
chez/chez032
chez/chez027
refc/buffer
refc/integers
refc/strings
node/node024
node/node004
node/integers

Unfortunately, I am unable to reproduce them locally.
crush.Dockerfile.txt

But locally my list of bad tests are:

chez/channels009
chez/channels008
chez/futures001

Continue digging.

[GulinSS]

All is fine now. LSP test is red but fix is known. It should be applied after.

@mjustus
@gallais

[GulinSS]

Same report as here.

AMD64 (Dockerfile)
Aarch64 (Dockerfile)

LSP issue is known. Everything else is OK for AMD64. Aarch64 has issue with base64 library but it has no relation to current PR.

pack-admin was used to prepare reports.

---

I've updated LSP. Report is fine now.

Actual TOML (with pointing to PR-version Idris2 compiler and PR-version LSP).

[GulinSS]

We are pleased to announce that this commit is once again prepared for merging. The previous iteration was halted due to several critical issues that required attention. Since then, the main branch has advanced significantly. The current state of the code not only passes all relevant tests but also successfully builds the entire pack collection.

Our assessment is that the present state of this Pull Request is now suitable for integration into the main branch. We kindly request that participants in the discussion review the changes to identify any remaining critical issues that would block a merge. We suggest distinguishing these from potential improvements that could be addressed in follow-up work. Should no blocking issues be identified, we recommend proceeding with the merge. This consideration is particularly pertinent given the rapid pace of compiler development; rebasing and incorporating the necessary refinements since the last review cycle alone required over a month of effort.