Improper handling of strings explicitly ending with null

[DanielELog]

Let there be a string: null\0.
When code containing it is compiled to CIR, it'll turn into something like this (emitting less important parts):
cir.global <...> = #cir.const_array<"null" : !cir.array<!s8i x 4>, trailing_zeros> : !cir.array<!s8i x 6> ....
Notice that const_array's type length is shorter than that of global it's contained within.
As this global is eventually used, get_global will state the type as !cir.array<!s8i x 6>.
Compiler doesn't throw any warnings or errors through all of this.

However, the issue rises when the compiled file is later attempted to be parsed by mlir tools, namely mlir::parseSourceFile. Instead of a reference to an object representing parsed code, it returns nullptr, and writes the next text to stderr:
error: 'cir.get_global' op result type pointee type ''!cir.array<!cir.int<s, 8> x 6>'' does not match type '!cir.array<!cir.int<s, 8> x 4>' of the global @.str.

Steps to reproduce:

• Create a .c-file with the following code pasted in:

const char *funnyThing() {
  return "null\0";
}

• Compile it to ClangIR:
  clang -S -Xclang -emit-cir-flat <just created file>.c

• Create another program that tries to parse CIR files:

#include <clang/CIR/Dialect/IR/CIRDialect.h>
#include <mlir/Parser/Parser.h>

int main(int argc, char *argv[]) {
  mlir::MLIRContext context;
  mlir::DialectRegistry registry;
  registry.insert<cir::CIRDialect>();
  context.appendDialectRegistry(registry);
  context.allowUnregisteredDialects();

  mlir::ParserConfig parseConfig(&context);
  auto module =
      mlir::parseSourceFile<mlir::ModuleOp>("<compiled file>", parseConfig);
  if (module.get() == nullptr) {
    return -1;
  }
  return 0;
}

• Compile and run it

Expected behaviour:

The program exits successfully.

Actual behaviour:

The program exits with a return code of -1 and the aforementioned error text message in console.

Additional notes:

• The same happens if you initialise a char-array with a string literal of shorter length:
  char notNull[25] = "null";

• Everything is parsed just fine if the null-char is placed in the middle of the string, as in: null\0null

• This behaviour was observed on a slightly modified clangir repo for our own needs, but none of the original source code was explicitly changed. It is, though, behind upstream.

[shrikardongre]

Hi would definitely like to give it a try !

[shrikardongre]

Sorry I was not able to pick this up immediately due to health reasons .Will start working on it now .

[shrikardongre]

@el-ev please feel free to take it up if you want to . I was busy with #1560
😃