108 lines
3.6 KiB
Markdown
108 lines
3.6 KiB
Markdown
|
# C# Language Design Notes for September 26, 2018
|
||
|
|
|
||
|
|
## Agenda
|
||
|
|
|
||
|
|
Warning waves
|
||
|
|
|
||
|
|
## Discussion
|
||
|
|
|
||
|
|
Motivation: Right now we consider adding a new warning to existing code to be
|
||
|
|
a breaking change. We want a way to add diagnostics without it being a
|
||
|
|
breaking change.
|
||
|
|
|
||
|
|
Solution: Some mechanism to opt-in to breaks ("warning waves").
|
||
|
|
|
||
|
|
For warning project levels, we consider "latest" to be the most common setting
|
||
|
|
aside from "none". Most people who want all possible warnings will target
|
||
|
|
"latest", and will only choose an earlier warning level number when the get
|
||
|
|
a new warning that they can't fix at the moment for some reason.
|
||
|
|
|
||
|
|
Negatives: Seemingly unrelated warnings are grouped into a bundle that may be
|
||
|
|
confusing. However, enabling individual warnings seems both a pain for users
|
||
|
|
to do every update, and very difficult for discovery (where do users find the
|
||
|
|
list of new warnings?)
|
||
|
|
|
||
|
|
When you haven't enabled the warning wave, we still want the diagnostics to
|
||
|
|
appear, but we want them to be suppressed such that the IDE and tooling can
|
||
|
|
see them, but the user does not (normally). Exactly what type of suppression
|
||
|
|
we use is to be solved.
|
||
|
|
|
||
|
|
### Q & A
|
||
|
|
|
||
|
|
One problem we'd like to address with warning waves is definite assignment
|
||
|
|
of structs with private members where, due to various compiler bugs, the
|
||
|
|
struct appears to be definitely assigned when it is not.
|
||
|
|
|
||
|
|
*Q: Definite assignment diagnostics are always errors right now -- should we allow "error waves" as well?*
|
||
|
|
|
||
|
|
**A:**
|
||
|
|
|
||
|
|
No, for now. Let's see if we can provide warnings for some of these issues
|
||
|
|
without producing errors.
|
||
|
|
|
||
|
|
*Q: Should warning waves be per-SyntaxTree or per-Compilation?*
|
||
|
|
|
||
|
|
**A:**
|
||
|
|
|
||
|
|
Per-Compilation for now. The SyntaxTree level may be an interesting feature
|
||
|
|
but there are no scenarios compelling enough right now that merit the
|
||
|
|
additional complexity.
|
||
|
|
|
||
|
|
*Q: Is the command line option case sensitive or case insensitive?*
|
||
|
|
|
||
|
|
**A:** Case-insensitive.
|
||
|
|
|
||
|
|
*Q: How does the IDE get access to info on the warning waves?*
|
||
|
|
|
||
|
|
**A:**
|
||
|
|
|
||
|
|
The compiler should provide an API to get a list of all warning IDs in a
|
||
|
|
particular wave. The IDE should also pull from the compiler resources to
|
||
|
|
find the description for each particular warning. The compiler also needs
|
||
|
|
to know which warning versions are valid. We also need an API for getting
|
||
|
|
which warning wave a particular warning is part of, if any. Warnings in
|
||
|
|
new language features are never part of a warning wave.
|
||
|
|
|
||
|
|
*Q: What's the bar for adding a warning to a warning wave? Is it the same
|
||
|
|
as whether or not we would have created a diagnostic if we were doing
|
||
|
|
the feature for the first time now?*
|
||
|
|
|
||
|
|
**Conclusion**
|
||
|
|
|
||
|
|
No. This will still cause users to do extra work, so we need to make sure
|
||
|
|
that each warning we're adding is worth the change. We should also consider
|
||
|
|
how much work will go into a particular warning wave and avoid overwhelming
|
||
|
|
the user. Based on feedback we can dial the severity back and forth.
|
||
|
|
|
||
|
|
However, we should introduce high-impact changes as soon as possible to make
|
||
|
|
it clear what kind of breaks users are signing up for.
|
||
|
|
|
||
|
|
*Q: Do we want a "major" flag for upgrading language version only with major
|
||
|
|
version?*
|
||
|
|
|
||
|
|
**Conclusion**
|
||
|
|
|
||
|
|
No.
|
||
|
|
|
||
|
|
*Q: Which warnings do we put in?*
|
||
|
|
|
||
|
|
**Conclusion**
|
||
|
|
|
||
|
|
Let's do prioritization later, but don't spend too much time deciding exactly
|
||
|
|
which one. In general, the system for adding warnings should go through LDM.
|
||
|
|
|
||
|
|
*Q: What are the version numbers?*
|
||
|
|
|
||
|
|
**Conclusion**
|
||
|
|
|
||
|
|
We aren't sure yet. "7.3.1"? "8.0.0"? Jared proposes Git SHA.
|
||
|
|
|
||
|
|
**Notes:**
|
||
|
|
|
||
|
|
1. `csc /warnversion:` with no warnversion could list all the possible
|
||
|
|
warning versions with all of the diagnostic ids in each warnversion and the
|
||
|
|
title of that warning.
|
||
|
|
|
||
|
|
2. No warning waves is `/warnversion:none`. All warnings is
|
||
|
|
`/warnversion:all`.
|