Initial addition of CONSTANT SECTION by RamyGeorge · Pull Request #278 · OCamlPro/gnucobol

RamyGeorge · 2026-03-03T17:58:36Z

Summary

This pull request introduces the CONSTANT SECTION as defined for Fujitsu Language reference. Its intended purpose is to introduce VALUES that do not change during program execution. For now, It expects record description entries.

Changes

Addition of the grammar for CONSTANT SECTION
New Flag for COBC_HD_CONSTANT_SECTION

Motivation

Specific section for adding CONSTANT values while enforcing proper syntax

Tests

Test for the grammar is added at tests/testsuite.src/syn_definition.at
Test for MOVE with a CONSTANT is expected to fail for now

Please give any feedback and/or any changes required to fulfill current PR goal.

GitMensch

That's a good first take!
Please add cobc/Changelog to your changes as well-

please see https://sourceforge.net/p/gnucobol/wiki/Style%20guide/ for some general hints

The test currently fail (run make check and after the first one make check TESTSUITEFLAGS=--recheck --verbose locally to see them) because of

-prog.cob:6: error: Items in CONSTANT SECTION must have VALUE
+prog.cob:2: note: free format detected
+prog.cob:7: error: Items in CONSTANT SECTION must have  VALUE 
+prog.cob:7: warning: handling of CONSTANT SECTION code generation is unfinished; implementation is likely to be changed

for line two: start DIVISIONs and SECTIONs and paragraphs at column 8 and each "real" code at column 12; line 7 will be line 6 after the suggested change

GitMensch · 2026-03-03T18:45:53Z

+	if(f->storage == CB_STORAGE_CONSTANT){
+		if(!f->values){
+			cb_error(_("Items in CONSTANT SECTION must have  VALUE "));


formatting: see whitespace as used in other places (and drop the additional trailing spaces in line 3411, please)

msgid (that's hard to get right from the start, you only can get a clue how it might look like when checking the others) should possibly be "item in CONSTANT SECTION must have a VALUE clause" (again no trailing space)

GitMensch · 2026-03-03T18:46:54Z

 	}

+	if(f->storage == CB_STORAGE_CONSTANT){
+		if(!f->values){


I'd have to check the rules but it could be that for a record structure only part of it needs a VALUE clause - I really don't know (the Fuji manual should have the rules in).

GitMensch · 2026-03-03T18:50:03Z

 	COBC_HD_SCREEN_SECTION		= (1U << 17),
-	COBC_HD_PROCEDURE_DIVISION	= (1U << 18)
+	COBC_HD_PROCEDURE_DIVISION	= (1U << 18),
+	COBC_HD_CONSTANT_SECTION = (1U << 19) 


this should have the right order to be able to use > / >= operators;
per Fuji manual CONSTANT SECTION goes before LINKAGE (As you did with the parser later on

GitMensch · 2026-03-03T18:56:41Z

+
+| constant_section SECTION _dot
+  {
+	check_headers_present(COBC_HD_DATA_DIVISION,0,0,0); // check for Data division before hand


the comment is correct but superfluous here, note that per style guide: we only use C89 comment blocks (as GC still compiles on C89 compilers that don't have // inline commments)

GitMensch · 2026-03-03T19:07:15Z


+	if(f->storage == CB_STORAGE_CONSTANT){
+		if(!f->values){
+			cb_error(_("Items in CONSTANT SECTION must have  VALUE "));


you want cb_error_x (CB_TREE(f), .... here as the current line number is already after the field and you want its starting position

GitMensch · 2026-03-03T19:09:28Z

+			cb_error(_("Items in CONSTANT SECTION must have  VALUE "));
+		}
+
+		CB_UNFINISHED ("CONSTANT SECTION code generation");


that would come for every line (please add a second var, maybe a record without VALUE to the test to highlight it) - most easy solution would possibly be to add it on the program validation level if constant_section is non-NULL

The only place I did find such validation is cb_validate_program_data. I am not exactly sure where to put it within all the logic but i have added a check for cb_storage_constant at the end and called for CB_UNFINISHED)

yes similar, but instead of the constant you'd check the program's ->constant_storage (once it gets any addition, I don't think the constant section elements currently do get linked there, but into the previous storage).

GitMensch · 2026-03-03T19:09:36Z

 	cb_tree x;
 	const int level = cb_get_level ($1);
-
+	


trim trailing whitespace

GitMensch · 2026-03-03T19:09:46Z

+
+AT_CHECK([$COMPILE_ONLY prog.cob], [1], [],[prog.cob:6: error: Items in CONSTANT SECTION must have VALUE
+])
+AT_CLEANUP


that wants a line break at the end; please also have a look at how the other tests are formatted (only slightly different)

GitMensch · 2026-03-03T19:17:57Z

follow-up additions after the mentioned issues:

have a test that MOVEs a constant to a field, then DISPLAYs that field
have a look how level 78 constants define their constness in their definition - using the same or similar may solve the MOVE TO CONSTANT issue
optional: in codegen possibly use the constant prefix (which is used for fields built from literals) instead of the field one
ideally: in codegen generate the data in the same way the constant data (which is used for string literals) is setup
follow-on:
- add a new scope "CO" to -fdump option that handles the elements in the constant_storage, along with a test
- internally set all level 78 constants and 01 cosntants defined in any storage into the constant_storage (so they will dump as well)

GitMensch

mostly testing issues in this review iteration;

please have a look at the already specified changes to -fdump and add a new test to listings.at with -ftsymbol (just edit an existing test and add a CONSTANT SECTION into it, then see if the symbol listing includes those or not

GitMensch · 2026-03-06T12:06:57Z

+       CONSTANT SECTION.
+       01  NUM-CONST   PIC 9(3).
+       01  OTHER-CONST PIC 9(3) VALUE 123.
+       PROCEDURE DIVISION.


please add a third constant with a constant record

That comment of mine was misleading - I did not meant "a CONSTANT RECORD" but "a record that is a constant"; the check where CONSTANT RECORD is possible to use is to be done in its syntax test.

drop CONSTANT RECORD.
Add new test for CONSTANT RECORD ON WORKING/LOCAL STORAGE

GitMensch · 2026-03-06T12:09:43Z

+           STOP RUN.
+])
+
+AT_CHECK([$COMPILE prog.cob], [1], [],[ignore])


you may add -Wno-unfinished to the command line - please add the expected error into stderr instead of ignore (see tests above how to split the AT_CHECK into multiple lines for that

GitMensch · 2026-03-06T12:14:33Z

+AT_SETUP([MOVE CONSTANT SECTION to field])
+AT_KEYWORDS([extension constant move])
+
+AT_XFAIL_IF([true]) 
+
+AT_DATA([prog.cob],[
+       IDENTIFICATION DIVISION.
+       PROGRAM-ID. prog.
+       DATA DIVISION.
+       CONSTANT SECTION.
+       01  MY-CONST    PIC 9(3) VALUE 123.
+       WORKING-STORAGE SECTION.
+       01  RESULT-FLD  PIC 9(3).
+       PROCEDURE DIVISION.
+           MOVE MY-CONST TO RESULT-FLD.
+           DISPLAY RESULT-FLD.
+           STOP RUN.
+])
+# This is also not implemented yet but should help towards the bigger issue with CONSTANTs being replaced by literals
+AT_CHECK([$COMPILE prog.cob], [0], [], [])
+AT_CLEANUP


this test should be moved to run_extensions (with -Wno-unfinished in the compilation) and should include testing the actual result (which I guess will be fine);
please add another runtime test into run_extensions.at that has an alphanumeric constant and uses refererence modification [substring], like MOVE MY-CONST (2:2) TO RESULT-FLD. - I guess that will currently fail during compile.

please move that test before the new constant with refmod test to run_extensions and check the result as well (without an expected failure)

GitMensch · 2026-03-06T12:16:57Z

 	switch (storage) {
 	case CB_STORAGE_CONSTANT:
-		return "Constants";
+		return "CONSTANT SECTION";


Constants may should be lower-cased (not sure), but CONSTANT SECTION is wrong here as other constants have the same storage but are not "living" in that section

still applies

RamyGeorge · 2026-03-14T00:18:07Z

+])
+
+AT_CHECK([$COMPILE -Wno-unfinished prog.cob], [0], [], [])
+AT_CHECK([./prog], [0], [BC],[])


This is one of the weird suggestions i had from an agent?
it suddenly passed when adding this but i have since removed it and still worked so i guess there was a hallucination?! (which is to be expected it is basically the same test from syn_move.at)

That should pass without a problem (ref-mod of level 78 constant currently can't work [I need to check if that should be allowed, not sure] and most likely not of 01 CONSTANT AS [which likely should be allowed, also needs to be checked]), so please drop that expected failure (which then shows the result in the CI as well.

RamyGeorge · 2026-03-14T00:18:54Z

+AT_KEYWORDS([extension constant VALUE])
+
+#THis fails because codegen is not implemented yet
+AT_XFAIL_IF([true])


This also fails so i marked with XFAIL since codegen is not implemented

GitMensch

let's have a look at the actual result by not suppressing the testsuite results and add CONSTANT RECORD and NULLABLE clause as well;
As this PR adds user-visible functionality (extension CONSTANT SECTION and CONSTANT RECORD support + dump + smybol listing for those) there should be 2 entries in the NEWS file as well.

GitMensch · 2026-03-14T11:55:48Z

+])
+
+AT_CHECK([$COMPILE -Wno-unfinished prog.cob], [0], [], [])
+AT_CHECK([./prog], [0], [BC],[])


That should pass without a problem (ref-mod of level 78 constant currently can't work [I need to check if that should be allowed, not sure] and most likely not of 01 CONSTANT AS [which likely should be allowed, also needs to be checked]), so please drop that expected failure (which then shows the result in the CI as well.

GitMensch · 2026-03-14T11:56:36Z

+])
+
+AT_CHECK([$COMPILE -Wno-unfinished prog.cob], [0], [], [])
+AT_CHECK([./prog], [0], [BC],[])


This line should be replaced by AT_CHECK([$COBCRUN_DIRECT ./prog], [0], [BC])

GitMensch · 2026-03-14T11:57:02Z

+           STOP RUN.
+
+
+


drop empty lines

GitMensch · 2026-03-14T11:58:23Z

+AT_SETUP([CONSTANT SECTION syntax enforced value])
+AT_KEYWORDS([extension constant VALUE])
+
+#THis fails because codegen is not implemented yet


this should still work in codegen, remove the expected failure and we see where the issue is
I'd expect the return code to be 0, not 1 as it is only a warning.

GitMensch · 2026-03-14T12:01:46Z

       CONSTANT SECTION.
       01  NUM-CONST   PIC 9(3).
       01  OTHER-CONST PIC 9(3) VALUE 123.
+       01  THIRD-CONST CONSTANT RECORD.


The CONSTANT RECORD case should be moved to the WORKING-STORAGE and instead add another item here bad-record CONSTANT RECORD that expects a compile-time error (see iso draft for the rules):

The CONSTANT RECORD clause may be specified only in the local-storage or working-storage [...].

please split the test - CONSTANT RECORD (which doesn't even need a VALUE at all) is not an extension, same for 01 CONSTANT AS

GitMensch · 2026-03-14T12:02:58Z


-AT_CHECK([$COMPILE prog.cob], [1], [],[ignore])
+AT_CHECK([$COMPILE -Wno-unfinished prog.cob], [1], [],
+[ignore


we don't ignore the output - we actually want to see an error here; for the time being please also drop the expected failure, allowing us to see what does not yet work

GitMensch · 2026-03-14T12:04:14Z

+AT_SETUP([MOVE CONSTANT SECTION to field])
+AT_KEYWORDS([extension constant move])
+
+AT_XFAIL_IF([true]) 
+
+AT_DATA([prog.cob],[
+       IDENTIFICATION DIVISION.
+       PROGRAM-ID. prog.
+       DATA DIVISION.
+       CONSTANT SECTION.
+       01  MY-CONST    PIC 9(3) VALUE 123.
+       WORKING-STORAGE SECTION.
+       01  RESULT-FLD  PIC 9(3).
+       PROCEDURE DIVISION.
+           MOVE MY-CONST TO RESULT-FLD.
+           DISPLAY RESULT-FLD.
+           STOP RUN.
+])
+# This is also not implemented yet but should help towards the bigger issue with CONSTANTs being replaced by literals
+AT_CHECK([$COMPILE prog.cob], [0], [], [])
+AT_CLEANUP


please move that test before the new constant with refmod test to run_extensions and check the result as well (without an expected failure)

GitMensch · 2026-03-14T12:11:11Z

+        if (!f->values) {
+            cb_error_x (CB_TREE(f),("item in CONSTANT SECTION must have a VALUE clause"));
+        }
+	}


As the else branch we want to "internally move" standard-constant (CONSTANT RECORD and CONSTANT AS) into that storage, to use the "normal" code generation we'd have for WORKING-STORAGE - and to find them in the dump and symbol listing there.

only flag i found for constant is f->flag_constant
I am assuming this is it and i am also assuming I'll have to get CONSTANT RECORD to have this flag aswell ?

only flag i found for constant is f->flag_constant

There is unsigned int flag_constant : 1; /* Is 01 AS CONSTANT */ in tree.h; that is also in one case to skip something (I haven't checked the details)

I am assuming this is it and i am also assuming I'll have to get CONSTANT RECORD to have this flag aswell ?

Setting it would be reasonable, when doing that the comment needs to be adjusted to /* Is 01 AS CONSTANT / CONSTANT RECORD (depending on ->children) */ or similar and add the check for the child at the place where currently something is skipped (if it should not apply to CONSTANT RECORD).

working on both the NULLABLE and CONSTANT RECORD right now
is there a SYN_CLAUSE for CONSTANT RECORD clause right now or do i add a new one? (no comments on which is which)

that sounds like an understanding issue of our bison use - let's make a 10 minute session out of that ;-)

GitMensch · 2026-03-14T13:06:17Z

+		if (cb_flag_dump & COB_DUMP_CO) {
+			if (has_field_to_dump(prog->constant_storage)) {
+				has_dump = 1;
+				output_line ("/* Dump CONSTANT SECTION */");


The comment should say "Dump constants", also below - as this will also apply to the 01 CONSTANT AS, 01 CONSTANT RECORD and 78-constants.

This still applies.

GitMensch · 2026-03-14T21:03:19Z

+| NULLABLE
+  {
+	CB_UNSUPPORTED("NULLABLE");
+  }  


make a new "nullable_clause" out of that - this also allows to do checks within that

GitMensch · 2026-03-14T21:05:53Z

 		}
 	}
  }
+| level_number user_entry_name CONSTANT RECORD


CONSTANT RECORD will be a "normal" clause, same as nullable_clause and also used at the same place; you can then use current_field->level or similar to do the check

GitMensch · 2026-03-15T14:14:16Z

+	if (prog->constant_storage) {
+		CB_UNFINISHED ("CONSTANT SECTION code generation");
+	}
 }


let's move that to the parser

still applies

GitMensch · 2026-03-15T14:15:22Z

+           STOP RUN.
+])
+
+AT_CHECK([$COMPILE -Wunfinished prog.cob], [0], [], 


just use AT_CHECK([$COMPILE -Wno-unfinished prog.cob], [0], [], []) here (it is a runtime check so we don't care about the warning) - and add the missing AT_CHECK([$COBCRUN_DIRECT ./prog], [0], [123])

still applies

GitMensch · 2026-03-15T14:41:55Z

+# Expected to fail until reference modification is 
+# fully implemented for CONSTANT literals.
+AT_XFAIL_IF([true]) 


as noted before: that should already be fully supported

RamyGeorge · 2026-03-20T11:57:50Z


 %token LEVEL_NUMBER_IN_AREA_A	"level-number (Area A)"
 %token WORD_IN_AREA_A		"Identifier (Area A)"
+%token CONSTANT_RECORD


Putting this token definition in it lexcographical position broke the whole think
it particularly lead to a "by 1 off" with reserved c

token WORDS comes before WORKING-STORAGE

declaring WORKING-STORAGE returns the WORDS token

Adding a token adjusts parser.h, if you get an off-by one that likely means some timestamps are screwed.
Try make -C build/cobc clean && touch cobc/parser.y && make -C build/cobc to ensure that this isn't a problem.

Also: your latest push nearly passes all CI (where everything is build from scratch).

just a clarification on "would display strange"

PS: running make -C build/cobc clean && touch cobc/parser.y && make -C build/cobc

didn't fix the make compiling still explodes with examples like

missing program-id even though it is there?

just a clarification on "would display strange"

Whenever bison refers the tokens, for example in "expected TOKEN got TOKEN" it uses the token name.
The default is the string version of the enum value of the token "as-is".
This may lead to "Expected CONSTANT got CONSTANT_RECORD"; if you explicit define a name - here "CONSTANT RECORD" it will show that way.

Guess: you have parser.h in cobc and in build/cobc as you've executed bison in the source directory manually.
Am I right? (that guess may be related to me doing that in the past as well...)

GitMensch

a bunch of older items are still open + some new - but overall there's visible progress 👍

GitMensch · 2026-03-20T12:31:49Z

the changes in this file miss an update to listings.at, verifying it to work as expected

GitMensch · 2026-03-20T12:35:24Z

+#define COB_DUMP_CO 0x0020  /* CONSTANT SECTION*/
+#define COB_DUMP_LS	0x0040  /* LINKAGE SECTION */
+#define COB_DUMP_LO	0x0080  /* LOCAL-STORAGE SECTION */
+#define COB_DUMP_ALL	(COB_DUMP_FD|COB_DUMP_WS|COB_DUMP_RD|COB_DUMP_SD|COB_DUMP_SC|COB_DUMP_CO|COB_DUMP_LS|COB_DUMP_LO)


As this changes -fdump and -fdump=allit needs an entry in the NEWS under the cobc options. We could also think of changing the default (= if none is given) to "most" or similar, or - which is _possibly_ the right thing to do say that "ALL" dumps all storage, the constants are only dumped if explicit requested, for example with-fdump=all,co` (in this case the COB_DUMP_ALL definition would stay as is).

In any case the behaviour should be clear in the NEWS entry and it should be visible in a test case as well.

GitMensch · 2026-03-20T12:35:40Z

+		if (cb_flag_dump & COB_DUMP_CO) {
+			if (has_field_to_dump(prog->constant_storage)) {
+				has_dump = 1;
+				output_line ("/* Dump CONSTANT SECTION */");


This still applies.

GitMensch · 2026-03-20T12:46:48Z

+       01  NUM-CONST   PIC 9(3) VALUE 444.
+       01  OTHER-CONST PIC 9(3) VALUE 123.


this test does not check what its title says

This means to test for the enforced VALUE caluse
in hindsight the one after with just the syntax has one entry with value and one without so i can possible just erase this

drop a value
expect error for invalid constant section syntax

GitMensch · 2026-03-20T12:49:15Z

+       CONSTANT SECTION.
+       01  NUM-CONST   PIC 9(3).
+       01  OTHER-CONST PIC 9(3) VALUE 123.
+       PROCEDURE DIVISION.


That comment of mine was misleading - I did not meant "a CONSTANT RECORD" but "a record that is a constant"; the check where CONSTANT RECORD is possible to use is to be done in its syntax test.

GitMensch · 2026-03-20T12:50:57Z

+AT_CHECK([$COMPILE -Wunfinished prog.cob], [1], [],
+[prog.cob:7: warning: handling of CONSTANT SECTION code generation is unfinished; implementation is likely to be changed


similar as to above: we don't care about the unfinished here, so you can use -Wno-unfinished for the compile

GitMensch · 2026-03-20T12:51:55Z

+
+AT_CHECK([$COMPILE -Wunfinished prog.cob], [1], [],
+[prog.cob:7: warning: handling of CONSTANT SECTION code generation is unfinished; implementation is likely to be changed
+prog.cob:8: error: invalid MOVE target: 123


you may make that an expected failure and change the expected output to invalid MOVE target: constant NUM-CONST.

codecov-commenter · 2026-03-21T14:25:12Z

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

❌ Patch coverage is 34.00000% with 33 lines in your changes missing coverage. Please review.
⚠️ Please upload report for BASE (gitside-gnucobol-3.x@253e5cc). Learn more about missing BASE report.

Files with missing lines	Patch %	Lines
cobc/codegen.c	5.88%	14 Missing and 2 partials ⚠️
cobc/field.c	41.66%	2 Missing and 5 partials ⚠️
cobc/parser.y	58.33%	3 Missing and 2 partials ⚠️
cobc/cobc.c	50.00%	1 Missing and 1 partial ⚠️
cobc/scanner.l	50.00%	0 Missing and 2 partials ⚠️
cobc/typeck.c	0.00%	1 Missing ⚠️
❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@                   Coverage Diff                   @@
##             gitside-gnucobol-3.x     #278   +/-   ##
=======================================================
  Coverage                        ?   67.42%           
=======================================================
  Files                           ?       34           
  Lines                           ?    61576           
  Branches                        ?    16050           
=======================================================
  Hits                            ?    41516           
  Misses                          ?    14104           
  Partials                        ?     5956

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Initial addition of CONSTANT SECTION

ebb3b05

GitMensch requested changes Mar 3, 2026

View reviewed changes

Corrections and follow up on previous CONSTANT SECTION changes

7c8d4bb

GitMensch requested changes Mar 6, 2026

View reviewed changes

RamyGeorge added 2 commits March 14, 2026 01:41

TEsts, Fdump and symbols

73d2b01

trailing whitespace fix

08997c8

RamyGeorge commented Mar 14, 2026

View reviewed changes

GitMensch requested changes Mar 14, 2026

View reviewed changes

RamyGeorge added 2 commits March 14, 2026 20:28

NULLABLE and CONSTANT RECORD

96e7ac8

field.c addition

1283d1a

GitMensch reviewed Mar 14, 2026

View reviewed changes

Comment thread cobc/parser.y

GitMensch reviewed Mar 14, 2026

View reviewed changes

Fixed testing and field.c adjustments

156a99e

GitMensch marked this pull request as draft March 15, 2026 14:05

GitMensch reviewed Mar 15, 2026

View reviewed changes

Comment thread cobc/typeck.c

GitMensch reviewed Mar 15, 2026

View reviewed changes

CONSTANT RECORD and NULLABLE redefinition

5cf52b0

RamyGeorge commented Mar 20, 2026

View reviewed changes

GitMensch requested changes Mar 20, 2026

View reviewed changes

RamyGeorge added 2 commits March 20, 2026 21:58

News Changelog and older requests

20a07e0

Fixed Constant_Record token position

ccee361

		01 NUM-CONST PIC 9(3) VALUE 444.
		01 OTHER-CONST PIC 9(3) VALUE 123.

		AT_CHECK([$COMPILE -Wunfinished prog.cob], [1], [],
		[prog.cob:7: warning: handling of CONSTANT SECTION code generation is unfinished; implementation is likely to be changed

Conversation

RamyGeorge commented Mar 3, 2026

Summary

Changes

Motivation

Tests

Uh oh!

GitMensch left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

GitMensch commented Mar 3, 2026

Uh oh!

GitMensch left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

GitMensch left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment