Fix: natspec annotations on constructors

[aarlt]

Part of #1141.

• natspec annotations on constructore where ignored.

[axic]

What is the ABCDEF doing here?

[chriseth]

It specifies a different delimiter. Otherwise, the string would end early in line 696 after uint256)"

[aarlt]

ABCDEF is just a custom delimiter for the raw string literal.

[axic]

Oh right because the quote is right next to it: )"

[aarlt]

@chriseth @axic What is the current state here? Should I just recommit?

[chriseth]

Not sure if we should use this name. The constructor does not really have a signature.

@axic what do you think?

[axic]

I agree this could be improved.

I think there are a couple of different options:

• not having a name, (uint256,uint256) - this should be fine since the fallback cannot have parameters (not preferred)
• having an invalid character in the name, such as constructor:(uint256,uint256) (to reflect the current syntax)
• keeping the contract name, since that is unambigious

[axic]

Actually after #3923 it could just use consturctor(uin256,uin256) since constructor is a restricted name.

Then again, probably natspec needs to be redesigned at this point.

[aarlt]

@axic ok, i would prefer constructor(..).. the questions is where to place that.. in methods, or should we do that within an extra json node...

{
"methods" : {
	"mul(uint256,uint256)" : {
		"notice" : "another multiplier"
	},
	"test(uint256,uint256)" : "this is a really nice constructor"
}
}

hmm.. interesting.. natspecs on fallbacks.. never tried that...

are there already ideas around "redesigning natspec"?

[axic]

#1141 is the most comprehensive collection of issues

[axic]

@aarlt can you please make that change or enable push access for us?

[aarlt]

@axic @chriseth so the final version should be just constructor? I would prefer not to remove potentially useful information.. could imagine that it may be useful for some tools.. am i wrong?

[aarlt]

however, i think next week i will have some time to checkout the natspec redesign.. anything else that should be done beside stuff mentioned in #1141 and #2243? @chriseth you wanted that arbitrary natspec tags are allowed, right? additionally to that I would like to be able to distinguish between natspec tags that need to preserve newlines.. or we just introduce a special json node that will hold the tag values with all the newlines.. it would also be nice to keep track of the line number - so it is possible to retrieve the location of a specific natspec tag within the solidity source.. @axic @chriseth what are your thoughts?

[axic]

Can you create a new issue for that please?

Also I think we can just go forward with constructor in order to get this finally merged.

[aarlt]

@axic @chriseth Is it still correct to place constructor within the methods object?

{
	"methods" : 
	{
		"constructor" : "this is a really nice constructor"
	}
}

[aarlt]

hmm.. looks like that i did something wrong during the rebase.. will check later