+ Adrian and Davide, since they work in this area. Hi Raj,
> On Jan 15, 2018, at 4:48 PM, Raj Barik via swift-dev <swift-dev@swift.org> > wrote: > > Thanks Mark. You are right, the following assertion fails > > require(!DS || DS->getParentFunction() == I->getFunction(), > "debug scope of instruction belongs to a different function"); > > I am not sure if we need such a check. This check exists to ensure that the debug info generated for a program is helpful. For example, a function with the wrong debug scope attached might make for confusing backtraces. vedant > > > On Mon, Jan 15, 2018 at 4:16 PM, Mark Lacey <mark.la...@apple.com > <mailto:mark.la...@apple.com>> wrote: > > >> On Jan 15, 2018, at 12:54 PM, Raj Barik <rkba...@gmail.com >> <mailto:rkba...@gmail.com>> wrote: >> >> Mark, >> >> Thanks a lot for quick reply. >> >> Is there any reason this interface in SILInstruction should be private? >> void setDebugScope(SILBuilder &B, const SILDebugScope *DS); >> >> In my case, I am splicing the old F into the new function NF. While splicing >> retains the debug scope, the new instruction (InitRef) that I am adding to >> NF is being created in some random scope (not F) even though I explicitly >> make Builder's debug scope point to F's. > > The assert you originally hit appears to indicate that the parentFunction of > the debug scope for an instruction should be the same as the function the > instruction is in. I am not very familiar with the requirements of our debug > information and debug scopes, but this seems like a reasonable expectation. > > I suggested looking at SILCloner because it is the primary way by which we > clone functions, and clearly has to deal with debug scopes when it does so. > > I’m not sure how much more help I can be on this matter, but perhaps someone > more knowledgable can chime in. > > Mark > > > > >> >> Best, >> Raj >> >> >> >> On Mon, Jan 15, 2018 at 9:52 AM, Mark Lacey <mark.la...@apple.com >> <mailto:mark.la...@apple.com>> wrote: >> I’d suggest looking at SILCloner.h as well as ScopeCloner in >> SILBasicBlock.cpp to see how they are dealing with debug scopes. >> >> Mark >> >> > On Jan 15, 2018, at 9:24 AM, Raj Barik via swift-dev <swift-dev@swift.org >> > <mailto:swift-dev@swift.org>> wrote: >> > >> > Hi, >> > >> > I am running into a debug scope SIL Verifier error when creating a new >> > function (NF) from an existing one (F). Can someone point me where I am >> > going wrong? >> > >> > NF = M.createFunction(...., F->getDebugScope()); >> > SILBasicBlock *NFBody = NF->createBasicBlock(); >> > SILBuilder NFBuilder(NFBody); >> > SILOpenedArchetypesTracker OpenedArchetypesTrackerNF(NF); >> > NFBuilder.setOpenedArchetypesTracker(&OpenedArchetypesTrackerNF); >> > NFBuilder.setCurrentDebugScope(NFBody->getParent()->getDebugScope()); >> > ... >> > for (auto ¶m : params) { /* Assume all are generic types */ >> > auto GenericsSILType = .... >> > auto NewArg = NFBody->createFunctionArgument(GenericSILType); >> > auto Conformances = Mod->lookupConformance(...); >> > auto *InitRef = NFBuilder.createInitExistentialRef( Loc, >> > ArgDesc.Arg->getType(), >> > NewArg->getType().getSwiftRValueType()->getCanonicalType(), NewArg, >> > Conformances); >> > ... >> > } >> > >> > The InitRef instruction created above runs into SIL verifier error: >> > >> > SIL verification failed: debug scope of instruction belongs to a different >> > function: !DS || DS->getParentFunction() == I->getFunction() >> > Verifying instruction: >> > %0 = argument of bb0 : $τ_0_0 // user: %1 >> > -> %1 = init_existential_ref %0 : $τ_0_0 : $τ_0_0, $SomeProtocol // >> > user: %2 >> > >> > The SIL looks correct to me though. >> > >> > --Raj >> > _______________________________________________ >> > swift-dev mailing list >> > swift-dev@swift.org <mailto:swift-dev@swift.org> >> > https://lists.swift.org/mailman/listinfo/swift-dev >> > <https://lists.swift.org/mailman/listinfo/swift-dev> >> >> > > > _______________________________________________ > swift-dev mailing list > swift-dev@swift.org > https://lists.swift.org/mailman/listinfo/swift-dev
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
