Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stabilize #[coverage] attribute #130766

Merged
merged 1 commit into from
Dec 17, 2024

Conversation

clarfonthey
Copy link
Contributor

@clarfonthey clarfonthey commented Sep 23, 2024

Closes #84605, which passed FCP.

Stabilisation report here: #84605 (comment)

Also added to reference here: rust-lang/reference#1628


try-job: aarch64-apple
try-job: x86_64-gnu
try-job: x86_64-msvc

@rustbot
Copy link
Collaborator

rustbot commented Sep 23, 2024

r? @nnethercote

rustbot has assigned @nnethercote.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Sep 23, 2024
@rustbot
Copy link
Collaborator

rustbot commented Sep 23, 2024

Some changes occurred in coverage tests.

cc @Zalathar

rust-analyzer is developed in its own repository. If possible, consider making this change to rust-lang/rust-analyzer instead.

cc @rust-lang/rust-analyzer

@clarfonthey clarfonthey force-pushed the stable-coverage-attribute branch from dc49513 to 4b64d0d Compare September 23, 2024 23:49
@rust-log-analyzer

This comment has been minimized.

@clarfonthey clarfonthey force-pushed the stable-coverage-attribute branch from 4b64d0d to 2a11c1d Compare September 24, 2024 01:36
@rust-log-analyzer

This comment has been minimized.

@clarfonthey clarfonthey force-pushed the stable-coverage-attribute branch from 2a11c1d to 8037f0c Compare September 24, 2024 02:29
@rust-log-analyzer

This comment has been minimized.

@nnethercote
Copy link
Contributor

I will forward this to a more appropriate reviewer:

r? @Zalathar

@rustbot rustbot assigned Zalathar and unassigned nnethercote Sep 24, 2024
@clarfonthey
Copy link
Contributor Author

FWIW, I'm currently working on fixing the test errors-- my computer kept crashing which made it difficult to run all the tests. Unfortunately a lot of coverage tests are now off-by-one due to the removal of the line enabling the feature, and they're all going to have to be re-blessed.

@clarfonthey clarfonthey force-pushed the stable-coverage-attribute branch from 8037f0c to 53c467b Compare September 24, 2024 03:19
@rust-log-analyzer

This comment has been minimized.

@clarfonthey
Copy link
Contributor Author

clarfonthey commented Sep 24, 2024

Appear to be getting very weird crashes with the debuginfo tests. From the backtrace:

Backtrace
#0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1  0x000075b3eae5d463 in __pthread_kill_internal (threadid=<optimized out>, signo=6) at pthread_kill.c:78
#2  0x000075b3eae04120 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3  0x000075b3eadeb4c3 in __GI_abort () at abort.c:79
#4  0x000075b3eb0e451b in fatal_error_exit (status=-1) at Python/pylifecycle.c:2737
#5  fatal_error (fd=<optimized out>, header=header@entry=1, prefix=prefix@entry=0x75b3eb372990 <__func__.10.lto_priv.1> "PyImport_AppendInittab", msg=msg@entry=0x75b3eb2bf7c0 "PyImport_AppendInittab() may not be called after Py_Initialize()", status=status@entry=-1) at Python/pylifecycle.c:2848
#6  0x000075b3eb0e4899 in _Py_FatalErrorFunc (func=0x75b3eb372990 <__func__.10.lto_priv.1> "PyImport_AppendInittab", msg=0x75b3eb2bf7c0 "PyImport_AppendInittab() may not be called after Py_Initialize()") at Python/pylifecycle.c:2934
#7  0x000075b3eb034330 in PyImport_AppendInittab (name=<optimized out>, initfunc=<optimized out>) at Python/import.c:1499
#8  0x000075b3e9c61aa2 in InitializePythonRAII () at /usr/src/debug/lldb/lldb-18.1.8.src/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp:110
#9  lldb_private::ScriptInterpreterPythonImpl::Initialize () at /usr/src/debug/lldb/lldb-18.1.8.src/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp:2938
#10 0x000075b3eae608fb in __pthread_once_slow (once_control=0x75b3ea3c32a4 <lldb_private::ScriptInterpreterPython::Initialize()::g_once_flag>, init_routine=0x75b3ddc9e2e0 <std::__once_proxy()>) at pthread_once.c:116
#11 0x000075b3eae60979 in ___pthread_once (once_control=<optimized out>, init_routine=<optimized out>) at pthread_once.c:143
#12 0x000075b3e96f5180 in __gthread_once () at /usr/include/c++/14.1.1/x86_64-pc-linux-gnu/bits/gthr-default.h:713
#13 call_once<lldb_private::ScriptInterpreterPython::Initialize()::<lambda()> > () at /usr/include/c++/14.1.1/mutex:916
#14 call_once<lldb_private::ScriptInterpreterPython::Initialize()::<lambda()> > () at /usr/include/llvm/Support/Threading.h:89
#15 lldb_private::ScriptInterpreterPython::Initialize () at /usr/src/debug/lldb/lldb-18.1.8.src/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp:348
#16 lldb_private::lldb_initialize_ScriptInterpreterPython () at /usr/src/debug/lldb/lldb-18.1.8.src/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp:64
#17 lldb_private::SystemInitializerFull::Initialize () at /usr/src/debug/lldb/lldb-18.1.8.src/build/source/Plugins/Plugins.def:104
#18 0x000075b3e95c543e in lldb_private::SystemLifetimeManager::Initialize () at /usr/src/debug/lldb/lldb-18.1.8.src/source/Initialization/SystemLifetimeManager.cpp:36
#19 lldb::SBDebugger::InitializeWithErrorHandling () at /usr/src/debug/lldb/lldb-18.1.8.src/source/API/SBDebugger.cpp:219
#20 0x000075b3e9727ddb in lldb::SBDebugger::Initialize () at /usr/src/debug/lldb/lldb-18.1.8.src/source/API/SBDebugger.cpp:175
#21 _wrap_SBDebugger_Initialize () at /usr/src/debug/lldb/lldb-18.1.8.src/build/bindings/python/LLDBWrapPython.cpp:23282
#22 0x000075b3eb13bd1b in cfunction_vectorcall_NOARGS (func=0x75b3ea6f6750, args=<optimized out>, nargsf=<optimized out>, kwnames=0x0) at ./Include/cpython/methodobject.h:50
#23 0x000075b3eb15caed in _PyObject_VectorcallTstate (tstate=0x75b3eb5e3198 <_PyRuntime+459704>, callable=0x75b3ea6f6750, args=0x75b3eb5f1468, nargsf=9223372036854775808, kwnames=0x0) at ./Include/internal/pycore_call.h:92
#24 PyObject_Vectorcall (callable=0x75b3ea6f6750, args=0x75b3eb5f1468, nargsf=9223372036854775808, kwnames=0x0) at Objects/call.c:325
#25 0x000075b3eb141829 in _PyEval_EvalFrameDefault (tstate=<optimized out>, frame=<optimized out>, throwflag=<optimized out>) at Python/bytecodes.c:2715
#26 0x000075b3eb2064b5 in PyEval_EvalCode (co=0x5cdfa44d2040, globals=<optimized out>, locals=0x75b3ea855980) at Python/ceval.c:578
#27 0x000075b3eb222a76 in builtin_exec_impl (module=<optimized out>, source=0x5cdfa44d2040, globals=0x75b3ea855980, locals=0x75b3ea855980, closure=<optimized out>) at Python/bltinmodule.c:1096
#28 builtin_exec (module=<optimized out>, args=<optimized out>, nargs=<optimized out>, kwnames=<optimized out>) at Python/clinic/bltinmodule.c.h:586
#29 0x000075b3eb15cc3e in cfunction_vectorcall_FASTCALL_KEYWORDS (func=<optimized out>, args=0x75b3ea86e358, nargsf=<optimized out>, kwnames=0x0) at Objects/methodobject.c:438
#30 0x000075b3eb146c11 in PyCFunction_Call (callable=0x75b3ea938770, args=0x75b3ea86e340, kwargs=0x75b3ea86fec0) at Objects/call.c:387
#31 _PyEval_EvalFrameDefault (tstate=<optimized out>, frame=<optimized out>, throwflag=<optimized out>) at Python/bytecodes.c:3263
#32 0x000075b3eb16798b in _PyObject_VectorcallTstate (tstate=0x75b3eb5e3198 <_PyRuntime+459704>, callable=0x75b3ea93c040, args=0x7ffce28e7510, nargsf=2, kwnames=0x0) at ./Include/internal/pycore_call.h:92
#33 object_vacall (tstate=tstate@entry=0x75b3eb5e3198 <_PyRuntime+459704>, base=<optimized out>, callable=0x75b3ea93c040, vargs=0x7ffce28e75a0) at Objects/call.c:850
#34 0x000075b3eb1999eb in PyObject_CallMethodObjArgs (obj=<optimized out>, name=<optimized out>) at Objects/call.c:911
#35 0x000075b3eb198f19 in import_find_and_load (tstate=0x75b3eb5e3198 <_PyRuntime+459704>, abs_name=0x75b3ea7ac360) at Python/import.c:2779
#36 PyImport_ImportModuleLevelObject (name=0x75b3ea7ac360, globals=<optimized out>, locals=<optimized out>, fromlist=0x75b3eb56a460 <_Py_NoneStruct>, level=0) at Python/import.c:2862
#37 0x000075b3eb1494d1 in import_name (tstate=<optimized out>, frame=<optimized out>, name=0x75b3ea7ac360, fromlist=0x75b3eb56a460 <_Py_NoneStruct>, level=0x75b3eb573aa8 <_PyRuntime+3272>) at Python/ceval.c:2482
#38 _PyEval_EvalFrameDefault (tstate=<optimized out>, frame=<optimized out>, throwflag=<optimized out>) at Python/bytecodes.c:2144
#39 0x000075b3eb2064b5 in PyEval_EvalCode (co=0x5cdfa44ec7e0, globals=<optimized out>, locals=0x75b3ea77ef00) at Python/ceval.c:578
#40 0x000075b3eb22a84a in run_eval_code_obj (tstate=tstate@entry=0x75b3eb5e3198 <_PyRuntime+459704>, co=co@entry=0x5cdfa44ec7e0, globals=globals@entry=0x75b3ea77ef00, locals=locals@entry=0x75b3ea77ef00) at Python/pythonrun.c:1722
#41 0x000075b3eb22572f in run_mod (mod=mod@entry=0x5cdfa450e6a0, filename=filename@entry=0x75b3ea7c1590, globals=globals@entry=0x75b3ea77ef00, locals=locals@entry=0x75b3ea77ef00, flags=flags@entry=0x7ffce28e7b90, arena=arena@entry=0x75b3ea8b5fd0) at Python/pythonrun.c:1743
#42 0x000075b3eb23fd14 in pyrun_file (fp=fp@entry=0x5cdfa43ec550, filename=filename@entry=0x75b3ea7c1590, start=start@entry=257, globals=globals@entry=0x75b3ea77ef00, locals=locals@entry=0x75b3ea77ef00, closeit=closeit@entry=1, flags=0x7ffce28e7b90) at Python/pythonrun.c:1643
#43 0x000075b3eb23f5a1 in _PyRun_SimpleFileObject (fp=0x5cdfa43ec550, filename=0x75b3ea7c1590, closeit=1, flags=0x7ffce28e7b90) at Python/pythonrun.c:433
#44 0x000075b3eb23ecff in _PyRun_AnyFileObject (fp=0x5cdfa43ec550, filename=0x75b3ea7c1590, closeit=1, flags=0x7ffce28e7b90) at Python/pythonrun.c:78
#45 0x000075b3eb2374c4 in pymain_run_file_obj (program_name=0x75b3ea77f030, filename=0x75b3ea7c1590, skip_source_first_line=0) at Modules/main.c:360
#46 pymain_run_file (config=0x75b3eb585d78 <_PyRuntime+77720>) at Modules/main.c:379
#47 pymain_run_python (exitcode=0x7ffce28e7b64) at Modules/main.c:633
#48 Py_RunMain () at Modules/main.c:713
#49 0x000075b3eb1f1c2c in Py_BytesMain (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:767
#50 0x000075b3eadece08 in __libc_start_call_main (main=main@entry=0x5cdf84c7e120 <main>, argc=argc@entry=4, argv=argv@entry=0x7ffce28e7df8) at ../sysdeps/nptl/libc_start_call_main.h:58
#51 0x000075b3eadececc in __libc_start_main_impl (main=0x5cdf84c7e120 <main>, argc=4, argv=0x7ffce28e7df8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffce28e7de8) at ../csu/libc-start.c:360
#52 0x00005cdf84c7e045 in _start ()

I'm just going to run ./x clean and hope that fixes it. But it looks like there might be some weird inconsistency between Rust wanting to run the version of LLVM in the repo, and the one on my machine…


Yeah, okay. It might also be a difference in Python 3.12 that broke something too, but either way, the debuginfo tests show up as failing on my machine and the coverage tests show up as passing also, so, something weird is afoot.

@traviscross
Copy link
Contributor

cc @rust-lang/lang

@jieyouxu
Copy link
Member

Yeah, okay. It might also be a difference in Python 3.12 that broke something too, but either way, the debuginfo tests show up as failing on my machine and the coverage tests show up as passing also, so, something weird is afoot.

I'm not exactly sure what debuginfo tests want, but bootstrap and other parts of compiletest AFAIK assumes Python 3.10 exactly, not 3.9 or 3.12.

@clarfonthey
Copy link
Contributor Author

clarfonthey commented Sep 24, 2024

I'm not exactly sure what debuginfo tests want, but bootstrap and other parts of compiletest AFAIK assumes Python 3.10 exactly, not 3.9 or 3.12.

That feels worth documenting somewhere, considering how on my end that just shows up as LLVM hard-crashing and not as a wrong Python version. Like, maybe even worth having a virtualenv setup for the repo just to guarantee the right Python version is being used.

@jieyouxu
Copy link
Member

I'm not sure if that's the root cause of your crashes, but if it is, then yes

@clarfonthey
Copy link
Contributor Author

Well, I'm currently installing 3.10, so, we'll hopefully find out!

@jieyouxu
Copy link
Member

jieyouxu commented Sep 24, 2024

Actually sorry minor correction: it's not bootstrap that expects Python 3.10 (as I see there is a toolstate check that goes through 3.10+ as well), but something in compiletest (maybe debuginfo tests?) expect Python 3.10 dll to be available.

EDIT: I remembered what it is, it's lldb debuginfo tests, that requires Python 3.10 dll to be in the PATH in windows at least.

@jieyouxu
Copy link
Member

jieyouxu commented Sep 24, 2024

That feels worth documenting somewhere, considering how on my end that just shows up as LLVM hard-crashing and not as a wrong Python version. Like, maybe even worth having a virtualenv setup for the repo just to guarantee the right Python version is being used.

This is cc #125706, #126092 and #128392

@clarfonthey
Copy link
Contributor Author

You linked #128392 twice, which I assume is a mistake.

@jieyouxu
Copy link
Member

jieyouxu commented Sep 24, 2024

You linked #128392 twice, which I assume is a mistake.

I meant to link #126092 which is probably most relevant for your lldb(?) crash here, but I had both issues ending in 92 open at once and I got confused.

@clarfonthey
Copy link
Contributor Author

clarfonthey commented Sep 24, 2024

Yeah, I'm giving up on getting the debuginfo tests working. But I'll poke around to see if I can get the other tests to replicate their issues.

I would have to downgrade my system Python version, since the tests explicitly link /usr/bin/python instead of /usr/bin/env python.

@clarfonthey
Copy link
Contributor Author

It seems that even running the test suite via docker, I can't replicate the latest errors. Running ../x test --stage 2 inside the container either passes with no issues, or gives me an error about being unable to find ld

Looks like I've stumbled my way into the realm of cursed compiler testing issues that I don't know how to fix.

bors added a commit to rust-lang-ci/rust that referenced this pull request Dec 16, 2024
…e, r=<try>

Stabilize #[coverage] attribute

Closes rust-lang#84605, which passed FCP.

Stabilisation report here: rust-lang#84605 (comment)

Also added to reference here: rust-lang/reference#1628

---

try-job: aarch64-apple
try-job: x86_64-gnu
try-job: x86_64-msvc
@bors
Copy link
Contributor

bors commented Dec 16, 2024

⌛ Trying commit cccbaae with merge 95f4974...

@rust-log-analyzer

This comment has been minimized.

@bors
Copy link
Contributor

bors commented Dec 16, 2024

💔 Test failed - checks-actions

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 16, 2024
@clarfonthey
Copy link
Contributor Author

I guess I'll begrudgingly set up a test docker image and do it that way. Heading out soon but I can at least start the build now and let it run while I'm shopping, since it'll be quite a while.

@clarfonthey clarfonthey force-pushed the stable-coverage-attribute branch from cccbaae to cb487cc Compare December 17, 2024 02:07
@clarfonthey
Copy link
Contributor Author

Apparently, blessing the build.profiler = true tests just added an extra newline to the end of them. This appears to be the catastrophic failure that stopped CI from passing, since that was all I could find from running the tests, including after rebasing. I didn't run the aarch64 tests via qemu but I'm assuming that the architecture-specific stuff isn't failing… hopefully.

Maybe third time's the charm?

@Zalathar
Copy link
Contributor

@bors try

@bors delegate (for running more try jobs if necessary)

@bors
Copy link
Contributor

bors commented Dec 17, 2024

⌛ Trying commit cb487cc with merge 376a5b7...

bors added a commit to rust-lang-ci/rust that referenced this pull request Dec 17, 2024
…e, r=<try>

Stabilize #[coverage] attribute

Closes rust-lang#84605, which passed FCP.

Stabilisation report here: rust-lang#84605 (comment)

Also added to reference here: rust-lang/reference#1628

---

try-job: aarch64-apple
try-job: x86_64-gnu
try-job: x86_64-msvc
@bors
Copy link
Contributor

bors commented Dec 17, 2024

☀️ Try build successful - checks-actions
Build commit: 376a5b7 (376a5b74cb465afb8f4add257a150d3bea7ee398)

@clarfonthey
Copy link
Contributor Author

clarfonthey commented Dec 17, 2024

@bors r=@wesleywiser (does delegate let me do this?)

edit: fair enough

@bors
Copy link
Contributor

bors commented Dec 17, 2024

@clarfonthey: 🔑 Insufficient privileges: Not in reviewers

@jhpratt
Copy link
Member

jhpratt commented Dec 17, 2024

@bors delegate+

@bors
Copy link
Contributor

bors commented Dec 17, 2024

✌️ @clarfonthey, you can now approve this pull request!

If @jhpratt told you to "r=me" after making some further change, please make that change, then do @bors r=@jhpratt

@clarfonthey
Copy link
Contributor Author

@bors r=@wesleywiser

@bors
Copy link
Contributor

bors commented Dec 17, 2024

📌 Commit cb487cc has been approved by wesleywiser

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Dec 17, 2024
@bors
Copy link
Contributor

bors commented Dec 17, 2024

⌛ Testing commit cb487cc with merge 1d35638...

@bors
Copy link
Contributor

bors commented Dec 17, 2024

☀️ Test successful - checks-actions
Approved by: wesleywiser
Pushing 1d35638 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Dec 17, 2024
@bors bors merged commit 1d35638 into rust-lang:master Dec 17, 2024
7 checks passed
@rustbot rustbot added this to the 1.85.0 milestone Dec 17, 2024
@clarfonthey clarfonthey deleted the stable-coverage-attribute branch December 17, 2024 18:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-code-coverage Area: Source-based code coverage (-Cinstrument-coverage) merged-by-bors This PR was explicitly merged by bors. relnotes Marks issues that should be documented in the release notes of the next release. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Tracking issue for function attribute #[coverage]