Stl: tests/libcxx: re.alg.search/no_update_pos.pass.cpp is UNRESOLVED

[StephanTLavavej]

For some reason, this is specific to x86 - it doesn't repro when I build/test x64.

I observe 2 configurations of "Unresolved Tests":

S:\GitHub\STL\out\build\x86>python tests\utils\stl-lit\stl-lit.py ..\..\..\llvm-project\libcxx\test\std\re\re.alg\re.alg.search -o test.log
[...]
stl-lit.py: S:\GitHub\STL\tests\utils\stl\test\format.py:225: warning: [WinError 740] The requested operation requires elevation
UNRESOLVED: libc++ :: std/re/re.alg/re.alg.search/no_update_pos.pass.cpp:1 (19 of 24)
[...]
stl-lit.py: S:\GitHub\STL\tests\utils\stl\test\format.py:225: warning: [WinError 740] The requested operation requires elevation
UNRESOLVED: libc++ :: std/re/re.alg/re.alg.search/no_update_pos.pass.cpp:0 (22 of 24)
[...]
********************
Unresolved Tests (2):
  libc++ :: std/re/re.alg/re.alg.search/no_update_pos.pass.cpp:0
  libc++ :: std/re/re.alg/re.alg.search/no_update_pos.pass.cpp:1


Testing Time: 19.23s
  Expected Passes  : 14
  Expected Failures:  8
  Unresolved Tests :  2

1 warning(s) in tests

The log file contains:

    {
      "code": "UNRESOLVED",
      "elapsed": 4.137548446655273,
      "name": "libc++ :: std/re/re.alg/re.alg.search/no_update_pos.pass.cpp:0",
      "output": "Exception during script execution:\nTraceback (most recent call last):\n  File \"S:/GitHub/STL/llvm-project/llvm\\utils\\lit\\lit\\worker.py\", line 73, in _execute_test_handle_errors\n    result = test.config.test_format.execute(test, lit_config)\n  File \"S:\\GitHub\\STL\\tests\\utils\\stl\\test\\format.py\", line 167, in execute\n    result = self._execute(test, lit_config)\n  File \"S:\\GitHub\\STL\\tests\\utils\\stl\\test\\format.py\", line 226, in _execute\n    raise e\n  File \"S:\\GitHub\\STL\\tests\\utils\\stl\\test\\format.py\", line 208, in _execute\n    self.test_executor.run(step.cmd, step.work_dir,\n  File \"S:\\GitHub\\STL\\tests\\utils\\stl\\test\\executor.py\", line 63, in run\n    out, err, rc = executeCommand(cmd, cwd=work_dir, env=env)\n  File \"S:\\GitHub\\STL\\tests\\utils\\stl\\util.py\", line 95, in executeCommand\n    p = subprocess.Popen(command, cwd=cwd,\n  File \"C:\\Users\\stl\\AppData\\Local\\Programs\\Python\\Python38\\lib\\subprocess.py\", line 854, in __init__\n    self._execute_child(args, executable, preexec_fn, close_fds,\n  File \"C:\\Users\\stl\\AppData\\Local\\Programs\\Python\\Python38\\lib\\subprocess.py\", line 1307, in _execute_child\n    hp, ht, pid, tid = _winapi.CreateProcess(executable, args,\nOSError: [WinError 740] The requested operation requires elevation\n\n"
    },

The unescaped output is:

Exception during script execution:\nTraceback (most recent call last):
  File "S:/GitHub/STL/llvm-project/llvm\utils\lit\lit\worker.py", line 73, in _execute_test_handle_errors
    result = test.config.test_format.execute(test, lit_config)
  File "S:\GitHub\STL\tests\utils\stl\test\format.py", line 167, in execute
    result = self._execute(test, lit_config)
  File "S:\GitHub\STL\tests\utils\stl\test\format.py", line 226, in _execute
    raise e
  File "S:\GitHub\STL\tests\utils\stl\test\format.py", line 208, in _execute
    self.test_executor.run(step.cmd, step.work_dir,
  File "S:\GitHub\STL\tests\utils\stl\test\executor.py", line 63, in run
    out, err, rc = executeCommand(cmd, cwd=work_dir, env=env)
  File "S:\GitHub\STL\tests\utils\stl\util.py", line 95, in executeCommand
    p = subprocess.Popen(command, cwd=cwd,
  File "C:\Users\stl\AppData\Local\Programs\Python\Python38\lib\subprocess.py", line 854, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "C:\Users\stl\AppData\Local\Programs\Python\Python38\lib\subprocess.py", line 1307, in _execute_child
    hp, ht, pid, tid = _winapi.CreateProcess(executable, args,\nOSError: [WinError 740] The requested operation requires elevation

I suspect that Windows is emitting "The requested operation requires elevation" because no_update_pos.pass.exe is an executable name containing update as a substring, and Windows contains a heuristic that such executables may be installers requiring admin elevation. :grinning: (I've seen this heuristic activate for patch executables in the past.)

I am unsure how to solve this:

• Somehow change how the executable is run? (We don't want to grant it admin privileges, but maybe we can disable the heuristic?)
• Somehow change how the executable is built - I know that there's a way to disable the heuristic by building in a manifest, but that seems highly invasive, especially for libcxx.
• Just skip the test?
• Ask libcxx's maintainers if they'd consider renaming the test; I suspect that even updating would be sufficient to bypass the heuristic, and change, modify, etc. certainly would. This would preserve test coverage and permanently avoid the problem.

[AlexGuteniev]

• I know that there's a way to disable the heuristic by building in a manifest

There are external .manifest files, if it is somehow better than _building in_ manifest.

[StephanTLavavej]

@BillyONeal suggested that it might be as simple as linking with /MANIFESTUAC:level=asInvoker. We could investigate external manifests if the linker option is problematic.

[CaseyCarter]

Ask libcxx's maintainers if they'd consider renaming the test; I suspect that even updating would be sufficient to bypass the heuristic, and change, modify, etc. certainly would. This would preserve test coverage and permanently avoid the problem.

Libc++ maintainers: "Sure, no problem. We'll rename the test." ... ** rename to aux.cpp **

[BillyONeal]

@CaseyCarter Don't give them any ideas

[StephanTLavavej]

/MANIFESTUAC:level=asInvoker doesn't appear to help (I tried compiling/linking directly and it doesn't seem to avoid the prompt).

[AlexGuteniev]

Figured it out.

You need to specify /MANIFEST:EMBED or /MANIFEST as linker option (after /link),
(The first will create ebmeded into executable, the later is standalone .manifest file, for your purposes probably there's no difference, but usually embedded is more convenient)

You don't need to say /MANIFESTUAC:level=asInvoker explicitly - it is implied.
But if you want, should say /MANIFESTUAC:level='asInvoker', otherwise it seems to omit quotes in output and produce broken manifest.

I've reported all problems I've noticed with /MANIFESTUAC option as DevCom-1046798, but they should not block you, as you don't need /MANIFESTUAC at all.

[StephanTLavavej]

Amazing, thank you! I’ll work on a PR.