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

Tracking issue for RFC 2383, "Lint Reasons RFC" #54503

Open
Centril opened this Issue Sep 23, 2018 · 2 comments

Comments

Projects
None yet
2 participants
@Centril
Contributor

Centril commented Sep 23, 2018

This is a tracking issue for the RFC "Lint Reasons RFC" (rust-lang/rfcs#2383).

Steps:

Unresolved questions:

  • The use sites of the reason parameter.
@zackmdavis

This comment has been minimized.

Show comment
Hide comment
@zackmdavis

zackmdavis Sep 24, 2018

Member

I started looking at this tonight. (Briefly; I regret that my time is limited.)

The example output in the RFC puts a reason: line immediately below the top-level error: line, but from a consilience-with-the-existing-implementation perspective, I'm inclined to think it would make more sense to use an ordinary note: (just as the existing "#[level(lint)] on by default" messages and must-use rationales do).

The reason should probably be stored as a third field inside of LintSource::Node.

Member

zackmdavis commented Sep 24, 2018

I started looking at this tonight. (Briefly; I regret that my time is limited.)

The example output in the RFC puts a reason: line immediately below the top-level error: line, but from a consilience-with-the-existing-implementation perspective, I'm inclined to think it would make more sense to use an ordinary note: (just as the existing "#[level(lint)] on by default" messages and must-use rationales do).

The reason should probably be stored as a third field inside of LintSource::Node.

zackmdavis added a commit to zackmdavis/rust that referenced this issue Sep 30, 2018

introducing lint reason annotations (RFC 2383)
This is just for the `reason =` name-value meta-item; the
`#[expect(lint)]` attribute also described in the RFC is a problem for
another day.

The place where we were directly calling `emit()` on a match block
(whose arms returned a mutable reference to a diagnostic-builder) was
admittedly cute, but no longer plausibly natural after adding the
if-let to the end of the `LintSource::Node` arm.

This regards rust-lang#54503.
@zackmdavis

This comment has been minimized.

Show comment
Hide comment
@zackmdavis

zackmdavis Sep 30, 2018

Member

PR for reason = is #54683.

Unresolved questions:

  • The use sites of the reason parameter.

@myrrlyn I'm not sure what "use sites" means in this context?

Member

zackmdavis commented Sep 30, 2018

PR for reason = is #54683.

Unresolved questions:

  • The use sites of the reason parameter.

@myrrlyn I'm not sure what "use sites" means in this context?

zackmdavis added a commit to zackmdavis/rust that referenced this issue Oct 12, 2018

introducing lint reason annotations (RFC 2383)
This is just for the `reason =` name-value meta-item; the
`#[expect(lint)]` attribute also described in the RFC is a problem for
another day.

The place where we were directly calling `emit()` on a match block
(whose arms returned a mutable reference to a diagnostic-builder) was
admittedly cute, but no longer plausibly natural after adding the
if-let to the end of the `LintSource::Node` arm.

This regards rust-lang#54503.

zackmdavis added a commit to zackmdavis/rust that referenced this issue Oct 15, 2018

introducing lint reason annotations (RFC 2383)
This is just for the `reason =` name-value meta-item; the
`#[expect(lint)]` attribute also described in the RFC is a problem for
another day.

The place where we were directly calling `emit()` on a match block
(whose arms returned a mutable reference to a diagnostic-builder) was
admittedly cute, but no longer plausibly natural after adding the
if-let to the end of the `LintSource::Node` arm.

This regards rust-lang#54503.

zackmdavis added a commit to zackmdavis/rust that referenced this issue Oct 16, 2018

introducing lint reason annotations (RFC 2383)
This is just for the `reason =` name-value meta-item; the
`#[expect(lint)]` attribute also described in the RFC is a problem for
another day.

The place where we were directly calling `emit()` on a match block
(whose arms returned a mutable reference to a diagnostic-builder) was
admittedly cute, but no longer plausibly natural after adding the
if-let to the end of the `LintSource::Node` arm.

This regards rust-lang#54503.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment