-
Notifications
You must be signed in to change notification settings - Fork 50
Remove WEXPERIMENTAL for "if with unsupported statements" #332
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -251,3 +251,11 @@ | |
| like before. | ||
| - `release 7 7134` | ||
| - `release 6 6449` | ||
| - `note 6` DMLC no longer emits warnings saying | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Toplevel if logic is 1.4 exclusive, and thus so should this releasenote.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I disagree. You are right that they are exclusive for 1.4 files, but their only use is in the context of 1.2 devices: The only allowed identifier is
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Only for the time being. I think we've both agreed upon extending the conditional to also allow the use of the compat params? Nevertheless, I guess this is a matter of perspective of where a releasenote belongs. I was thinking "1.4, because this feature is only available in 1.4 files", while you're arguing the use of it is only significant due to how it impact 1.2 devices. Because of that, I'm fine with it being in
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The releasenote split between 1.2/1.4/both is inherently fuzzy and somewhat questionable. What matters the most is that the end-user sees a note attached to the right package version, this happens no matter what releasenote file we pick; the choice of file is not so important. I guess the advantage of the split is that many syntax additions are 1.4 specific, and putting it in -1.4 eliminates the need to mention this in text. I think it would make sense at least to merge RELEASENOTES and RELEASENOTES-1.2. A total 7 notes were 1.2 specific over the past 3 years.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So what action are we taking? |
||
| `top-level '#if' body with unsupported statements`. These warnings were | ||
| often triggered in common code, causing excessive polution in build logs unless `--no-warn=WEXPERIMENTAL` was passed to DMLC. | ||
| The same rules as before apply to `#if` statements: Statements such as | ||
| `param` and `template` are forbidden inside `#if`, but a special exception | ||
| allows forbidden statements to appear specifically inside an `#if (dml_1_2)` | ||
| block. The warning message was meant to highlight this irregularity, but | ||
| caused more harm than good; error messages surrounding the special case have been improved instead. | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -2488,8 +2488,8 @@ The *object declarations* are any number of declarations of objects, session | |
| variables, saved variables, methods, `in each` statements, or other `#if` | ||
| statements, but not parameters or `is` statements. When the conditional is | ||
| `true` (or if it's the else branch of a false conditional), the object | ||
| declarations are treated as if they had appeared without any surrounding *#if*. | ||
| So the two following declarations are equivalent: | ||
| declarations are treated as if they had appeared without any surrounding `#if`. | ||
| Thus, the two following snippets are equivalent: | ||
|
|
||
| ``` | ||
| #if (true) { | ||
|
|
@@ -2499,12 +2499,36 @@ So the two following declarations are equivalent: | |
| } | ||
| ``` | ||
|
|
||
| is equivalent to | ||
|
|
||
| ``` | ||
| register R size 4; | ||
| ``` | ||
|
|
||
| As a special exception, an `#if` statement that appears on top level is allowed | ||
| to contain any type of statement, as long as the condition doesn't reference | ||
| any identifiers other than `dml_1_2`, `true` and `false`. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If you do add
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The reason for "only 1.2" is that I want to encourage users to consistently use the dml_1_2 form, for two reasons (or both are really the same reason):
For this reason, I don't yet see a real use case where dml_1_4 is preferable over dml_1_2, so I don't see a compelling reason to spend time here.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. MMmmfmffhghh... fine.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. actually, no -- not fine. I don't understand why your favored approach is to use the restrictions placed on top-level |
||
| This is often useful while migrating the devices of a system from DML 1.2 | ||
| to DML 1.4, as it allows conditional definitions of templates in common | ||
| code used from both DML 1.2 and DML 1.4. | ||
| For example, let's say an existing template `reset_to_seven` | ||
| is used in DML 1.2 code to set the reset value of a field to 7 in DML 1.2. | ||
| The parameters that control reset values have changed from DML 1.2 to DML 1.4, | ||
| and one way to handle this is to provide separate template definitions | ||
| depending on whether the device uses DML 1.2 or DML 1.4: | ||
| ``` | ||
| #if (dml_1_2) { | ||
| template seven is field { | ||
| param hard_reset_value = 7; | ||
| param soft_reset_value = 7; | ||
| } | ||
| } #else { | ||
| template seven is field { | ||
| param init_val = 7; | ||
| } | ||
| } | ||
| ``` | ||
| Later, when all related devices have been ported to DML 1.4, | ||
| the `dml_1_2` clause can be removed. | ||
|
|
||
| ## In Each Declarations | ||
|
|
||
| In Each declarations are a convenient mechanism to apply a | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -810,19 +810,17 @@ class EUNINITIALIZED(DMLError): | |
| """ | ||
| fmt = "value of parameter %s is not yet initialized" | ||
|
|
||
| class ECONDP(DMLError): | ||
| class EBADCONDSTMT(DMLError): | ||
| """ | ||
| It is not permitted to declare a parameter directly inside an | ||
| `if` conditional. | ||
| """ | ||
| fmt = "conditional parameters are not allowed" | ||
| `#if` statements in object scope are only allowed to contain | ||
| certain kinds of declarations: objects, `method`, `session`, | ||
| `saved`, `#if`, `in each`, or `error`. | ||
|
|
||
| class ECONDT(DMLError): | ||
| """ | ||
| It is not permitted to use a template directly inside an | ||
| `if` conditional. | ||
| A special exception is that a `#if` on top scope may contain any | ||
| kind of statement as long as the `#if` condition doesn't reference | ||
| any identifiers other than `dml_1_2`, `true`, and `false`. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Don't forget
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. wait. actually you can't reference That feels like a bad inconsistency. I mean, I got confused about it. Maybe you should add |
||
| """ | ||
| fmt = "conditional templates are not allowed" | ||
| fmt = "'%s' declaration not allowed inside `#if`" | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it's worth highlighting both in error documentation, and, in fact, the error message itself, that the forbidden declaration is only forbidden directly within The impact is also rather small (at least for the error message): |
||
|
|
||
| # TODO: Consider re-wording the semantics of this error, allocate_type is only | ||
| # relevant in 1.4 when imported from 1.2, and as per SIMICS-9393 this | ||
|
|
||
This file was deleted.
This file was deleted.
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,52 @@ | ||
| /* | ||
| © 2024 Intel Corporation | ||
| SPDX-License-Identifier: MPL-2.0 | ||
| */ | ||
| dml 1.4; | ||
|
|
||
| device test; | ||
|
|
||
| template empty {} | ||
|
|
||
| param yes = true; | ||
| #if (yes) { | ||
| /// ERROR EBADCONDSTMT | ||
| param p = 3; | ||
| /// ERROR EBADCONDSTMT | ||
| typedef int i_t; | ||
| } #else { | ||
| /// ERROR EBADCONDSTMT | ||
| template t { | ||
| } | ||
|
|
||
| /// ERROR EBADCONDSTMT | ||
| extern typedef int i_t; | ||
|
|
||
| /// ERROR EBADCONDSTMT | ||
| is empty; | ||
| } | ||
|
|
||
| #if (true) { | ||
| // no error | ||
| param p = 3; | ||
| extern typedef int i2_t; | ||
| } | ||
| #if (false) { | ||
| // no error | ||
| is empty; | ||
| param p = 3; | ||
| } | ||
| #if (dml_1_2) { | ||
| // no error | ||
| is empty; | ||
| param p = 3; | ||
| } | ||
|
|
||
| group g { | ||
| #if (true) { | ||
| /// ERROR EBADCONDSTMT | ||
| param p = 5; | ||
| // ERROR EBADCONDSTMT | ||
| is empty; | ||
| } | ||
| } |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,51 @@ | ||
| /* | ||
| © 2024 Intel Corporation | ||
| SPDX-License-Identifier: MPL-2.0 | ||
| */ | ||
| dml 1.4; | ||
|
|
||
| device test; | ||
|
|
||
| /// COMPILE-ONLY | ||
|
|
||
| #if (true) { | ||
| extern typedef int a_t; | ||
| typedef int b_t; | ||
| param p = 1; | ||
| } #else { | ||
| extern void *x; | ||
| import "nonexisting.dml"; | ||
| param p = 2; | ||
| error; | ||
| } | ||
|
|
||
| #if (p != 1) { error; } | ||
|
|
||
| #if (false) { | ||
| typedef void *a_t; | ||
| extern typedef void *b_t; | ||
| error; | ||
| template t { error; } | ||
| } #else { | ||
| extern int x; | ||
| import "imported.dml"; | ||
| template t { param from_t = true; } | ||
| } | ||
|
|
||
| #if (!imported) { error; } | ||
|
|
||
| is t; | ||
| #if (!from_t) { error; } | ||
|
|
||
| #if (dml_1_2 || false) { | ||
| error; | ||
| } #else { | ||
| #if (true) { | ||
| #if (!false) { | ||
| // nested top-level #ifs are permitted | ||
| param foo = true; | ||
| } | ||
| } | ||
| } | ||
|
|
||
| #if (!foo) { error; } |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,7 @@ | ||
| /* | ||
| © 2024 Intel Corporation | ||
| SPDX-License-Identifier: MPL-2.0 | ||
| */ | ||
| dml 1.4; | ||
|
|
||
| param imported = true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I chose not to because I didn't want to bore the reader with details, but it does make sense to mention WEXPERIMENTAL because of how
--no-warn=WEXPERIMENTALis sprinkled in makefiles.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah that's mostly why I figured it was a good idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
still not mention of
WEXPERIMENTAL, here. I still think you should do so, but whichever way you go about it is up to you.