Timo
Timo
Now that we have an `Unrooted` API, one thing we could explore is using custom lints that check for how these are used. In particular, one issue that remains is...
The current opts that rely on type inference at compile time will also be unsound in presence of dynamic code execution (`eval`, `Function`), so we should try to move away...
I think you should be able to fix this by rebasing on master and then running `cargo dev update_lints`. There are probably some changes on the master branch that your...
I don't think you need to do that for every commit. I usually only rebase when conflicts happen or to squash commits when the PR is about to be merged...
It should probably warn on `0.max()` yes. One can just use the argument directly. `0.max(x + y)` is the same as `x + y` for unsigned integer types
The history here is a bit "convoluted", I tried cleaning it up a little bit by resolving my previous comments, but I don't know about @Centri3 's comments. Some of...
Sounds good, can you squash the commits? `r=me` with that done @bors delegate+
A fix for another issue that looked identical to this one (and what I assume is the same bug) should be on nightly now. There is no reproducer here so...
I'm not sure what the state of this PR is, it seems like it's not finished yet. The linked issue mentions that another PR fixed a very similar issue which...
It looks like the lint avoids visiting any nested expressions as soon as it finds code from an external macro (since it `return;`s and doesn't call `walk_expr`), which means that...