Unmapped code doesn't end up unmapped when called from a constructor

[haltman-at]

Description

Some code that, in a deployed context would be unmapped, in a constructor context instead gets mapped to the contract declaration node.

This is annoying for debugging because, when trying to track what's happened, it's hard to distinguish such implicit jumps from explicit ones in the code. In a deployed context we can tell them apart because one goes into unmapped code. In this context it's a lot harder.

Ideally, the code would remain unmapped in both the constructor and the deployed contexts.

Steps to Reproduce

pragma solidity ^0.8.0;

contract Main {
  constructor() {
    new Secondary();
  }
}

contract Secondary {
}

Before the CREATE for Secondary, there's a brief jump into what, if this weren't a constructor, would be unmapped code. Instead, however, the code is mapped to the contract Main { ... } node.

Note that the bug will still occur if the troublesome segment is inside a different function that's called from the constructor.

Environment

• Compiler version: 0.8.1 (it's in older versions as well; don't know how far back but I tried 0.7.2 and it's in that)
• Target EVM version (as per compiler settings): default
• Framework/IDE (e.g. Truffle or Remix): Truffle

[chriseth]

This seems to be a bit tricky and is related to how the "current source location" is set inside the compiler context. The jump target you mention is a "low level function" and its location might just be taken oven from the previous code. On the other hand, that low level function is created from the Main contract and this it should be valid to sets its location to the Main contract. This is how far I have got now.

If that's easier for you, I can make such utility functions always unmapped, but I still want to find out the cause of the difference between the two cases.

[github-actions[bot]]

This issue has been marked as stale due to inactivity for the last 90 days. It will be automatically closed in 7 days.

[github-actions[bot]]

Hi everyone! This issue has been automatically closed due to inactivity. If you think this issue is still relevant in the latest Solidity version and you have something to contribute, feel free to reopen. However, unless the issue is a concrete proposal that can be implemented, we recommend starting a language discussion on the forum instead.