-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Ruby: Experimental model editor support #14679
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
Conversation
b71410b
to
a746ec9
Compare
Add experimental support for the CodeQL Model Editor.
For model editing purposes.
This allows the model editor to find this query in a more robust way than by file path.
Gemspecs are sometimes named via the first argument to `Gem::Specification.new`: ```rb Gem::Specification.new 'sinatra' do |s| # ... end ```
d67fecf
to
6a38223
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some minor questions, but looks good to me otherwise.
*/ | ||
|
||
// This query is empty as Application Mode is not yet supported for Ruby. | ||
from int n |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we really need this placeholder query? If it is necessary, perhaps make it select columns of the right names and types but still use none()
as the where clause. That should make it more clear what should be implemented if we ever support Application Mode.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, AFAIK the model editor expects this file to be present. I've updated it with more descriptive column names.
*/ | ||
bindingset[this] | ||
string getParameterTypes() { | ||
// For now, return the names of postional parameters. We don't always have type information, so we can't return type names. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// For now, return the names of postional parameters. We don't always have type information, so we can't return type names. | |
// For now, return the names of postional and keyword parameters. We don't always have type information, so we can't return type names. |
pragma[nomagic] | ||
predicate isNeutral() { | ||
none() | ||
// this instanceof FlowSummaryImpl::Public::NeutralCallable |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this comment be removed ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's sort of a hint (from the C# version) for what we should do here, but I'm happy to remove it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's fine.
or | ||
not this.isSupported() and result = "" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it necessary to use empty string as special value?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe so - if we don't return a value here then the rows will not show up in the query, and most endpoints will not be supported. If you're asking why we don't use a more descriptive value such as "not-supported"
- I don't know. But we should try to stay consistent with Java/C# as much as we can I think, and this is what they do.
exists(string type, string path, string method | | ||
method = path.regexpCapture("(Method\\[[^\\]]+\\]).*", 1) and | ||
Util::pathToMethod(this, type, method) and | ||
sinkModel(type, path, _) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be sourceModel
? Currently SinkCallable
and SourceCallable
are identical except for the extends
clause.
sinkModel(type, path, _) | |
sourceModel(type, path, _) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes! Thank you
Prototype support for working with Ruby models in the model editor.