Replace in with const scope for gc implementations

[JinShil]

This PR also addresses #2704 (review)

cc @ZombineDev

About This PR

Followup to
#2676
dlang/phobos#7110
#2680
#2684
#2693
#2694
#2695
#2696
#2697
#2699
#2702
#2704

This one of several PRs I intend to submit, breaking up #2677 into multiple PRs.

This PR predominately addresses code in the gc implementations

Background

This PR is in support of dlang/dmd#10179

in as a parameter storage class is defined as scope const. However in has not yet
been properly implemented so its current implementation is equivalent to const. Properly
implementing in now will likely break code, so it is recommended to avoid using in, and
explicitly use const or scope const instead, until in is properly implemented.

The use of in as a parameter storage class is already discouraged in the documentation. See https://dlang.org/spec/function.html#parameters

[dlang-bot]

Thanks for your pull request and interest in making D better, @JinShil! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub fetch digger
dub run digger -- build "master + druntime#2706"

[rainers]

const should be ok for add/remove root/range, the GC isn't going to change the memory. scope should be removed, though. I think that is what @ZombineDev meant.

[JinShil]

const should be ok for add/remove root/range

But that's not how the GC API is currently written. See...

druntime/src/gc/proxy.d

Lines 228 to 231 in a370406

	void gc_addRange( void* p, size_t sz, const TypeInfo ti = null ) nothrow @nogc
	{
	return instance.addRange( p, sz, ti );
	}

druntime/src/gc/proxy.d

Lines 238 to 241 in a370406

	void gc_removeRange( void* p ) nothrow
	{
	return instance.removeRange( p );
	}

druntime/src/gc/impl/proto/gc.d

Lines 27 to 28 in a370406

	extern (C) void gc_addRange( void* p, size_t sz, const TypeInfo ti = null ) nothrow @nogc;
	extern (C) void gc_addRoot( void* p ) nothrow @nogc;

druntime/src/gc/impl/proto/gc.d

Line 202 in a370406

void addRange(void* p, size_t sz, const TypeInfo ti = null) nothrow @nogc

druntime/src/gc/impl/proto/gc.d

Line 207 in a370406

void removeRange(void* p) nothrow @nogc

Should I modify proto/gc.d and proxy.d to use const?

[rainers]

But that's not how the GC API is written. See...

But it used to have in in core.memory. I'd rather adjust the proxy functions and the GC implementations.

[rainers]

Should I modify proto/gc.d and proxy.d to use const?

Would be nice to be more const-correct, but it might be rather viral as you'll have to change all GC implementations. Should be ok to leave the proxy function as is for now.

[JinShil]

I don't mind making all the changes. I'll try to change them to const void* and see how it goes.

[JinShil]

I tried to make everything const-correct, but as @rainers predicted it snowballed into too many changes outside the scope of this PR. So, I did only what was necessary to keep the status quo.

It's clear there are some const-ness problems in the GC interface and implementations, but fixing that will have to be a different PR.

[rainers]

Looks like core.gc.gcinterface.GC.runFinalizers() should be updated, too.

[JinShil]

Looks like core.gc.gcinterface.GC.runFinalizers() should be updated, too.

Done. Thank you!

[PetarKirov]

Thanks!