New compiler switches need to be threaded through the project system for intellisense builds #7812
Comments
jasonmalinowski
changed the title
jasonmalinowski
added a commit
to jasonmalinowski/roslyn
that referenced
this issue
Jan 7, 2016
Because dotnet#7812 is not yet fixed, the IDE doesn't know if we set the PublicSign flag. As a result, all design-time builds will thing we're real-signing, which causes semantics to get all screwed up. The workaround for now is, for design-time builds only, to pass the DelaySign flag since that's "good enough". Fixes GitHub issue dotnet#7790.
|
@jaredpar Can you confirm the list of flags I gave above is the full list that was added since 1.0? (note: since 1.0, not 1.1, since we missed some in 1.1 too) |
|
Your list has /feature. The error message I'm getting suggests it should be /features. Error CS8058 Feature 'pattern matching' is experimental and unsupported; use '/features:patterns' to enable. |
|
@jasonmalinowski that list looks correct to me. |
|
Are pathmap and pdb:portable emit-only settings? |
|
Yes. |
jasonmalinowski
added a commit
to jasonmalinowski/roslyn
that referenced
this issue
Feb 6, 2016
This adds support for a new ICompilerOptionsHostObject which is how we can pass options through the project system without having to manually add separate properties for everything as we've traditionally done in the past. To ensure compatibility with "new" compiler tasks against "old" project systems, and "new" project systems against "old" tasks, we continue to use the historical ICscHostObject* and IVbcHostObject* properties for all existing values, and only use this property to shuttle through new values. For the rest of Visual Studio 2015, we can just use this for any new "simple" switches that we must pass along. We still would need to do additional work in the project system for any inputs that are lists of files because of the fast-up-to-date check. Longer term, there is still the unanswered question of how we want to future versions of Visual Studio to get command line options to completely get rid of all language service knowledge of this. There are two possible approaches: 1. We just use the support added in dotnet#4604 and just delete this entirely. 2. We continue to use ICompilerOptionsHostObject. My proposal for that would be we continue to use the model of "we pass all options not supported by a strongly typed host object interface to ICompilerOptionsHostObject", and the project system would just remove all support for everything else and fail those QueryInterface calls. This is therefore written with the idea that we could switch to option 2 in a coordinated way, if we wanted to do so. Fixes dotnet#7812, assuming you have an updated csproj.dll and msvbprj.dll which understands the new ICompilerOptionsHostObject.
|
The internal parts are also checked in too. |
jasonmalinowski
added a commit
to jasonmalinowski/roslyn
that referenced
this issue
Jun 20, 2016
We're have required Update 2 for some time, making this unnecessary.
jasonmalinowski
added a commit
that referenced
this issue
Jun 23, 2016
…ound Remove workaround for lack of #7812
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Right now these flags are not being passed through to the IDE design time builds:
Issue #6945 is tracking the feature request of adding UI, but even if we do not do that, we must pass these flags through design time builds or all sorts of things don't work. Notably, lack of /publicsign breaks semantics like crazy, since it assumes the .snk has private keys. Lack of /pathmap would be observable if an ENC edit did something around CallerInfo. /feature is a blocker for anybody trying to build new features.
The text was updated successfully, but these errors were encountered: