Comments (6)
(Ignore what I wrote, I forgot we had changed that bit of the code 😛
from humpty_dumpty.
The code in the fix-generics branch is an attempt at this. However, it still needs to error on stuff like drop
.
from humpty_dumpty.
\o/
from humpty_dumpty.
Actually there are several problems here:
- We wish to prohibit stuff like
let c = channel(); drop(c);
- We wish to be able to correctly track stuff in generic containers such as vectors.
- We wish to prohibit calling functions such as the above
dropit
with protected values.
1 and 3 are closely related of course, but the added problem of 1 is that, since drop
is in an external crate, we can't actually walk through it.
from humpty_dumpty.
After some discussion about this, I'm not sure we can currently handle 1 and 2 from above in an exhausstive manner. For example, consider the following function (defined in an external crate from the one humpty is currently checking):
fn foo<T>(v: Vec<T>) -> Vec<T> {
let mut new_v = Vec::new();
if let Some(x) = v.into_iter().last() {
new_v.push(x);
}
x
}
Since humpty can only access the meta-data for the function, ie. the argument types and the return type, we have no way of knowing whether or not it is safe to call with a protected value.
My current thinking is that we could simply warn on calls to external functions (that don't have allow_drop
), perhaps with the exception of calls to a specific list of functions that we white-list (vec.push, vec.pop comes to mind). Of course, we'd need to manually make sure that the white-listed functions are actually linear with respect to their arguments.
I still think that 3 from above can be addressed, but we'd probably have to invoke check_fn recursively (with some kind of state tracking to avoid overflow) with the type parameters instantialized to the protected types we call it with.
cc @laumann
from humpty_dumpty.
My current thinking is that we could simply warn on calls to external functions
This makes sense.
We can just change the ExprCall
/ExprMethodCall
handling to worry about situations where:
- The function is externally defined
- The function has no annotation
- One of the arguments has a protected type, found via
expr_ty
followed bywalk_ty
modulo whitelist
We wish to be able to correctly track stuff in generic containers such as vectors.
Note that we already do this. walk_ty
walks the type name (not the actual type fields), so Vec<Foo<Bar, Baz>>
would be walked as Vec<Foo<Bar, Baz>>
, Foo<Bar, Baz>
, Bar
, Baz
. This might just solve the problem in its entirety (assuming we fix the function issue above):
- If our type name is
Foo<NoDrop>
, i.e. hasNoDrop
somewhere within the type params,walk_ty
will find out and error. Easy peasy. - If our type name is
Foo
, and the containedNoDrop
is hardcoded in the definition ofFoo
(as opposed to a type param); sinceFoo
needs to be defined in a crate after (or the same crate as) the crate whichNoDrop
is defined in, it should be running the plugin too, and we can ensure thatdrop_protect
is propagated via a simple lint.
The only way to work around this is:
- Use a
type
alias to circumventwalk_ty
(type MyVec=Vec<NoDrop>
). This is easily caught by a lint. - Define a struct containing the protected type in a crate that doesn't run the plugin: We are assuming that all crates using the crate with drop protected variables will also run the plugin (not much we can do if people forget)
- Trait objects. Not entirely sure of this, but I think the creation of an owning trait object of a protected type can be caught by a lint. Or we can ignore it; this seems like an edge case.
from humpty_dumpty.
Related Issues (12)
- Add more tests
- Properly document what humpty_dumpty can and cant do HOT 1
- Remove "debug" output HOT 1
- Implement ExprWhile checking HOT 1
- handling of for loops doesn't correctly take breaks into account
- Handle closures HOT 10
- Introducing a protected value inside a loop does not always warn
- Incorrent handling of breaks inside match statements HOT 2
- Handle return statements HOT 3
- Handle break and continue statements in loops HOT 2
- Find a better way to test humpty HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from humpty_dumpty.