Closed nberth closed 1 year ago
Merging #72 (d065cff) into gcos4gnucobol-3.x (5a1ed6f) will increase coverage by
0.01%
. The diff coverage is83.33%
.
@@ Coverage Diff @@
## gcos4gnucobol-3.x #72 +/- ##
=====================================================
+ Coverage 65.15% 65.16% +0.01%
=====================================================
Files 34 34
Lines 56063 56098 +35
Branches 14672 14678 +6
=====================================================
+ Hits 36529 36558 +29
- Misses 13654 13657 +3
- Partials 5880 5883 +3
Impacted Files | Coverage Δ | |
---|---|---|
cobc/tree.c | 73.21% <0.00%> (ø) |
|
cobc/cobc.c | 70.78% <50.00%> (-0.03%) |
:arrow_down: |
cobc/typeck.c | 65.06% <90.00%> (+0.10%) |
:arrow_up: |
cobc/flag.def | 100.00% <100.00%> (ø) |
|
libcob/common.c | 55.65% <0.00%> (-0.14%) |
:arrow_down: |
cobc/codegen.c | 74.55% <0.00%> (+0.06%) |
:arrow_up: |
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more
I'd say the main question is: should this not be applied in parser.y to base the alphanumeric_collation / default on it?
Or would you in general split file collating sequences (then we'd need a different name)?
And Changelog should likely reference the SF issue.
Now upstream.
@GitMensch I've had failures for the following two tests (not related to this PR):
Failures appear to be random; one of them also happened on https://ci.appveyor.com/project/GitMensch/gnucobol-3-x/builds/45653125/job/7h019vour18kj9mb
Thanks for the notice, I've just checked in the fix.
In the end this relies more on "alphabets" than "collating sequences", so I'm not sure yet whether the approach is appropriate, or if the option is properly named.