Skip to content
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

Add SemanticModel.WithoutAccessChecks() #378

Closed
gafter opened this issue Feb 10, 2015 · 1 comment · Fixed by #26
Closed

Add SemanticModel.WithoutAccessChecks() #378

gafter opened this issue Feb 10, 2015 · 1 comment · Fixed by #26
Labels
Area-Compilers Feature Request Language-C# Language-VB Resolution-Fixed The bug has been fixed and/or the requested behavior has been implemented Verified

Comments

@gafter
Copy link
Member

gafter commented Feb 10, 2015

From: Omer Raviv
Sent: Thursday, November 6, 2014 12:43 PM
Subject: RE: Roslyn issues

Hey Guys,

Thanks a lot for your help, Kevin.

Of the two issues, 1# is the most crucial to us and the one we just can't ship without, so we’d really appreciate any possible help you could give us!

If I understand correctly, what we're asking for here amount to:

  1. Add a public API on SemanticModel to request a new SemanticModel that ignores accessibility checks, something like SemanticModel.WithSuppressAccessibilityChecks.
  2. Change every line of code where a Binder is created with BindingOptions.SemanticModel (9 places by my count), so that it also includes BindingFlags.SuppressAccessibilityChecks if that's what the SemanticModel specifies.
  3. Change the line in Binder.IsSymbolAccessibleConditional that says throw ExceptionUtilities.Unreachable; to say return true;

I'm sure there are many API design considerations here that I'm not aware of, but this is really all we're asking. Without this, we can’t get out of Roslyn the behavior that OzCode inherently depends on, and we’re kind of stuck.

Thanks a lot!

  • Omer

From: Tomas Matousek
Sent: Thursday, November 6, 2014 09:45 PM
Subject: RE: Roslyn issues

I think we need the same features for our EEs and to support interactive.

Re #1: The current implementation of EEs heavily depends on internals of the compiler. I’d like us to use less internal APIs and more public APIs that customers like CodeValue, Xamarin and others could leverage as well.
Re #2: To support interactive we are going to need a metadata reference whose internals are imported. Seems like exactly what Pavel is asking for.

Not sure when this work will be done. We are currently stretched thin.

Tomas


From: Kevin Pilch-Bisson
Sent: Thursday, November 6, 2014 11:36 AM
Subject: RE: Roslyn issues

Hey Guys,

Chuck/Tomas – OzCode is a VS extension that adds a bunch of functionality to the debugging experience. They are looking at moving over to using Roslyn, but there are a couple of issues blocking them at the moment. I’m wondering if you have ideas for workarounds, or thoughts about how we do these things in our own EEs.

  1.   Avoiding access checks so that they can use `SemanticModel` to look at private/internal data at debug time.  They tried changing the implementation of `IsSymbolAccessibleConditional` to just return `true`, and that works for them, but they don’t want to fork Roslyn and build their own compilation models just to get this working.
    
  2.   They’d like to import internal metadata, but `CompilationOptions.WithMetadataImportOptions` is internal.  Even if it wasn’t, they would need some way to tell VS to use that, so that they could re-use our compilations.
    

Any ideas?

Kevin Pilch-Bisson
http://twitter.com/Pilchie

[issue ported from TFS DevDiv 1078951]

@gafter
Copy link
Member Author

gafter commented Feb 10, 2015

This may be of interest to @Pilchie @AnthonyDGreen

@gafter gafter added this to the 1.0-rc2 milestone Feb 10, 2015
@gafter gafter self-assigned this Feb 10, 2015
@gafter gafter added 4 - In Review A fix for the issue is submitted for review. and removed 3 - Working labels Feb 10, 2015
@gafter gafter removed the 4 - In Review A fix for the issue is submitted for review. label Feb 19, 2015
@gafter gafter added Verified Resolution-Fixed The bug has been fixed and/or the requested behavior has been implemented labels Mar 4, 2015
@jaredpar jaredpar removed this from the 1.0-rc2 milestone Nov 23, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Compilers Feature Request Language-C# Language-VB Resolution-Fixed The bug has been fixed and/or the requested behavior has been implemented Verified
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants