Fix intermediate type checking in expression parsing

[vyasr]

Description

When parsing expressions, device data references are reused if there are multiple that are identical. Equality is determined by comparing the fields of the reference, but previously the data type was omitted. For column and literal references, this is OK because the data_index uniquely identifies the reference. For intermediates, however, the index is not sufficient to disambiguate because an expression could reuse a given location even if the operation produces a different data type. Therefore, the data type must be part of the equality operator.

Resolves #14409

Checklist

• I am familiar with the Contributing Guidelines.
• New or existing tests cover these changes.
• The documentation is up to date with these changes.

[bdice]

This totally makes sense. I agree with this fix and would support it going into 23.12. Thanks @vyasr.

[vyasr]

/merge

[aocsa]

Regarding the issue at #14409, do you think it might be a good idea to consider implementing unit tests that involve scenarios like having 100 or 1000 elements in a tree, reaching 100 levels of depth, and so on? I believe it would be beneficial to introduce these pathological tests to conduct comprehensive testing and stress the AST, ultimately aiding in the identification and resolution of any potential issues. cc @felipeblazing

[vyasr]

Regarding the issue at #14409, do you think it might be a good idea to consider implementing unit tests that involve scenarios like having 100 or 1000 elements in a tree, reaching 100 levels of depth, and so on? I believe it would be beneficial to introduce these pathological tests to conduct comprehensive testing and stress the AST, ultimately aiding in the identification and resolution of any potential issues. cc @felipeblazing

Yes absolutely. Would you be willing to contribute some new tests? You can follow the pattern in this PR. I'm afraid I won't have time to add them here, but if you opened a PR with such tests and it revealed issue I would be happy to help debug them later.

[aocsa]

Regarding the issue at #14409, do you think it might be a good idea to consider implementing unit tests that involve scenarios like having 100 or 1000 elements in a tree, reaching 100 levels of depth, and so on? I believe it would be beneficial to introduce these pathological tests to conduct comprehensive testing and stress the AST, ultimately aiding in the identification and resolution of any potential issues. cc @felipeblazing

Yes absolutely. Would you be willing to contribute some new tests? You can follow the pattern in this PR. I'm afraid I won't have time to add them here, but if you opened a PR with such tests and it revealed issue I would be happy to help debug them later.

Sure I can do that.

[aocsa]

Regarding the issue at #14409, do you think it might be a good idea to consider implementing unit tests that involve scenarios like having 100 or 1000 elements in a tree, reaching 100 levels of depth, and so on? I believe it would be beneficial to introduce these pathological tests to conduct comprehensive testing and stress the AST, ultimately aiding in the identification and resolution of any potential issues. cc @felipeblazing

Yes absolutely. Would you be willing to contribute some new tests? You can follow the pattern in this PR. I'm afraid I won't have time to add them here, but if you opened a PR with such tests and it revealed issue I would be happy to help debug them later.

Sure I can do that.

@vyasr, I have created a PR that introduces unit test described as before. You can find it here. Good thing, I did not identify any new issues.

[vyasr]

Thanks! I'll have a look.