Make cpp assembly file extensions case sensitive again

[Gormo]

This fixes an issue introduced by PR #14005 where .s and .S
extensions were handled case-insensitive on Windows so the action
assemble was triggered instead of preprocess_assemble.

[oquenchil]

LGTM

[Gormo]

@lberki, can we merge this so we don't need to maintain this patch locally when doing uplifts?

[oquenchil]

@buildbreaker2021 will take over the review and import.

[buildbreaker2021]

lgtm

[comius]

This PR seems to negate the assumptions made in WindowsOsPathPolicy.endsWith, that Windows don't know about character case (upper/lower). https://cs.opensource.google/bazel/bazel/+/master:src/main/java/com/google/devtools/build/lib/vfs/WindowsOsPathPolicy.java;l=213;drc=9cb59369a84d9328c2929eefcb58c1b972ab15f2

Having a special case for Windows in CppFileTypes introduces a tech debt in my opinion - there's lack of comments (in this PR) why there is a need for a special case here. Please add a comment with a link to an issue.

I think the right thing to do is to remove the assumption (of case insensitivity) in WindowsOsPathPolicy and then fix the locations where poorly behaved toolchains create either lower or upper cased suffices.

[torgil]

I think the right thing to do is to remove the assumption (of case insensitivity) in WindowsOsPathPolicy and then fix the locations where poorly behaved toolchains create either lower or upper cased suffices.

This would reintroduce the issues in #14005. The "right thing" question in there was never properly discussed but you could reason that a new windows user would have a hard time to "fix" third-party libraries for casing (Microsoft clibs package in my case) or make Windows-specific case-by-case additions to CppFileTypes.

[comius]

I think the right thing to do is to remove the assumption (of case insensitivity) in WindowsOsPathPolicy and then fix the locations where poorly behaved toolchains create either lower or upper cased suffices.

This would reintroduce the issues in #14005. The "right thing" question in there was never properly discussed but you could reason that a new windows user would have a hard time to "fix" third-party libraries for casing (Microsoft clibs package in my case) or make Windows-specific case-by-case additions to CppFileTypes.

Sure, I agree.

Would you mind just adding a comment to the code, that "FileType is extended to use case-sensitive comparison also on Windows". I don't want the next developer hitting their head on it.

When this piece of code is rewritten to Starlark, we won't have the luxury of extending FileType, all file types will need to be listed case-sensitively. Perhaps special cased for linux/windows/macos one level higher.

I'm not sure if it's a good or a bad news we only need to special case this one special operating system :)

[Gormo]

Ok for merge now?

[fmeum]

@bazel-io flag

[sgowroji]

@bazel-io fork 5.3.0