This also only occurs when --turbo and --always-opt are passed, so looks like a turbofan ends up creating something which is not a isOneByteString .

I noticed that string add is optimized differently in turbofan and crankshaft. Crankshaft inlines few of the cases without calling to the StringAdd stub. I will take a look at this.

This is my TODO in JSTypedLowering, where we always use the cons_string_map, w/o checking whether we could produce a one-byte string instead. This is not a correctness issue tho.

Did this get fixed in the mean time? The original report doesn't repro anymore with ToT and this is one of the legacy cases from the fuzzer evaluation phase.

If it's supposed to still repro, do you have an actual one?

TurboFan probably constant-folds the string addition by now. So using non constant one byte string on one side should still repro. 

Indeed, still repros. Still requires --expose-externalize-string.

function f(a) {
  print(isOneByteString(a + "qwertyuiopasdfghjklzxcvbnm"))
}
f("12345");
f("12345");
%OptimizeFunctionOnNextCall(f)
f("12345");

// Output:
# Compared x64,ignition with x64,ignition_turbo
#
# Flags of x64,ignition:
--abort_on_stack_overflow --expose-gc --allow-natives-syntax --invoke-weak-callbacks --omit-quit --es-staging --expose-externalize-string --random-seed 732681078 --ignition --turbo-filter=~ --hydrogen-filter=~ --nocrankshaft
# Flags of x64,ignition_turbo:
--abort_on_stack_overflow --expose-gc --allow-natives-syntax --invoke-weak-callbacks --omit-quit --es-staging --expose-externalize-string --random-seed 732681078 --ignition --turbo
#
# Difference:
- true
+ false
#
# Source file:
none
#
### Start of configuration x64,ignition:
true
true
true

### End of configuration x64,ignition
#
### Start of configuration x64,ignition_turbo:
true
true
false

### End of configuration x64,ignition_turbo

This was fixed recently with https://chromium-review.googlesource.com/799700