Open mdboom opened 2 years ago
@mdboom: I think a better approach would be to create sub-checklists or a single issue per file with another checklist for the paths that need coverage, instead of opening dozen of issues for each individual path.
Even having an issue per file will result in 548 new issues though, so I'm not sure if we want to do that preemptively for each file. I'd say it's better to keep the checklist with the files and paths here, and then directly create PRs for each (or multiple) paths.
Another option is to create a project, and handle it there. You can add a new custom field to specify the file, and create draft issues for each path without creating actual issues here (let me know if you need more help with that).
I think a better approach would be to create sub-checklists or a single issue per file with another checklist for the paths that need coverage, instead of opening dozen of issues for each individual path.
I thought about that, but most of the uncovered areas will have independent fixes, and bug-per-area sets up that work to happen.
I'm starting with files that have seen a lot of changes lately, so we're seeing quite a few issues in them. I suspect most files will not be that way -- most will probably have no issues, and we can just check the box here and not create a flood of issues where they aren't needed.
Even having an issue per file will result in 548 new issues though, so I'm not sure if we want to do that automatically for each file. I'd say it's better to keep this checklist here, and create PRs.
Agreed.
Another option is to create a project, and handle it there (let me know if you need help with that).
I'm happy to use a project instead if you'd prefer. IIUC, it's pretty easy to move the existing issues already created into it. I know I can't create a project, but once it's created, I don't know what my limited permissions will allow me to do.
Maybe it would be better to start by trimming down the list to remove files that have no issues, and see how many files are left first.
The remaining files and their paths could be listed here, and if someone starts working on them and wants to discuss the approach they could create the issues lazily or directly create PRs that refers to this meta issues if the fix is straightforward enough.
I don't think having lot of almost empty issues (like https://github.com/python/cpython/issues/94817) will help this effort.
Maybe it would be better to start by trimming down the list to remove files that have no issues, and see how many files are left first.
I programmatically removed files that have 100% coverage, and then also (manually) removed anything platform specific and all of Modules
(which can be handled easily in separate waves later -- they aren't a priority now). This gets us down to 136 tasks from 500+, which is a lot more manageable.
The remaining files and their paths could be listed here, and if someone starts working on them and wants to discuss the approach they could create the issues lazily or directly create PRs that refers to this meta issues if the fix is straightforward enough.
My thinking was this checklist was to say "someone has read through the file and identified all of the potential issues". Some of the issues will have simple tests that can be written, some are dead code, some might reveal bugs, but we need a place to have those discussions and deal with them individually (not here, ideally). For really simple ones, if it's ok to just reference this bug, that's fine by me, but we still need a way to keep track of which files have been vetted to track progress.
I don't think having lot of almost empty issues (like #94817) will help this effort.
Maybe not in general. The ones I've filed so far are directly tied to the faster CPython work, and the ability to move with more confidence there. So there are motivated people who want to close these bugs. But I empathize with the concern of just creating bugs for the sake of creating them.
This gets us down to 136 tasks from 500+, which is a lot more manageable.
This is much better, thanks for doing this!
My thinking was this checklist was to say "someone has read through the file and identified all of the potential issues".
My idea was to do something like:
Python/compile.c
Python/condvar.h
Python/context.c
Once people start working on these items, there are different options. They can:
The first two options work for straightforward cases, the third works if the problems are similar, and the last for more complex cases that require discussions. You can also do this incrementally, i.e. start with a list like the one above, then convert some to PRs and some to issues as needed.
In addition, if you hover with the mouse over a checklist item, a β¨ icon will appear to the right which will allow you to quickly convert the item to an actual issue if/when you decide to open a discussion about a specific file or problem.
So there are motivated people who want to close these bugs.
That's great to hear, I just wanted to avoid creating a bunch of issues that might end up sitting there indefinitely :)
Thanks. The revised plan you suggested should work just fine. I didn't know about the feature to automatically open an issue from a checklist item.
@pablogsal, should we be backporting these coverage-improving tests to 3.11? I think we should be consistent in our handling of all of them.
I don't think we usually backport test-only PRs, but perhaps these are sort of a special case.
Test only PRs are generally ok to backport π
When someone has "read through" a particular source file and added created subitems for any interesting gaps, they should check it off on the list below and add links to any issues created.
Hi, do you need some more eyes in checking coverage report? I just read Python Developer's Guide and I'm finding some issue with "easy" tag to fix ;)
i am not sure why i run ./python Lib/test/test_funcattrs.py
: test__builtins__
failed
@ofey404 wrote:
Hi, do you need some more eyes in checking coverage report? I just read Python Developer's Guide and I'm finding some issue with "easy" tag to fix
Yes. We could use help both finding coverage holes (by taking a file without a checkmark above and adding entries for anything not well-covered beneath it), or taking any of the holes and trying to write a test to cover it.
@fatelei wrote:
i am not sure why i run ./python Lib/test/test_funcattrs.py: testbuiltins failed
If you want to run a single test file, you should use:
./python -m test test_funcattrs
Hi @mdboom, I tried to improve the test coverage of PyObject_HasAttrString
. I'm new to the C API of Python and I hope that my PR can help you π
Working on gen_new_with_qualname and API PyGen_NewWithQualName and PyGen_New have no coverage
PR πͺ
Question from https://github.com/python/cpython/pull/98545
Do we care to cover deprecated API?
No, just like we donβt care to fix bugs in deprecated code (security excepted).
Thank you, https://github.com/python/cpython/pull/98545 is now closed.
@mdboom I have several pending PRs to get merged, and after that I propose to update the meta information / coverage data. There will be a lot of changes in coverage.
Plus, there are new changes to the source code.
What do you think? :)
@sobolevn could you request review from me on these PRs? I'll see if I can work through some of them.
WIP:
PySlice_GetIndices
/ PySlice_GetIndicesEx
Hi, I tried to improve coverage for Objects/dictobject.c with this PR:
BTW, it seems like _PyDict_GetItemHint (which is mentioned in the list) no longer exists.
The list is quite outdated :)
The checklist above says
PyNumber_Check
doesn't testcomplex
but Objects/abstract.c:905 currently has
return nb && (nb->nb_index || nb->nb_int || nb->nb_float || PyComplex_Check(o));
PyComplex_Check
itself seems well-developed in Objects/complexobject.c
.
Is this checklist item obsolete?
The checklist above says
PyMapping_HasKey
andPyMapping_HasKeyString
are untested
This appears not to be the case. The baseline coverage report linked in the bug description says they are uncovered, but that report is from 2022. I ran a full lcov
today and the functions do appear to be fully covered. as of commit 16c9415fba4 from August 2023. For example:
Lib/test/test_capi/test_abstract.py
lines 440β528 appear to test these functions extensively.
Is this checklist item obsolete?
Yes, it's quite possible the list is obsolete at this point.
Perhaps edit the comment:
If you like, I can check into the other Object/abstract.c
items and let you know if they can all be checked off.
I've added a warning about outdated. There is a PR for publishing automatic coverage reports here: https://github.com/python/cpython/pull/94760 @mdboom, do you need help pushing that forward?
@encukou: Yeah, I haven't really thought about #94760 in a while. It still seems like a worthwhile thing to do, but I'm not sure I will have time in the near future. Feel free to take it over if you are interested.
[edit by @encukou, May 2024] The coverage report and checklist are outdated. Run coverage locally before contributing.
This bug is going to be used to track work in a other bugs to improve the C-level coverage of the CPython test suite.
There is a set of
baseline coverage results on main[edit: outdated, see above] that can be used to find coverage gaps.The plan, discussed on discuss.python.org is as follows:
Related work:
There is related work to publish coverage results from CPython on a regular basis, but this issue is concerned with using those results to actually reduce our gaps in coverage.
List of source files:
Include/internal/pycore_asdl.h
Include/internal/pycore_bitutils.h
Include/internal/pycore_call.h
Include/internal/pycore_code.h
Include/internal/pycore_frame.h
Include/internal/pycore_moduleobject.h
Include/internal/pycore_object.h
Include/internal/pycore_pymath.h
Include/internal/pycore_pymem.h
Include/internal/pycore_pystate.h
Include/object.h
Include/pydtrace.h
Objects/abstract.c
PyBuffer_FromContiguous
,PyObject_CopyData
,PyBuffer_FillContiguousStrides
PyNumber_Check
doesn't testcomplex
PySequence_Repeat
andPySequence_InPlaceRepeat
have no coveragePySequence_SetItem
with a negative index is untestedPySequence_SetSlice
andPySequence_DelSlice
are untestedPyMapping_HasKey
andPyMapping_HasKeyString
are untestedObjects/accu.c
Objects/boolobject.c
Objects/bytearrayobject.c
Objects/bytes_methods.c
Objects/bytesobject.c
PyBytes_FromFormatV
, the special handling of%p
isn't tested.~ It's only the case where the underlying libc is broken that isn't tested.Objects/call.c
PyEval_CallObjectWithKeywords
has no coverage_PyObject_CallMethodId_SizeT
has no coverageObjects/capsule.c
Objects/cellobject.c
Objects/classobject.c
Objects/codeobject.c
Objects/complexobject.c
Objects/descrobject.c
Objects/dictobject.c
dictresize
convert split table into new combined table" is uncovered._PyDict_GetItemHint
has no coverageObjects/enumobject.c
Objects/exceptions.c
Objects/fileobject.c
PyFile_FromFd
has no coveragePyFile_GetLine
overbytes
input has no coverageObjects/floatobject.c
Objects/frameobject.c
Objects/funcobject.c
PyFunction_GetCode
,PyFunction_GetGlobals
,PyFunction_GetModule
,PyFunction_GetDefaults
,PyFunction_SetDefaults
,PyFunction_GetKwDefaults
,PyFunction_SetKwDefaults
,PyFunction_GetClosure
,PyFunction_SetClosure
,PyFunction_GetAnnotations
,PyFunction_SetAnnotations
\Objects/genericaliasobject.c
Objects/genobject.c
gen_new_with_qualname
and APIPyGen_NewWithQualName
andPyGen_New
have no coverage.PyCoro_New
has no coveragePyAsyncGen_New
has no coverageasync_gen_athrow_send
has poor coverageObjects/interpreteridobject.c
Objects/iterobject.c
Objects/listobject.c
Objects/longobject.c
_PyLong_Sing_t_Converter
has no coveragelong_format_binary
doesn't test outputting to UCS2 or UCS4int_bit_length_impl
andint_bit_count_impl
doesn't cover the case where expression overflowsObjects/memoryobject.c
init_slice
is not well-coveredObjects/methodobject.c
Objects/moduleobject.c
PyModule_GetFilename
has no coverageObjects/namespaceobject.c
Objects/object.c
PyObject_Print
has no coveragePyObject_Bytes
does not test the case where there is a__bytes__
PyObject_SetAttrString
doesn't test when object has atp_setattr
PyObject_GetAttrString
doesn't test when object has atp_getattr
_PyObject_LookupAttr
doesn't test when object has atp_getattr
Objects/obmalloc.c
Objects/odictobject.c
Objects/picklebufobject.c
PyPickleBuffer_FromObject
,PyPickleBuffer_Release
has no coverageObjects/rangeobject.c
Objects/setobject.c
Objects/sliceobject.c
PySlice_GetIndices
/PySlice_GetIndicesEx
has no coverageObjects/stringlib/codecs.h
Objects/stringlib/count.h
Objects/stringlib/ctype.h
Objects/stringlib/eq.h
Objects/stringlib/fastsearch.h
Objects/stringlib/find.h
Objects/stringlib/find_max_char.h
Objects/stringlib/join.h
Objects/stringlib/localeutil.h
Objects/stringlib/partition.h
Objects/stringlib/replace.h
Objects/stringlib/split.h
Objects/stringlib/transmogrify.h
Objects/stringlib/undef.h
Objects/stringlib/unicode_format.h
Objects/structseq.c
Objects/tupleobject.c
Objects/typeobject.c
wrap_sq_setitem
has no coverageObjects/unicodectype.c
Objects/unicodeobject.c
xmlcharrefreplace
doesn't test for codepoints < 100 (This seems almost impossible to occur).resize_inplace
has no coverageunicode_kind_name
when!PyUnicode_IS_COMPACT
isn't covered -- low priority used by consistency check onlyunicode_write_cstr
doesn't test writing into UCS2 or UCS4PyUnicode_AsDecodedObject
,PyUnicode_AsDecodedUnicode
,PyUnicode_AsEncodedObject
,PyUnicode_AsEncodedUnicode
has no coverage_Py_DecodeUTF8Ex
and_Py_EncodeUTF8Ex
has no coverage forerror == surrogateescape
PyUnicode_BuildEncodingMap
doesn't handle theneed_dict
caseucs1lib_find_slice
anducs1lib_rfind_slice
aren't covered.PyUnicode_Count
has no coveragePyUnicode_CompareWithASCIIString
has no coverage for comparing with UCS2 or UCS4_PyUnicode_EqualToASCIIId
has no coverageObjects/unicodetype_db.h
Objects/unionobject.c
Objects/weakrefobject.c
Parser/action_helpers.c
_PyPegen_set_expr_context
doesn't cover "starred kind"_PyPegen_get_expr_name
switch statement coverage is non-exhaustiveParser/myreadline.c
(N/A Windows-only)Parser/parser.c
Parser/peg_api.c
Parser/pegen.c
Parser/pegen.h
Parser/pegen_errors.c
Parser/string_parser.c
Parser/tokenizer.c
Python/Python-ast.c
~ Generated codePython/Python-tokenize.c
Python/_warnings.c
show_warning
doesn't cover the case where there is asourceline
.PyErr_WarnExplicit
has no coveragePython/asdl.c
Python/ast.c
ensure_literal_*
functions aren't coveredvalidate_pattern_match_value
doesn't cover all elements of switchPython/ast_opt.c
check_complexity
doesn't cover thefrozenset
caseast_foldbody
isn't coveredPython/ast_unparse.c
Python/bltinmodule.c
Python/bootstrap_hash.c
Python/ceval.c
PyEval_AquireLock
andPyEval_ReleaseLock
are uncoveredSTORE_ATTR_WITH_HINT
doesn't cover the case where the dictionary doesn't have Unicode keysCALL_FUNCTION_EX
doesn't cover the case where kwargs is not an exact dictPyEval_EvalCodeEx
doesn't cover the case where kwargs are passed inPyEval_GetFrame
has no coveragePython/ceval_gil.h
Python/codecs.c
Python/compile.c
Python/condvar.h
Python/context.c
PyContext_Copy
,PyContext_Enter
,PyContext_Exit
have no coveragePython/deepfreeze/deepfreeze.c
Python/dtoa.c
Python/dup2.c
Python/dynamic_annotations.c
Python/errors.c
Python/fileutils.c
is_valid_wide_char
doesn't test error branchesencode_ascii
/decode_ascii
has no coverage (probably very low priority -- comment says only for platforms with a broken mbstowcs (FreeBSD, OpenIndiana)_Py_stat
has no coveragePython/formatter_unicode.c
Python/frame.c
Python/frozenmain.c
Python/future.c
Python/getargs.c
Python/getopt.c
Python/hamt.c
Python/hashtable.c
Python/import.c
Python/importdl.c
Python/initconfig.c
Python/marshal.c
Python/modsupport.c
Python/mysnprintf.c
Python/mystrtoul.c
Python/pathconfig.c
Python/preconfig.c
Python/pyarena.c
Python/pyfpe.c
Python/pyhash.c
Python/pylifecycle.c
Python/pystate.c
Python/pystrcmp.c
Python/pystrhex.c
Python/pystrtod.c
Python/pythonrun.c
Python/pytime.c
Python/specialize.c
Python/structmember.c
Python/suggestions.c
Python/symtable.c
Python/sysmodule.c
Python/thread.c
Python/traceback.c
depth > limit
_PyTraceBack_Print_Indented
with overflowingtracebacklimit
_Py_DumpDecimal
,_Py_DumpHexadecimal
,_Py_DumpASCII
,dump_frame
,dump_traceback
,_Py_DumpTraceback
,write_thread_id
,_Py_DumpTracebackThreads
-- possibly they have tests which are disabled under some circumstances.