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
[SR-12309] Force unwrapping nil literal compiles without warning #54739
Comments
This could be implemented as a syntactic usage restriction pretty easily. There's even a utility in MiscDiagnostics for pulling this out. Retagging as a starter bug. Ping me here if you want more information. |
@swift-ci create |
Comment by Hassan ElDesouky (JIRA) @CodaFi Can you give me more information, please? |
Comment by Hassan ElDesouky (JIRA) @CodaFi I think it's already has been resolved because I'm trying to regenerate the issue and it's not compiling and giving me an error message as it should. However, when I looked into the recent PRs on Swift I didn't see a PR for this bug. |
This is about showing a warning at compile-time (on runtime this code crashes as expected) |
Comment by Hassan ElDesouky (JIRA) @theblixguy My Mac is still building the compiler, so I haven't tested anything yet. So, my approach to solving this problem is to create a new diagnostic message in DiagnosticsSema.def it will be something like: ERROR(cannot_unwrap_nil_literal,none,
"'nil' literal cannot be force unwrapped", ()) Then in the MiscDiagnostics.cpp file I will check to see if we are force unwrawppign a nil litreal around line number 248] /// Diagnose force unwrawpping a 'nil' literal
if (auto *nilLiteral = dyn_cast<ForceValueExpr>(E)) {
if (isTypeCheckedOptionalNil(E)) {
Ctx.Diags.diagnose(nilLiteral->getLoc(),
diag::cannot_unwrap_nil_literal);
}
}
Am I on the right track or I'm missing something? Thank you 🙂 |
hassaneldesouky (JIRA User) Thanks for your help with this! I think diagnosing it in MiscDiagnostics might be too late. I suggest you to add a new "warning" fix (you can find multiple examples for such fixes in CSFix.h, search for `/*isWarning=*/true`) and detect the problem while generating constraints (in CSGen.cpp there is `ConstraintGenerator` class which is responsible for constraint generation) and "fix" the problem right when it is encountered. I'd let you figure out how the problem manifests in AST, but here is a hint - https://github.com/apple/swift/blob/master/docs/DebuggingTheCompiler.rst#debugging-the-type-checker has some useful information about how to enable logging to see what type-checker does and AST it works with. |
Note that code like this `_ = nil!` currently type-checks and later crashes in SILGen but should be diagnosed as an error in type-checker. |
I think the fact that _ = nil! isn't diagnosed by the constraint system is a separate issue that we should fix by moving diagnosing a nil literal without contextual information from CSGen into the solver itself via fixes. Also a starter-worthy bug though in my opinion! |
Comment by Hassan ElDesouky (JIRA) PR: #30409 |
Comment by Hassan ElDesouky (JIRA) Successfully merged. |
Thank you for working on this, hassaneldesouky (JIRA User)! |
@glbrntt Please use next available nightly snapshot of master to verify and close. |
Verified against 2020-03-16 |
Attachment: Download
Additional Detail from JIRA
md5: 6955974a4e86043c16653d581b538542
Issue Description:
The following compiles without any warning/error, even though it's clearly nonsense:
Presumably the type checker thinks the
nil
is anInt?
being force-unwrapped. It would be neat to have a warning or error here.The text was updated successfully, but these errors were encountered: