summaryrefslogtreecommitdiff
path: root/test/regress
Commit message (Collapse)AuthorAgeFilesLines
* Fix amount tokenizer re: embedded minus sign.Donald Lam2021-05-021-0/+12
| | | | | An amount may have a (single) leading minus sign, but none after that. Bug #2001 (and #1809).
* Don't use date format %FDaniel Coonce2021-02-021-1/+1
| | | | Date format %F is not available on all platforms.
* compare_by_commodity: Always return the result of the recursive callChristoph Dittmann2021-01-301-0/+14
| | | | | | | | | | | | | | | | | | | | | | | Commit 501fbc08ae5493db77bb34f4c4fbe1f3a3bc14e3 changed the behavior of this function to not return the "equal" result (==0) from the recursive call. Previously, the function returned the result of the recursive call unconditionally. The current behavior causes an assertion error for certain postings. The regression test added in this commit shows such a posting. I found through Travis CI that the old behavior was incomplete and caused unstable orderings, so reverting to the old behavior doesn't work. Instead, this change adds a fallback: If the recursive call that compares the prices numerically returns "equal", then compare the prices with their original commodity as a tie breaker. This commit does not change any existing ordering, it only adds deterministic ordering in a case that currently triggers an assertion error. This fixes issue #1998.
* Do not treat balance assignments with 0 diff as a null postingDaraul Harris2020-12-054-0/+112
| | | | | | | | | | | Ledger is treating balance assignments that have a 0 diff as having a null posting, leading to the posting being auto-balanced and therefore causing incorrect values to be returned for the transaction. I fixed this by just making the posting equal to amt - amt (0 in the right commodity). Fixes #1942
* Fix regression in sorted_amountsMartin Michlmayr2020-10-301-0/+17
| | | | | | | | | | Commit 557ab32 ("Expose a new utility function for balances: sorted_amounts") split out some code into a separate function. Unfortunately, in the process an "if" statement was dropped, leading to amounts being shown that shouldn't be shown because they are smaller than the display precision. Fixes #1969
* Add regression test for issue #1895Martin Michlmayr2020-05-181-0/+31
| | | | Thanks to Feiko Nanninga for the test case.
* Improve testcase for issue #1894 slightlyMartin Michlmayr2020-05-091-3/+8
|
* Add regression tests for issue #1894Rahix2020-05-092-0/+37
| | | | | | Add tests for wrong behavior caused by commit 49b07a1c1948 ("Correction to the way parens are parsed in query expressions") which was reverted with commit 869302ae9ce3. The bug report was issue #1894.
* Ensure that apply directives have an argumentMartin Michlmayr2020-04-271-0/+20
| | | | | | | | The directive `apply account` and similar directives (fixed, year...) require an argument. Ensure that an argument is given. Fixes #553 Fixes #1854
* fix: Fix #543 by tracking an account's real balanceDaraul2020-04-054-0/+104
| | | | | | | | | | | | | | Without these changes, whether an account's balance is virtual or real is not considered when asserting it's balance. This lead to situations where the user must consider their virtual postings when attemping to assert the real balance of the account. See test/regress/543_a.test for that testcase, taken from the original issue. This commit also includes other, fringe, situations that I noticed while working on the fix. It essentially just adds a separate attribute to the account class(?) that hold's the account's "real" balance, which is only updated when the user attempts an assertion on a real account. The virtual account's balance is updated the way it always was.
* Revert expected test time value to correct valueAndy Clayton2020-03-251-1/+1
| | | | | | This was changed to be specific to the author's local TZ in 139beba. With the test TZ override fixed, revert this back to the value that is correct across all environments (including travis).
* test: Unbreak one more test case with python3 bridgeDimitri John Ledkov2019-12-061-1/+1
| | | | | | | | | | | python3 has buffered output by default, hence testcase option_py returned no output when executed under test harness. I think this is a real problem in the way python interpreter is embeded, and i.e. stdout is not flushed until after test case has died. However, running things unbuffered seems to make everything work. But for some reason I had to adjust 1057.test slightly. I have no idea what those numbers mean, and if running things unbuffered break stuff.
* Make tests scripts Python 3 compatibleAlexis Hildebrandt2019-12-057-19/+35
|
* Format annotations using format that can be parsedOleg Bulatov2019-11-272-2/+2
| | | | | | | | | | | | | | | | | I expect an output of `ledger print` to be consumable by ledger. But on the next journal ``` 2019/11/25 * test Foo 1 AAPL {1.00 EUR} [2019/11/24] Bar ``` it prints [19-Nov-24], which it does not understand with default options. With this patch it prints [2019/11/24].
* Add support for '%F' date format specifierMichael Budde2019-04-021-0/+20
| | | | | | | | | '%F' is equivalent to '%Y-%m-%d'. Using the '%F' format without this change this would not give any hard errors but instead give dates with wrong years because the 'has_year' trait would not be correctly detected and thus parsed dates would get set to the current year. Fixes #1775
* Fix tag value parsingMichael Budde2019-03-301-0/+17
| | | | | | | | | | | | If a tag is more than 2 characters from the beginning of the comment the tag value offset will be wrong. #1702 gives an example where the tag line starts with `;;` and the tag value thus becomes `: Bar` because of this bug. The use `index` in the offset calulation seems to be a lucky coincidence that works in the common case: "; tag: value" Fixes #1702
* Reject postings with comment after flagMichael Budde2019-03-301-0/+12
| | | | Fixes #1753
* Fix possible stack overflow in option parsing routineMartin Michlmayr2019-01-261-0/+7
| | | | | | | | | | | | | | | It is possible to create a stack overflow by giving an option that is longer than the buffer that is used during option parsing because the length of the input string is not checked. Prevent the issue by always checking the input string length and discarding options that does not fit in the buffer as invalid. This issue has been assigned CVE-2017-12481. Thanks to Gwan Yeong Kim for reporting this issue. Fixes #1222
* Fix possible stack overflow in date parsing routineMichael Budde2019-01-261-0/+9
| | | | | | | | | | | | | | | It is possible to create a stack overflow by giving a date that is longer than the buffer that is used during date parsing because the length of the input string is not checked. The `VERIFY` macro is only enabled when debug-mode is enabled and the `--verify-memory` argument is used. Prevent the issue by always checking the input string length and discarding dates that does not fit in the buffer as invalid. This issue has been assigned CVE-2017-12482. Fixes #1224
* Merge pull request #1743 from scfc/move-garbage-dat-to-test-using-itJohn Wiegley2019-01-252-30/+823
|\ | | | | Move garbage-input.dat to test case using it
| * Move garbage-input.dat to test case using itTim Landscheidt2019-01-222-30/+823
| |
* | Ignore null deferred postingsMichael Budde2019-01-231-0/+5
|/ | | | | | | | | | | | | | | | | | All-null transactions (i.e. a transaction where all postings have a null amount) are discarded during parsing and the `xact` object is free'd. But if the transaction contains a deferred posting this results in a use-after-free vulnerability because a reference to the deferred posting is stored in the account object which is later read when deferred postings are applied after parsing is finished. Ignore null deferred postings to prevent this – they should not have any effect any way. Thanks to Cory Duplantis for reporting this issue and providing an initial analysis. Ref TALOS-2017-0304, CVE-2017-2808 Fixes #1723
* Fix parsing issue involving effective datesMartin Michlmayr2019-01-151-0/+12
| | | | | | | | | | | | | | | | | Cory Duplantis reported that "A specially crafted journal file can cause [an] integer underflow resulting in code execution". Cory provided this test case: Expenses:Food:Groceries $ 37.50 ; ] [=2004/01/01] Note the ] that comes before [ after the ;. This issue was reported and described in great detail by Cory Duplantis of Cisco Talos. This issue is known as TALOS-2017-0303 and has been assigned CVE-2017-2807. Cory's description can be found at https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0303 Fixes #1722
* Add test case for issue #1703Martin Michlmayr2019-01-121-0/+11
| | | | | Add a test case for issue #1703 which John Wiegley fixed in commit 56025cde ("Don't attempt to invert a value if it's already zero").
* Add the test to make sure it works in the future.Pascal Fleury2018-07-181-0/+36
|
* Remove TOK_A_YEAR tokenChristoph Dittmann2018-06-103-2/+30
| | | | | | | | | | | | | | | | This fixes #1626. The tokenizer eagerly classifies 4-digit integers as TOK_A_YEAR tokens. In some contexts such as "every 1000 years", this causes errors. I think the tokenizer does not have enough information available to distinguish between integers and years. After this patch, the tokenizer will always classify integers as TOK_INT tokens. The "has 4 digits" heuristic to determine if an integer is a year is moved to the place where it's actually needed (and it can be slightly more generic there, too).
* Make automated transactions work with assertionsChristoph Dittmann2018-06-091-0/+15
| | | | | | | | | | | | | | | This fixes issue #1127. In my understanding, PR #552 was meant to fix this, but was incomplete. Without this patch, automated transactions are invisible to assertions. This patch fixes this by adding a flag to the account to tell it that there is a new posting, analogous to the behavior of finalize(). I dug up issue #1127 too late to find that this is the same solution proposed by @tbm. Although I wrote this independently, credit goes to Martin Michlmayr (@tbm).
* budget_posts: Keep pending items until the last day they applysmr8942018-04-041-0/+79
|
* Fix handling of edge cases in trim functionMichael Budde2018-01-251-0/+33
| | | | Fixes #520
* Fix segfault when using --market with --group-byMichael Budde2018-01-041-0/+26
| | | | | | | | | | | `changed_value_posts::create_accounts()` reuses the `<Revalued>` account from `display_filter`, but when clearing `changed_value_posts` `create_accounts()` would be called before the account had been recreated by `display_filter_posts`. This results in a segfault when using the --group-by option. I'm not sure if `display_filter_posts` has the same problem but I reordered the calls there too for good measure.
* Merge pull request #494 from jjlee/fix-totalJohn Wiegley2017-10-262-0/+58
|\ | | | | Fix bug where .total used in value exprs breaks totals
| * Fix bug where .total used in value exprs breaks totalsJohn Lee2017-10-262-0/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Re-initialize (to VOID) totals for the account and its ancestors on adding postings. Otherwise the cache intended for use by recursive calls of C++ function total() in computing family (i.e. account hierarchy) totals is incorrectly retained from one top-level call to the next, causing inconsistent and broken behaviour. * Re-initialize (to false) calculated and gathered. Otherwise we won't e.g. recalculate stale totals for ancestor accounts (e.g. won't recalculate Assets:Savings total if Assets:Savings changes via a posting). Although the value expression total function is used by ledger itself in computing totals, this bug would only appear on use of .total in user-supplied value expressions computed *during parsing* of ledger files, rather than after parsing (I believe ledger only ever calls it for internal purposes after parsing is complete). It is possible this bug also affected other functions than total (perhaps even in circumstances other than analagous to that described in the preceding paragraph). I have not checked that.
* | Merge pull request #484 from mk12/bug-1182-ptrJohn Wiegley2017-10-262-0/+29
|\ \ | |/ |/| Fix Bug 1182: Error message for parse failure after '='
| * Print error message if parsing predicate after '='Mitchell Kember2016-12-202-0/+29
| |
* | Merge pull request #477 from thdox/bug-584-550thdox2017-01-161-0/+73
|\ \ | | | | | | Add regress test for bugs 550 and 584
| * | Add regress test for bugs 550 and 584thdox2017-01-051-0/+73
| |/
* | Merge pull request #476 from thdox/bug-1055thdox2017-01-161-0/+26
|\ \ | | | | | | Add regress test for bug 1055
| * | Add regress test for bug 1055thdox2017-01-051-0/+26
| |/
* / Add regress test for bug 1132thdox2017-01-051-0/+16
|/
* Don't explicitly reference test file in 1057.testJohn Wiegley2016-11-131-1/+1
|
* --force-color does not require anymore --color.thdox2016-10-271-1/+1
| | | | This was reported as Bug #1109
* Fix bug 1187: Allow balance assertions with multiple posts to same accountMitchell Kember2016-10-074-0/+105
|
* Fix regress test 383 on WindowsEvan Mallory2016-10-021-1/+1
| | | | %g is not available in Windows strftime. See documentation at https://msdn.microsoft.com/en-us/library/fe06s4ak.aspx
* Fix test harness to work with msys2Evan Mallory2016-09-231-1/+2
| | | | | | With this change, 97% of the tests pass. See the build on appveyor for more info: https://ci.appveyor.com/project/Evan/ledger/build/build-49 I'll follow up with another PR to fix some of the remaining broken tests
* Fix Bug 1147: Check balance assertions against the amount AFTERMitchell Kember2016-03-222-0/+22
|
* Merge pull request #449 from ppickfor/nextJohn Wiegley2016-03-141-0/+29
|\ | | | | Use interval start date (period from/since) to initialize first period.
| * Periods should be initialized from from/since clause rather than earliest ↵Peter Pickford2016-03-091-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | transaction date Bug 1159 Use interval start date (period from/since) to initialize first period. This allows the offset of a period start to be specified -p 'every 12 months from 2000-04-01' will have periods yyyy-04-01 to yyyy-03-31 .... If no from/since is specified for the period the first transaction date reported is used to initialize the period as before. added test case regress/1159.test
* | days - do not stabalize periods spacified in daysPeter Pickford2016-03-135-0/+532
|/ | | | | | | | weeks - calculate start date for finding period using remainer 400/periodlength to reduce number of iterations (perhaps this ought to follow the same conventio as years months and quarters) add sample period command tests add add day period tests for forecasts and budgets add week period tests for forecasts and budgets - these do not change
* Fix test suite failureMartin Michlmayr2016-02-161-1/+1
| | | | | I'm sure I used $FILE for the final version but I must have committed an old version.
* Increase maximum length for regexMartin Michlmayr2016-02-151-0/+28
| | | | Fixes bug #981
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-06 08:34:31 +0000