sqlfluff: -- noqa ignored in multiline comment

Search before asking

  • I searched the issues and found no similar issues.

What Happened

I have a very long URL inside a multiline comment. I don’t want to trigger a rule failure, so I tried putting -- noqa: LT05 at the end of the line. But because we are already inside a multiline comment, the noqa declaration was ignored.

Expected Behaviour

There should be a way to specify noqa for comment lines. (See also #4881 which would be a better solution in this particular case.)

Observed Behaviour

sqlfluff lint outputs the following failure even when -- noqa: LT05 is appended to the long comment line:

L:   2 | P:   1 | LT05 | Line is too long (106 > 88).

How to reproduce

Run sqlfluff lint on the following SQL file:

/*
* https://example.com/1111111111111111111111111111111111111111111111111111111111111111111111 -- noqa: LT05
*/

Dialect

tsql

Version

sqlfluff, version 2.1.0 Python 3.10.10

Configuration

[sqlfluff]
dialect = tsql
max_line_length = 88

# ST06 reorders columns, which seems presumptuous
exclude_rules = ST06

[sqlfluff:indentation]
allow_implicit_indents = True

[sqlfluff:rules:references.special_chars]
allow_space_in_identifier = True
additional_allowed_characters = ['-/()?,']

Are you willing to work on and submit a PR to address the issue?

  • Yes I am willing to submit a PR!

Code of Conduct

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Comments: 15 (13 by maintainers)

Commits related to this issue

Most upvoted comments

When it starts a comment I think we can be more lenient. I think either should work 👍

@daviewales - I’m comfortable with the syntax suggestions you’ve made 👍 .

As for pointers:

  • The current parsing of noqa lines is done here . You’ll see that the method returns a NoQaDirective object on success containing the information about the command. At the moment the comment has to start with noqa after taking off any --.
  • The other issue is that the method above is effectively called from here. You’ll note that it’s only called for segments of type inline_comment. You’ll need to open that up to also cover segments of type block_comment to resolve this issue.

My expectation is that if you do both of those things, and handle any weird edge cases that arise as a result - you’ll be good 👍

I’m just waiting. It’s an open source project, so the maintainers are likely doing this in their own time.