Skip to content

[DiagnosticsQol] Modify diagnostic macro into single DIAG #34488

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

Merged
merged 3 commits into from
Nov 2, 2020

Conversation

so5462
Copy link
Contributor

@so5462 so5462 commented Oct 29, 2020

This PR addresses SR-13774, which utilizes DefineDiagnosticMacros.h to shorten macro expansion (error, warning, note, remark) into DIAG.

Resolves SR-13774.

Copy link
Contributor

@HassanElDesouky HassanElDesouky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Welcome to the project! I think this PR will be ready to go after you modify storedDiagnosticInfos[].

cc @xedin, @owenv

@xedin xedin self-requested a review October 29, 2020 20:10
StoredDiagnosticInfo(DiagnosticKind::Note, DiagnosticOptions::Options),
#define REMARK(ID, Options, Text, Signature) \
StoredDiagnosticInfo(DiagnosticKind::Remark, DiagnosticOptions::Options),
#define DIAG(KIND, ID, Options, Text, Signature) \
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To shorten this definition we would need to capitalize all of the enum class DiagnosticKind values like the following:

enum class DiagnosticKind : uint8_t {
  ERROR,
  WARNING,
  REMARK,
  NOTE
};

@xedin WDYT?

Copy link
Contributor Author

@so5462 so5462 Oct 30, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which means, that this would require capitalization of these in other places as well right? I mean, wherever DiagnosticKind is referenced

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Naming style of the cases in enums has to stay consistent across repository. I think it's okay to just leave this as is.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@xedin makes sense, I'll revert the change that I made for this then, and this will be the only case, where it will be left as is.

@xedin
Copy link
Contributor

xedin commented Oct 30, 2020

@swift-ci please smoke test

Copy link
Contributor

@owenv owenv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@owenv
Copy link
Contributor

owenv commented Nov 1, 2020

@swift-ci please smoke test

@xedin
Copy link
Contributor

xedin commented Nov 2, 2020

@swift-ci please test Windows platform

@xedin
Copy link
Contributor

xedin commented Nov 2, 2020

Windows is failing due to CI issues, let's try one more time and if that land anyway.

@xedin
Copy link
Contributor

xedin commented Nov 2, 2020

@swift-ci please test Windows platform

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants