Skip to content

refactor: set default lineinfo on state/block#2344

Closed
romanc wants to merge 3 commits into
spcl:mainfrom
romanc:romanc/warnings-default-line-info
Closed

refactor: set default lineinfo on state/block#2344
romanc wants to merge 3 commits into
spcl:mainfrom
romanc:romanc/warnings-default-line-info

Conversation

@romanc

@romanc romanc commented Apr 21, 2026

Copy link
Copy Markdown
Contributor

Description

Follow-up from PR #2321, we shouldn't set debuginfo anymore to a DebugInfo object when adding things to a State (or CFG Block). Instead, we set the default_lineinfo on that State.

@romanc romanc marked this pull request as ready for review April 21, 2026 16:09
FlorianDeconinck pushed a commit to GridTools/gt4py that referenced this pull request Apr 21, 2026
…2581)

## Description

DaCe now comes with a configuration option whether or not to inspect the
python stack in case debug information (e.g. line number) is missing. We
previously used a fake `DebugInfo` object to prevent the call to
`inspect()`. With the new configuration option, we can remove those fake
objects again and just configure the desired behavior.

A word of caution: until spcl/dace#2344 or
something similar is merged, DaCe will output a ton of deprecation
warnings caused by the addition of the new config option.

## Requirements

- [ ] All fixes and/or new features come with corresponding tests.
  N/A
- [ ] Important design decisions have been documented in the appropriate
ADR inside the [docs/development/ADRs/](docs/development/ADRs/README.md)
folder.
  N/A

@tbennun tbennun left a comment

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.

I think the current diff in newast is overkill and we can just wrap the parts that change pv.current_lineinfo with the with statement instead. Any reason not to?

@romanc

romanc commented Apr 22, 2026

Copy link
Copy Markdown
Contributor Author

I agree, it doesn't look pretty now. I don't have a mental picture of newast.py that is good enough to propose an automatically sync of .current_lineinfo on the ProgramVisitor with ._default_line_info on the respective State.

I guess one could automatically set state._default_line_info to pv.current_lineinfo for any state that is added to the SDFG and then potentially update once pv.current_lineinfo changes. Is that what you are suggesting? That would mean tracking all new state creation and setting _default_line_info accordingly.

I start to wonder why we changed the signature of state.add_read() in the first place. PR #2345 explores partially reverting https://github.com/spcl/dace/pull/2321and avoiding the deprecation warnings all together.

@romanc

romanc commented Apr 23, 2026

Copy link
Copy Markdown
Contributor Author

@tbennun I think you should look at #2345 as a replacement for this PR. #2345 is a much smaller change and gives the same results (all warnings gone).

@tbennun tbennun closed this Apr 23, 2026
@romanc romanc deleted the romanc/warnings-default-line-info branch April 23, 2026 06:15
romanc added a commit to romanc/dace that referenced this pull request Apr 24, 2026
## Description

In PR spcl#2321 we introduced a way to turn
of automatic stack inspection when adding a node to a state without
explicitly stating debug info (such as file name, line info, ...). Since
merging this PR, we get a ton of `DeprecationWarning`s from code added
in `_get_debug_info()`.

In a first attempt (see PR spcl#2344), we
tried to work around the issue by setting `._default_line_info` on the
state. This method proved to be very verbose and unnecessarily
complicates parsing, where we have a legitimate use-case for explicitly
passing along an explicit `DebugInfo`.

This PR suggests to keep the API of `state.add_*()` functions as before,
partially reverting changes from PR
spcl#2321. Doing so, we can drop the
deprecation warnings because nothing changes.
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.

2 participants