Wrong precedence pattern #4535
Labels
No Label
1. kind/balancing
1. kind/breaking
1. kind/bug
1. kind/construction
1. kind/documentation
1. kind/enhancement
1. kind/griefing
1. kind/invalid
1. kind/meme
1. kind/node limit
1. kind/other
1. kind/protocol
2. prio/controversial
2. prio/critical
2. prio/elevated
2. prio/good first issue
2. prio/interesting
2. prio/low
3. source/art
3. source/client
3. source/engine
3. source/ingame
3. source/integration
3. source/lag
3. source/license
3. source/mod upstream
3. source/unknown
3. source/website
4. step/approved
4. step/at work
4. step/blocked
4. step/discussion
4. step/help wanted
4. step/needs confirmation
4. step/partially fixed
4. step/question
4. step/ready to deploy
4. step/ready to QA test
4. step/want approval
5. result/cannot reproduce
5. result/duplicate
5. result/fixed
5. result/maybe
5. result/wontfix
ugh/petz
ugh/QA main
ugh/QA NOK
ugh/QA OK
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: your-land/bugtracker#4535
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Following #4418 more examples of potentially wrong precedences:
yikes, most of this is bad stuff. there's a couple of examples which aren't errors, nearly all of them from "i18n.py", where it's a discouraged pattern and not a logic error.
I've synced the mods and did a new grep. List above is now updated.
./yl_commons/features/interpolate_planting.lua:153: if offset.y ~= 0 and not xor(offset.x == 0, offset.z == 0) then
there's a logic error here, but it's that
and
should beor
(also,not xor
is equality, so that can be simplified). fixed inc4e4c89178
upstream PR against MTG https://github.com/minetest/minetest_game/pull/3032
fix for our beds fork:
0acbc17e30
upstream issue for worldedit additions https://github.com/sbrl/Minetest-WorldEditAdditions/issues/93
no PR cuz i'm not sure what the correct code is.
aerotest: false positive (the bad code is in a comment...)
canons: upstream PR https://bitbucket.org/fluxionary/minetest-cannons/pull-requests/1
PR for personal_log: https://github.com/minetest-mods/personal_log/pull/8
water_life PR: https://github.com/berengma/water_life/pull/92
think that's all the upstream issues. @AliasAlreadyTaken, do you want to take care of fixing the things in your code?
Yesh, I'll do that :D
If there are more bad patterns, please do tell.
We should maybe use a luacheck more often and not greenlight a mod or code that doesn't pass it.
i'm "religiously" using luacheck, stylua, and pre-commit to do basic linting on all my mods at this point. these things aren't a guarantee against bugs, but until we've got better minetest automated testing (i'm working on that too), they're the best option we've got.
Can you maybe write a short guide for the noobs like me how you use them?
Coz if a religion is gud, I'll gladly join.
i wrote a brief guide: https://gitea.your-land.de/your-land/bugtracker/wiki/luacheck%2C-stylua%2C-pre-commit
this was merged
supposedly fixed
Fixed in
72b6d1c92e
Fixed in
73d65894aa
Fixed in
eca833c82e
Fixed in
eccf499970
Fixed in
15a7a67c46
Fixed in
15a7a67c46
Fixed in
1431e8dc07
Fixed in
bb6c79c05e
@whosit Want to do us the honour and run it again?
cannons is fixed upstream (I get 404 on flux's link)(sorry, got confused)is it? apparently (1) my repo was private (2) i opened a PR against my own repo, not upstream. bitbucket confuses me.
new PR for cannons: https://bitbucket.org/kingarthursteam/cannons/pull-requests/1
Means, except cannons (which we most likely need to adopt) everything is fixed?
QA: After a brief look at a lot of code: yay! Most of the fixes will be delivered with 1.1.120, but let's hold off on closing it until the last one is done as well.
The upstream maintainer of cannons didn't show any reaction for more than 6 month, we'll most likely have to adopt the mod. In a fit of rage I fixed the issue in the cannons mod directly in the way suggested in the PR, so we can finally close this.
Since we already QA'ed all the other occurrences, this QA is successful if cannons can still be placed, fired and especially dug in various forms.
QA
Cannons and the digging part were tested by Parrish and found OK
assuming all this is live