[GitHub] [tvm] kparzysz-quic opened a new pull request, #12152: [Target] Improve string interpretation in Target creation

[GitBox <gi...@apache.org>]

kparzysz-quic opened a new pull request, #12152:
URL: https://github.com/apache/tvm/pull/12152

   - `SplitString` now preserves escape sequences, but still observes quote characters.
   - Added function `Interpret` that transforms given string according to interpretation rules:
     - outermost quotes are removed (if present),
     - escape sequences inside quotes are preserved verbatim,
     - unquoted escape sequences produce the escaped character (the escape character (\) is removed.
   - Interpretation happens every time a value of any type is to be parsed from a string, e.g. Array<String> will first be parsed as an array, then substrings of the input will be parsed as individual elements of that array. In this case, some parts of the initial input will be parsed (and interpreted) twice.
   
   This new scheme enabled encoding nested arrays of string with any degree of nesting. For example
   ```
   "-field='\\'foo0\\',\\'bar0,bar1\\'','\\'zing0,zing1\\',\\'fred\\''"
   ```
   would correspond to the target kind attribute
   ```
   Array<Array<Array<String>>>("field"))
   ```
   and have the value
   ```
   { { {foo0}, {bar0, bar1} }, { {zing0, zing1}, {fred} } }
   ```


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@tvm.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [tvm] kparzysz-quic commented on pull request #12152: [Target] Improve string interpretation in Target creation

[GitBox <gi...@apache.org>]

kparzysz-quic commented on PR #12152:
URL: https://github.com/apache/tvm/pull/12152#issuecomment-1195474345

   Short answer: no.
   
   This came up when I was working on adding llvm-options to llvm target.  That is going to be `Array<String>`, but I wanted a robust way of embedding arbitrary strings as option values, so that we don't place any restrictions there.  So I thought about how to encode string within a string, etc, especially in a context of an array of strings.  This is the result.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@tvm.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [tvm] kparzysz-quic merged pull request #12152: [Target] Improve string interpretation in Target creation

[GitBox <gi...@apache.org>]

kparzysz-quic merged PR #12152:
URL: https://github.com/apache/tvm/pull/12152


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@tvm.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org