Skip to content

dslx: Prefer local constants over parametric bindings - #5303

Open
goutamadwant wants to merge 2 commits into
google:mainfrom
goutamadwant:fix-dslx-const-shadowing
Open

goutamadwant wants to merge 2 commits into
google:mainfrom
goutamadwant:fix-dslx-const-shadowing

Conversation

@goutamadwant

Copy link
Copy Markdown

Constexpr evaluation seeds its environment with parametric bindings. When a
local constant shadows a parametric with the same name, inserting the
resolved lexical value left the original parametric value in place. A
const if could therefore select the wrong branch under TIv2.

Replace the seeded value with the resolved lexical binding. Add a reduced
regression test whose local constant must select the u32 branch instead
of the incompatible u16 branch.

Validation:

  • Reproduced the reported failure before the fix; the original example now
    typechecks for all four instantiations.
  • Passed //xls/dslx:constexpr_evaluator_test, all 19 test targets under
    //xls/dslx/type_system_v2/..., and the function_converter_test and
    proc_config_ir_converter_test targets.
  • The broader IR-converter package run stopped at a macOS linker error in
    //xls/passes:oss_optimization_passes after 7 of 14 tests passed.
    Runtime execution of the original example was not completed.

Fixes #4161

When constexpr evaluation resolves a lexical constant, let it replace a same-named parametric value that seeded the environment. This makes const conditionals honor local shadowing under TIv2.

Fixes google#4161
TEST(TypecheckV2Test, ConstConditionalLocalConstShadowsParametric) {
EXPECT_THAT(R"(
fn f<N: u32>() -> u32 {
const N = N % u32:4;

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We may be better off disallowing the shadowing of a parametric, to tell you the truth. The good of disallowing it seems to outweigh the good of trying to support it. It would probably also be easier to verify all cases of (error in the parser?). What do you think?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree @richmckeever disallowing it is cleaner. I've updated the parser to reject parametric shadowing instead of trying to support it. Pls have another look. thanks!

Reject lexical bindings that shadow an in-scope parametric during parsing,
including parametrics inherited by struct and proc implementations. Report
the original binding location and preserve ordinary local shadowing.

Remove the constexpr environment workaround, add parser and typechecking
regressions, and document the restriction.

Fixes google#4161

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Confusing variable shadowing with const if

2 participants