fix: validate marker names in -m expression with --strict-markers #14127

RonnyPfannschmidt · 2026-01-18T11:05:10Z

When --strict-markers is enabled, marker names used in -m expressions are now validated against registered markers.

Copilot

Pull request overview

This pull request implements validation of marker names in -m (marker expression) arguments when --strict-markers is enabled, addressing issue #2781. Previously, --strict-markers only validated markers used in test decorations (e.g., @pytest.mark.foo), but not markers referenced in command-line -m expressions.

Changes:

Added tracking of identifier names during expression parsing to capture marker names used in expressions
Implemented validation of marker names in -m expressions against registered markers when strict mode is enabled
Added comprehensive test coverage for the new validation behavior

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
src/_pytest/mark/expression.py	Modified Scanner, expression parser, and Expression class to track and expose identifier names used in expressions
src/_pytest/mark/init.py	Added `_validate_marker_names()` function to validate markers in expressions when strict_markers is enabled
testing/test_mark_expression.py	Added unit tests for the new `Expression.idents()` method
testing/test_mark.py	Added integration test verifying that unregistered markers in `-m` expressions trigger errors with --strict-markers
changelog/2781.feature.rst	Documented the new feature

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-01-18T11:09:28Z

testing/test_mark.py

+    pytester.makeini(
+        """
+        [pytest]
+        markers = registered: a registered marker
+        """
+    )


The makeini call here is redundant because it's immediately overwritten by another makeini call on lines 239-245 when option_name is "strict_markers" or "strict". This first ini file is never used. Consider removing these lines or restructuring the test to avoid creating the ini file twice.

bluetech

I debated with myself whether this is a good feature. It can help with bad typos, but maybe there's a use case for trying non-registered markers? But I couldn't think of any such use cases. So LGTM. Let's see if anyone complains...

Consider also mentioning this briefly in the strict_markers documentation.

bluetech · 2026-01-18T16:36:30Z

changelog/2781.feature.rst

@@ -0,0 +1 @@
+When ``--strict-markers`` is enabled, marker names used in ``-m`` expressions are now validated against registered markers.


Suggested change

When ``--strict-markers`` is enabled, marker names used in ``-m`` expressions are now validated against registered markers.

When :confval:`strict_markers` is enabled, marker names used in :option:`-m` expressions are now validated against registered markers.

bluetech · 2026-01-18T16:44:19Z

src/_pytest/mark/__init__.py

+
+    # Get registered markers from the ini configuration.
+    registered_markers: set[str] = set()
+    for line in config.getini("markers"):


We currently have this in 2 places (in _pytest.mark.pytest_cmdline_main and in MarkGenerator. If we are to follow the "rule of three", maybe can add a method to Config like

def _iter_registered_markers(self) -> Iterator[tuple[str, str]]

which yields (name, description) (I don't remember if the description is optional, if it is, would be tuple[str, str | None]).

bluetech · 2026-01-18T16:45:20Z

src/_pytest/mark/__init__.py

+    if not strict_markers:
+        return
+
+    # Get registered markers from the ini configuration.


Personally I don't find this comment adds much, but OK if it helps.

the commments are sometihng i need to retrain myself to note and remove

bluetech · 2026-01-18T16:45:24Z

src/_pytest/mark/__init__.py

+        marker = line.split(":")[0].split("(")[0].strip()
+        registered_markers.add(marker)
+
+    # Check each identifier in the expression.


Personally I don't find this comment adds much, but OK if it helps.

bluetech · 2026-01-18T16:45:57Z

src/_pytest/mark/expression.py

        return ret
    ident = s.accept(TokenType.IDENT)
    if ident:
+        # This is a marker/keyword name - track it.


Personally I don't find this comment adds much, but OK if it helps.

bluetech · 2026-01-18T16:47:16Z

src/_pytest/mark/expression.py

        #: The original input line, as a string.
        self.input: Final = input
        self._code: Final = code
+        #: The identifiers (marker/keyword names) used in the expression.


Expression is written to be "independent" of its uses, i.e. it doesn't "know" about markers or keywords. I would therefore remove the parenthetical here.

bluetech · 2026-01-18T16:48:56Z

src/_pytest/mark/expression.py

+        """Return the set of identifier names used in the expression.
+
+        For marker expressions (-m), these are marker names.
+        For keyword expressions (-k), these are keyword names.
+        """


Same here, I suggest dropping the mention of marker/keyword.

Suggested change

"""Return the set of identifier names used in the expression.

For marker expressions (-m), these are marker names.

For keyword expressions (-k), these are keyword names.

"""

"""Return the set of all identifiers which appear in the expression."""

Closes pytest-dev#2781 Co-authored-by: Cursor AI <ai@cursor.sh> Co-authored-by: Anthropic Claude Opus 4.5 <claude@anthropic.com>

Copilot AI review requested due to automatic review settings January 18, 2026 11:05

psf-chronographer bot added the bot:chronographer:provided (automation) changelog entry is part of PR label Jan 18, 2026

Copilot started reviewing on behalf of RonnyPfannschmidt January 18, 2026 11:05 View session

Copilot AI reviewed Jan 18, 2026

View reviewed changes

RonnyPfannschmidt force-pushed the fix-2781-strict-markers-m-expression branch from ec4ad16 to 20e1063 Compare January 18, 2026 11:23

bluetech approved these changes Jan 18, 2026

View reviewed changes

RonnyPfannschmidt force-pushed the fix-2781-strict-markers-m-expression branch from 20e1063 to 56688fb Compare January 19, 2026 10:17

fix: validate marker names in -m expression with --strict-markers

2192ac2

Closes pytest-dev#2781 Co-authored-by: Cursor AI <ai@cursor.sh> Co-authored-by: Anthropic Claude Opus 4.5 <claude@anthropic.com>

RonnyPfannschmidt force-pushed the fix-2781-strict-markers-m-expression branch from 56688fb to 2192ac2 Compare January 19, 2026 10:17

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

fix: validate marker names in -m expression with --strict-markers #14127

fix: validate marker names in -m expression with --strict-markers #14127

RonnyPfannschmidt commented Jan 18, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Jan 18, 2026

Uh oh!

bluetech left a comment

Uh oh!

bluetech Jan 18, 2026

Uh oh!

bluetech Jan 18, 2026

Uh oh!

bluetech Jan 18, 2026

Uh oh!

RonnyPfannschmidt Jan 18, 2026

Uh oh!

bluetech Jan 18, 2026

Uh oh!

bluetech Jan 18, 2026

Uh oh!

bluetech Jan 18, 2026

Uh oh!

bluetech Jan 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

		@@ -0,0 +1 @@
		When ``--strict-markers`` is enabled, marker names used in ``-m`` expressions are now validated against registered markers.

	When ``--strict-markers`` is enabled, marker names used in ``-m`` expressions are now validated against registered markers.
	When :confval:`strict_markers` is enabled, marker names used in :option:`-m` expressions are now validated against registered markers.

Uh oh!

fix: validate marker names in -m expression with --strict-markers #14127

Are you sure you want to change the base?

fix: validate marker names in -m expression with --strict-markers #14127

Conversation

RonnyPfannschmidt commented Jan 18, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Jan 18, 2026

Choose a reason for hiding this comment

Uh oh!

bluetech left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants