MarkGenerator: Report unknown mark warning at caller level

[allanlewis]

Currently, PytestUnknownMarkWarning is reported at the level of MarkGenerator, which is unhelpful to callers as the warning is shown as being "caused" by pytest. This commit therefore increases the stack level passed to the warning call to 2, which will make the warning log as being "caused" by the caller, which is much more helpful.

• Target the master branch for bug fixes, documentation updates and trivial changes.
• Target the features branch for new features, improvements, and removals/deprecations.
• Include documentation when adding new features.
• Include new tests or update existing tests when applicable.

Unless your change is trivial or a small documentation fix (e.g., a typo or reword of a small section) please:

• Create a new changelog file in the changelog folder, with a name like <ISSUE NUMBER>.<TYPE>.rst. See changelog/README.rst for details.
• Add yourself to AUTHORS in alphabetical order;

Closes #5928.

[allanlewis]

Should I add a test for this?

[nicoddemus]

Hi @allanlewis, thanks a lot for this!

Yes, a test would be appreciated, thanks.

[blueyed]

Test might be nice, but for this kind of things it is often not tested already (and not trivial).
+0 for a test from me.

[nicoddemus]

Test might be nice, but for this kind of things it is often not tested already (and not trivial).

Indeed, but we should have tests for warning locations because those things can regress (a refactoring might change the call stack depth).

But @allanlewis let us know if you have trouble coming up with a test, we would be glad to help!

[blueyed]

Related: #4445

[allanlewis]

Rebased on master.
Is there anything else to do here, or are we just waiting for the tests from #5984?

[blueyed]

@allanlewis
Maybe pull it into #5984, so that it gets tested there actually?

[allanlewis]

@allanlewis
Maybe pull it into #5984, so that it gets tested there actually?

I don't think I have permissions to do that - @nicoddemus ?

[blueyed]

@xibalba01 could do it.

[blueyed]

Just for the record, hypothesis failed the build here again (osx):

=================================== FAILURES ===================================
______________________ TestMetafunc.test_idval_hypothesis ______________________
[gw0] darwin -- Python 3.7.0 /Users/travis/build/pytest-dev/pytest/.tox/py37-xdist/bin/python
self = <metafunc.TestMetafunc object at 0x1066d0400>
    @hypothesis.given(strategies.text() | strategies.binary())
>   @hypothesis.settings(
        deadline=400.0
    )  # very close to std deadline and CI boxes are not reliable in CPU power
    def test_idval_hypothesis(self, value):
E   hypothesis.errors.FailedHealthCheck: Data generation is extremely slow: Only produced 7 valid examples in 1.12 seconds (0 invalid ones and 2 exceeded maximum size). Try decreasing size of the data you're generating (with e.g.max_size or max_leaves parameters).
E   See https://hypothesis.readthedocs.io/en/latest/healthchecks.html for more information about this. If you want to disable just this health check, add HealthCheck.too_slow to the suppress_health_check settings for this test.
testing/python/metafunc.py:195: FailedHealthCheck
---------------------------------- Hypothesis ----------------------------------
You can add @seed(35364130883208350154606057602597663902) to this test or run pytest with --hypothesis-seed=35364130883208350154606057602597663902 to reproduce this failure.
=============================== warnings summary ===============================

[phloose]

@xibalba01 could do it.

Sure i can try! I would have to add @allanlewis's fork as remote, right?! Never did this kind of "merging" of pull requests :)

[blueyed]

Yes. with https://github.com/github/hub you can do hub remote add -p allanlewis, then git fetch it.
But works more manually of course, too. I can recommend using / looking at hub though in general.

[phloose]

Ok just did it manually. Will have a look at hub

[blueyed]

Closing in favor of #5984.
See #5984 (comment).
Thanks for having started on this!

[allanlewis]

Thanks, @blueyed - I'm happy to defer to #5984.