feat[ux]: allow conversion of bytestring literals to bytes_M

[tserg]

What I did

Allow compile-time evaluation of convert("VYPER", bytes5) for literal bytestrings.

How I did it

Add a branch to handle conversion from literal bytestrings to bytes_M.

How to verify it

Commit message

feat[ux]: allow conversion of bytestring literals to bytes_M

This commit allows compile-time evaluation of conversion from
literal bytestrings to bytes_M type.

Description for the changelog

Allow conversion of bytestring literals to bytes_M

Cute Animal Picture

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 92.07%. Comparing base (cd31867) to head (9e916f1).
Report is 4 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #4480      +/-   ##
==========================================
- Coverage   92.12%   92.07%   -0.06%     
==========================================
  Files         119      120       +1     
  Lines       16962    17340     +378     
  Branches     2872     2935      +63     
==========================================
+ Hits        15626    15965     +339     
- Misses        919      957      +38     
- Partials      417      418       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[charles-cooper]

i think maybe instead of actually implementing the compile-time evaluation, we should just mark it as is_constant like we do for struct and interface constructors

[tserg]

i think maybe instead of actually implementing the compile-time evaluation, we should just mark it as is_constant like we do for struct and interface constructors

In order to mark it as a constant, wouldn't we need to perform compile-time evaluation even earlier at the stage of `vyper/semantics/analysis/constant_folding.py?

Otherwise, the checks in vyper/builtins/_convert.py would still catch convert(StringT_value, bytesM_T) as a TypeMismatch.

[charles-cooper]

i think maybe instead of actually implementing the compile-time evaluation, we should just mark it as is_constant like we do for struct and interface constructors

In order to mark it as a constant, wouldn't we need to perform compile-time evaluation even earlier at the stage of `vyper/semantics/analysis/constant_folding.py?

that's one way to do it, but we don't even need to go that far

Otherwise, the checks in vyper/builtins/_convert.py would still catch convert(StringT_value, bytesM_T) as a TypeMismatch.

i think that's fine, the user can do convert(b"...", bytes32). the real issue here is that assigning the result of convert() to a constant is rejected because it's not considered constant. (in fact, we could probably mark all builtins which are internally marked as pure as constant, when all the arguments are constant, but not sure that's in scope).

[tserg]

If I understood correctly, what we want is to be able to set the value for a constant as convert(b"...", bytesM_T), but convert("...", bytesM_T would remain invalid. Is this correct?