Resources Estimator throws InvalidOperationException when Q# contains no intrinsic gates

[ScottCarda-MS]

Describe the bug

When running the resources estimator on a Q# program that does not contain calls to intrinsically defined gates, an InvalidOperationException is thrown.

The error is being thrown from here: https://github.com/microsoft/qsharp-runtime/blob/main/src/Simulation/EntryPointDriver/Simulation.cs#L41
It is caused by there not being a "Microsoft.Quantum.QSharp.Core" assembly being referenced, so the LINQ First fails with this error.

To Reproduce

open Microsoft.Quantum.Canon;
open Microsoft.Quantum.Intrinsic;
@EntryPoint()
    operation Main () : Unit {
        Message("Hello World!");
}

Expected behavior

The resources estimator should run without error, producing a result that shows no resources are used.
Alternatively, a more appropriate error message could be thrown.

Actual behavior

Unhandled exception: System.InvalidOperationException: Sequence contains no elements
   at System.Linq.ThrowHelper.ThrowNoElementsException()
   at System.Linq.Enumerable.First[TSource](IEnumerable`1 source)
   at Microsoft.Quantum.EntryPointDriver.Simulation`3.Simulate(IEntryPoint entryPoint, TIn input, DriverSettings settings, String simulator) in C:\Repos\qsharp-runtime\src\Simulation\EntryPointDriver\Simulation.cs:line 37
   at System.CommandLine.Invocation.CommandHandler.GetResultCodeAsync(Object value, InvocationContext context)
   at System.CommandLine.Invocation.ModelBindingCommandHandler.InvokeAsync(InvocationContext context)
   at System.CommandLine.Invocation.InvocationPipeline.<>c__DisplayClass4_0.<<BuildInvocationChain>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<UseParseErrorReporting>b__20_0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass15_0.<<UseHelp>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass24_0.<<UseVersionOption>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass22_0.<<UseTypoCorrections>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<UseSuggestDirective>b__21_0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<UseParseDirective>b__19_0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<UseDebugDirective>b__11_0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<RegisterWithDotnetSuggest>b__10_0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass13_0.<<UseExceptionHandler>b__0>d.MoveNext()

System information

• OS: Windows 10

• .NET Core Version: .NET 5.0.103

• IQ# Version N/A

• Python Version (if applicable) N/A

Additional context
N/A

[bettinaheim]

Closely related but not entirely the same: #542.
@ScottCarda-MS Are you already looking into this one as part of adapting the entry point driver to process multiple entry points? Would you mind also taking a look at the related one I linked?

[ScottCarda-MS]

@bettinaheim I posted this as after a discussion with @swernli about this issue. Based on that I had thought this was an issue that @swernli would pick up when he had capacity, as it sounded, at the time, like he had some ideas on how to address this. @swernli can I assign this item to you?

[ScottCarda-MS]

@bettinaheim While this issue did surface during my work on the entry point driver, it doesn't seem to be related. In a conversation with @swernli, he showed me how to avoid the issue during my work on the entry point driver, but a genuine fix to the issue, as I remember him describing it, would take some refactoring and is outside the scope of my work with the entry point driver. I think @swernli would be a better assignee for this issue as he is more familiar with the code it touches and seemed to have an idea of what's needed to be done to genuinely fix the underlying issue, which may also fix #542, although I haven't looked into the code on that one.

[bettinaheim]

@ScottCarda-MS Capturing what we concluded in our offline chat: The root of the issue is indeed in a different place than I was suspecting based on the description. I'll hence unassign it for now, and then we will add it to our normal triage process.