Skip to content

Prevent leakage of warnings from configuration#52

Draft
patritzenfeld wants to merge 2 commits intomasterfrom
warning-leaks
Draft

Prevent leakage of warnings from configuration#52
patritzenfeld wants to merge 2 commits intomasterfrom
warning-leaks

Conversation

@patritzenfeld
Copy link
Copy Markdown
Member

closes #13

  • promote warnings to errors for sample solution tests
  • additionally enforce -Wall, this also indirectly covers -Wextended-warnings and therefore -Wx-partial

This should make sure the configs are warning free.

@jvoigtlaender this is a bit different from what you last suggested in #13, but I think it accomplishes the same goal. The config should fail on one of the interpreter runs respecting the config GHC options with -Wall if it would fail in one of the compiles ignoring the options. Do you see any problems with this approach?

@jvoigtlaender
Copy link
Copy Markdown
Member

Doesn't it prevent tail from being used in the sample solution? (Possibly my last proposal in #13 had the same property.)

I think we want the sample solution to be allowed to use tail (unless we explicitly say otherwise through configuration).

What we want to prevent is that the students get to see warnings about tail from the test code.

@jvoigtlaender
Copy link
Copy Markdown
Member

(Which could be achieved by making it so that the test suite is not allowed to use tail - and that being checked at config upload time via -Werror; but the problem being that this -Werror would then also apply to the sample solution unless this is somehow circumventable.)

@patritzenfeld
Copy link
Copy Markdown
Member Author

Would it be enough to always enforce the config rules for interpreter runs, thus changing those that are running with "default settings" (mentioned in #13 (comment)) to also use the config and not any additional warnings enabled by -Wall?

Or do you explicitly want -Wall to run on the config, but not the sample solution?

@jvoigtlaender
Copy link
Copy Markdown
Member

Yes, that would probably solve it. I didn't want -Wall. The issue was that students saw warnings arising from the test code, even ones that we didn't configure even for the students' code. Making sure that the test code does not contain any from the set of warnings active in some way at submission checking time (and making sure means to propagate them to errors at config checking time) should address that, and could involve actually changing what that set of warnings is.

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.

Leakage of warnings about supporting modules

2 participants