remove -dip1000 from default library

[WebFreak001]

DUB taints projects depending on this library with -dip1000 which can introduce memory corruption in previously valid code due to compiler bugs in the current implementation.

I suggest adding a special config for dip1000 / unittest config with it to ensure compatibility with dip1000 there, but not forcing users to use it due to DUB's current dflags handling.

[skoppe]

DUB taints projects depending on this library with -dip1000 which can introduce memory corruption in previously valid code due to compiler bugs in the current implementation.

Do you have an example of such a bug? It would be good to have a reference here.

I suggest adding a special config for dip1000 / unittest config with it to ensure compatibility with dip1000 there, but not forcing users to use it due to DUB's current dflags handling.

I rather see dip1000 adopted everywhere obviously, but I think you are right.

[WebFreak001]

I'm currently working on minimizing it, but I got a bug from returning this from a function (using mir algebraic):

	CompletionOptions completionProvider = {
		resolveProvider: doCompleteSnippets,
		triggerCharacters: [
			".", "=", "/", "*", "+", "-"
		],
		completionItem: CompletionOptions.CompletionItem(true.opt)
	};

	// of type Variant!(void, CompletionOptions)
	ret.completionProvider = completionProvider;

	return ret;

where triggerCharacters was corrupted afterwards, all the strings having bogus pointers, like first one pointing into the stack, second one being 3, third one being 1, fourth one being 0 and then some other very small numbers as pointer fields, causing segmentation fault when trying to use these strings, like printing them.

[skoppe]

Ok. Let me know if you get stuck, I might have some time this week to have a look.

[WebFreak001]

oh that issue is unrelated to concurrency though, I just found it because I had it in the dependencies, but didn't actually use it yet - just the dip1000 caused segfaults in random places in my code that was otherwise working

[skoppe]

I see. I have had my fair share of stack corruption though, and I am always interested in improving dip1000.

[WebFreak001]

here if you want to try reducing it yourself as well, I'm currently starting to dustmite this code which already exhibits the dip1000 bug behavior:

/++ dub.sdl:

name "dip1000-reduce"

// uncomment to introduce segfault:
//dflags "-dip1000"

dependency "mir-core" version="1.6.0"
+/

public import mir.algebraic : Variant, match;

Variant!(void, string[]) test()
{
	Variant!(void, string[]) ret = [
		".", "=", "/", "*", "+", "-"
	];

	return ret;
}

void main()
{
	auto cap = test();
	cap.match!(
		() {
			assert(false, "shouldn't");
		},
		(val) {
			assert(val.length == 6);
			string s = val[0] ~ val[1] ~ val[2] ~ val[3] ~ val[4] ~ val[5];
			assert(s == ".=/*+-");
		}
	);
}

[WebFreak001]

reduced code causing memory corruption:

// run with: dmd -dip1000 -debug -g -w -run bug.d

struct S()
{
	ulong[] payload;

	this(ulong[] value)
	{
		import core.lifetime;

		payload = forward!value;
	}
}

S!() test()
{
	return S!()([0, 1, 2, 3, 4, 5, 6, 7, 8, 9]);
}

void main()
{
	import std.stdio;

	auto val = test().payload;
	writeln("[0]=", val[0], " (should be 0)");
	writeln("[1]=", val[1], " (should be 1)");
	writeln("[2]=", val[2], " (should be 2)");
	writeln("[3]=", val[3], " (should be 3)");
	writeln("[4]=", val[4], " (should be 4)");
	writeln("[5]=", val[5], " (should be 5)");
	writeln("[6]=", val[6], " (should be 6)");
	writeln("[7]=", val[7], " (should be 7)");
	writeln("[8]=", val[8], " (should be 8)");
	writeln("[9]=", val[9], " (should be 8)");
}

[WebFreak001]

bug opened in dmd: https://issues.dlang.org/show_bug.cgi?id=24242