Miscompilation of `is_whitespace` inside rustc on Windows-msvc (with -Zdylib-lto)

[kpreid]

Code

fn main() {
    println!(
        "Hello \
    • world!"
    );
}

Current output

warning: non-ASCII whitespace symbol '\u{2022}' is not skipped
 --> experiment\src\main.rs:3:16
  |
3 |           "Hello \
  |  ________________^
4 | |     • world!"
  | |     ^ non-ASCII whitespace symbol '\u{2022}' is not skipped
  | |_____|
  |

Desired output

No warning, since U+2022 "•" is not whitespace.

Anything else?

stable-x86_64-pc-windows-msvc - rustc 1.68.0 (2c8cc3432 2023-03-06)

Weirdly, this warning only occurs on Windows. Unfortunately, I have no Windows systems to test on other than GitHub Actions, so it isn't convenient to test further. I hope this bug report is useful anyway.

[Teapot4195]

I have a spare windows system, I'll test further once I get home

[ehuss]

Hm, I can't seem to see a way to reproduce this. There isn't any platform-specific code involved in that warning. Are the logs from the GItHub Actions run publicly available?

[kpreid]

Hm, I can't seem to see a way to reproduce this.

To clarify, do you mean that you compiled the above code using a Windows system and saw no warnings?

There isn't any platform-specific code involved in that warning.

I'm not very familiar with Windows, but isn't it the case that Git checkout puts CRLF in text files on Windows, by default? That could have an influence while not being actually due to platform dependence in rustc, because rustc would be seeing '\\' CR LF spaces '•' instead of '\\' LF spaces '•'

Are the logs from the GItHub Actions run publicly available?

Yep — https://github.com/kpreid/all-is-cubes/actions/runs/4400743620/jobs/7706316716 is the run I used to test the above code. (It has a lot of other noise because it's just a quick hack upon my regular CI — if I have to I could set up a whole new repository with a custom setup.)

[ChrisDenton]

I can reproduce locally using stable msvc rustc:

Z:\test> rustc --version --verbose
rustc 1.68.0 (2c8cc3432 2023-03-06)
binary: rustc
commit-hash: 2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74
commit-date: 2023-03-06
host: x86_64-pc-windows-msvc
release: 1.68.0
LLVM version: 15.0.6
Z:\test> cat whitespace.rs
fn main() {
    "\
£";
}
Z:\test> rustc whitespace.rs
warning: non-ASCII whitespace symbol '\u{a3}' is not skipped
 --> whitespace.rs:2:6
  |
2 |       "\
  |  ______^
3 | | £";
  | | ^ non-ASCII whitespace symbol '\u{a3}' is not skipped
  | |_|
  |

warning: 1 warning emitted

Switching between Unix and Windows line endings does not seem to make a difference.

Using windows-gnu does not have this warning. But that makes no sense to me.

[ChrisDenton]

Ok, this is super weird. It only appears to affect x86_64-msvc:

Z:\test> rustc +1.68-i686-pc-windows-msvc whitespace.rs
Z:\test> rustc +1.68-x86_64-pc-windows-msvc whitespace.rs
warning: non-ASCII whitespace symbol '\u{a3}' is not skipped
 --> whitespace.rs:2:6
  |
2 |       "\
  |  ______^
3 | | £";
  | | ^ non-ASCII whitespace symbol '\u{a3}' is not skipped
  | |_|
  |

warning: 1 warning emitted

[ehuss]

Ah, I see, I was using aarch64-pc-windows-msvc. I tried x86_64-pc-windows-msvc, and that reproduces. How strange!

[ehuss]

I did a quick bisect, and it points to #103591 as where the regression started (cc @lqd).

[ehuss]

I did a little bit of poking around. Inside rustc, it definitely believes '£'.is_whitespace() is true. I don't particularly enjoy investigating inlining or llvm issues, so I probably won't poke around much more.