Translate XOR, shift left, shift right

[roji]

Closes #18795

Because it just had to be done.

[smitpatel]

To avoid a bug trail, we need to get a report on typeMapping characteristics on each of these operator on different databases. What are supported types. What are corresponding result types. etc

[roji]

edit: added MySQL info as well

XOR/AND/OR

On both SQL Server, PostgreSQL and MySQL, these always casts up to the wider integral operand (so TINYINT XOR BIGINT yields BIGINT). Regular arithmetic operators (e.g. Add) work the same way, all of the below return BIGINT:

SQL Server:

SELECT SQL_VARIANT_PROPERTY(CAST(8 AS SMALLINT) + CAST(1 AS BIGINT), 'BaseType');
SELECT SQL_VARIANT_PROPERTY(CAST(8 AS BIGINT) + CAST(1 AS SMALLINT), 'BaseType');

PostgreSQL:

SELECT pg_typeof(8::BIGINT + 1::SMALLINT);
SELECT pg_typeof(8::SMALLINT + 1::BIGINT);

MySQL:

CREATE TABLE types (tiny TINYINT, small SMALLINT, normal INT, big BIGINT); 
INSERT INTO types (tiny, small, normal, big) VALUES (8, 8, 8, 8);

CREATE TEMPORARY TABLE typeof AS SELECT tiny + big FROM types AS col;
DESCRIBE typeof;
DROP TABLE typeof;

Both return BIGINT. Our type inference doesn't match this: we just call ExpressionExtensions.InferTypeMapping on both sides. Did you have this on your radar, should I open an issue? Not sure if there's anything to check on Sqlite with its lack of real types.

SHL/SHR

Not supported on SQL Server.

On PostgreSQL the operation predictably returns the same type as the left operand. The right side can be SMALLINT or INT but not BIGINT. Modified the inference to simply apply the default mapping on the right-hand operand. Sqlite supports SHL/SHR but again no real typing so...

On MySQL the operation behaves like an arithmetic operator, taking the wider operand type:

CREATE TABLE types (tiny TINYINT, small SMALLINT, normal INT, big BIGINT); 
INSERT INTO types (tiny, small, normal, big) VALUES (8, 8, 8, 8);

CREATE TEMPORARY TABLE typeof AS SELECT tiny >> big FROM types AS col;
DESCRIBE typeof;
DROP TABLE typeof;

[roji]

I'm guessing that the mismatch above (arithmetic widening) doesn't actually manifest as a bug, because integer literals are identical, and even when sent as parameters there's implicit widening logic (either in the ADO.NET driver or in the database). But we may still want to fix this for correctness etc.

[roji]

@smitpatel this testing for translation failure (because of the XOR operator), although the name and purpose logic don't seem to fit - removed the throws assertion and made it into a positive test.

[smitpatel]

Type mapping inference is incorrect. TypeMapping inference needs to account for actual C# expression trees.

Tests should be written for following types for leftshift/rightshift s_SByte, s_Int16, s_Int32, s_Int64, s_Byte, s_UInt16, s_UInt32, s_UInt64
And for exclusive OR - s_SByte, s_Int16, s_Int32, s_Int64, s_Byte, s_UInt16, s_UInt32, s_UInt64, s_Boolean

[smitpatel]

This is incorrect change

[roji]

Closing this for now.