I think nil here is contextually Optional<Int>.none and force-unwrapping gives Int so it works.

cc @xedin @hborla

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