Add flag --incompatible_use_plus_in_repo_names

[Wyverald]

Defaults to false. When set to true, we use + instead of ~ as the separator in canonical repo names.

Some more subtle changes include:

• We now officially say that the "build" part of version strings (the part that begins with a plus) is ignored and stripped.
• When the flag is set to true, we effectively increase the lockfile version by 1 (see code comment in BazelLockFileModule).
• When true, we no longer insert a _main in front of names of repos generated by module extensions hosted in the main repo. (~abc as a name was problematic, but +abc is not.)
• When true, we no longer insert a v in front of numerical versions in canonical repo names. (my_mod~1.1 could be a Windows short path, but my_mod+1.1 cannot.)

Work towards #22865.

[fmeum]

Looks very thorough, including removing the special cases that are now unnecessary.

How certain we are that + is better than any other alternatives?

[Wyverald]

How certain we are that + is better than any other alternatives?

Let's look at all printable non-alphanumeric ASCII characters:

Character	Verdict	Comments
!	❌	bad on Windows with the !ENVVAR! syntax?
"	❌	quoting hell (also disallowed on Windows)
#	❌	begins a UNIX shell comment
$	❌	begins a UNIX shell env var
%	❌	begins a Windows env var
&	❌	special meaning in UNIX shell
'	❌	quoting hell
(	❌	bad for so many reasons
)	❌	bad for so many reasons
*	❌	wildcard (and disallowed on Windows)
+	✅	candidate! (only weirdness is with Batch copy)
,	❓	common separator in arguments (and weird with Batch move, for one)
-	❌	valid in version names
.	❌	valid in version names
/	❌	nightmare (and disallowed on Windows)
:	❌	disallowed on Windows
;	❌	UNIX Shell statement separator
<	❌	disallowed on Windows
=	❓	may be problematic in env etc.?
>	❌	disallowed on Windows
?	❌	wildcard (and disallowed on Windows)
@	❌	conflicts with marker files? and ... ugly?
[	❌	UNIX Shell special character
\	❌	nightmare (and disallowed on Windows)
]	❌	UNIX Shell special character
^	❌	Batch script special character (wtf Windows)
_	❌	valid in version names
`	❌	UNIX Shell special character
{	❌	UNIX Shell special character
|	❌	disallowed on windows
}	❌	UNIX Shell special character
~	❌	old candidate :(

So it looks like + is the best candidate so far, with , and = being other potential choices. WDYT?

[fmeum]

@ is also a special character in Bash afaik, otherwise that could have maybe been an (ugly) option. I agree with your assessment, the comprehensive list is highly appreciated! Mind linking to it from a code comment?

[meteorcloudy]

@Wyverald Can you file an incompatible issue to track this change? https://github.com/bazelbuild/bazel/issues/new/choose

[meteorcloudy]

@bazel-io fork 7.3.0

[malkia]

There was a slight, but I guess expected fallout, I had to switch some per_file_copt from

build:clang-cl --per_file_copt="external/protobuf~/.*@-Wno-invalid-offsetof"

to

build:clang-cl --per_file_copt="external/protobuf\\+/.*@-Wno-invalid-offsetof"

And because + is part of the regex language it needs to be escaped twice (escape the escaper). Other than that I haven't found other issues.