TWiki
>
P1076 Web
>
Vhdl2019CollectedRequirements
>
TopLCS2016_015b
(2020-02-17,
JimLewis
)
(raw view)
E
dit
A
ttach
---+ Language Change Specification for Accessing FILE_NAME and LINE_NUMBER of a Named Entity ---++ | <sticky><b>LCS Number:</b></sticky> | LCS-2016-015b | | <sticky><b>Version:</b> </sticky> | 1 {21-Feb-2017} %BR% 2 {22-Feb-2017} %BR% 3 {14-Mar-2017} | | <sticky><b>Date:</b> </sticky> | 14-Mar-2017 | | <sticky><b>Status:</b> </sticky> | Voting | | <sticky><b>Author:</b> </sticky> | Patrick Lehmann | | <sticky><b>Email:</b> </sticky> | [[Main.PatrickLehmann]] | | <sticky><b>Source Doc:</b></sticky> | - - - - | | <sticky><b>Summary:</b> </sticky> | Get source code positions of named entities. | ---+++ Voting Results: Cast your votes here Yes: 1 %USERSIG{SteveGrout - 2017-02-22}% - ver 2 1 %USERSIG{PatrickLehmann - 2017-03-14}% - ver 3 1 %USERSIG{JimLewis- 2017-03-06}%- ver 3. No: Abstain: 1 %USERSIG{LarsAsplund- 2017-03-23}%- ver 3 - Lacking use case ---++ Style Notes <noautolink> <sticky> Changes are shown in %RED%red font%ENDCOLOR%.%BR% Deletions are %RED%<del>crossed out</del>%ENDCOLOR%.%BR% Editing or reviewing notes in %GREEN%green font%ENDCOLOR%. ---++ Reviewing Notes This is a competing idea on how to solve LCS 015a. *Version 2:* * Aligned with LCS 015 / 015a * Fix meaning of file_line -> first lexical element *Version 1:* %BR% This version shows an attribute based approach to get to FILE_NAME and LINE_NUMBER of a named entity (see 7.2). <pre> package pkg is function foo return boolean is end package; package body pkg is function foo return boolean is begin report "foo: " & INTEGER'image(foo'LINE_NUMBER); end function; end package body; </pre> This returns "foo: 6". But not * "foo: 2" where the forward declaration appears and not * "foo: 8" where the attribute is used. The get the line of the report statement, a label before =report= or and an expression can be used: =INTEGER'image(foo'LINE_NUMBER + 2)=. *Version 2:* %BR% * Changed =FILE_NAME= to =FILE_PATH= (full name) * Added =FILE_NAME= for the simple file name * Fixed section number and name ---++ Details of Language Change ---+++ 16.2.5 Predefined attributes of named entities %GREEN%[Editor note: Insert the next table after table for E'PATH_NAME.]%ENDCOLOR% %BR% | %RED%E'FILE_NAME%ENDCOLOR% \ | %RED%Kind:%ENDCOLOR% | %RED%Value%ENDCOLOR% | | | %RED%Prefix:%ENDCOLOR% | %RED%Any prefix E that denotes a named entity.%ENDCOLOR% | | | %RED%Result type:%ENDCOLOR% | %RED%STRING.%ENDCOLOR% | | | %RED%Result:%ENDCOLOR% | %RED%The name of the design file without the file path in which E was fully defined.%ENDCOLOR% | | ||| | %RED%E'FILE_PATH%ENDCOLOR% \ | %RED%Kind:%ENDCOLOR% | %RED%Value%ENDCOLOR% | | | %RED%Prefix:%ENDCOLOR% | %RED%Any prefix E that denotes a named entity.%ENDCOLOR% | | | %RED%Result type:%ENDCOLOR% | %RED%STRING.%ENDCOLOR% | | | %RED%Result:%ENDCOLOR% | %RED%The fully resolved absolute path without the file name of the design file in which E was fully defined.%ENDCOLOR% | | ||| | %RED%E'FILE_LINE%ENDCOLOR% \ | %RED%Kind:%ENDCOLOR% | %RED%Value%ENDCOLOR% | | | %RED%Prefix:%ENDCOLOR% | %RED%Any prefix E that denotes a named entity.%ENDCOLOR% | | | %RED%Result type:%ENDCOLOR% | %RED%POSITIVE.%ENDCOLOR% | | | %RED%Result:%ENDCOLOR% | %RED%The line number in the design file where the first lexical element of E appeared and E was fully defined.%ENDCOLOR% | ---++ Comments ---+++ Version 1 I do not see this proposal competing with LCS 015a as the latter provides a direct solution for the most common use case in error reporting. The label approach looks somewhat clumsy. Nonetheless, this proposal has an added value in flexibly accessing the file information of arbitrary accessible objects. -- %BUBBLESIG{ThomasPreusser - 2017-02-21}% *JL:* Why an attribute when a simple subprogram can return this information. *PL: I noticed this LCS doesn't return always the same values as LCS 015a. As I explained in my email announcing both LCS 015a and LCS 015b, I wrote that attributes can be evaluated at analysis type and are globally static. That's not the case for your function based API. My NO vote on LCS 015a was changed to a NO for a technical issue. I still think we need this LCS too, because LCS 015a doesn't give us where a named entity was defined, only where it's executed. So in conclusion I think we should have both complementary solutions. -- %BUBBLESIG{PatrickLehmann - 2017-03-07}% PL: LCS 015a doesn't give us where a named entity was defined, only where it's executed I get the point: attributes are globally static; functions are dynamic. Both are useful/needed. But the functions and attributes are the same, e.g. FILE_NAME. This is going to be incredibly confusing. I don't like the idea of proliferating identifiers any more than anyone else, but this is effectively overloading, but with different behaviours. (OTOH if you really want to overload, decide whether to use LINE_NUMBER or FILE_LINE). -- %BUBBLESIG{MarkZwolinski - 2017-03-07}% I'll change that to whatever Jim uses. -- %BUBBLESIG{PatrickLehmann - 2017-03-07}% What is =E'LINE_NUMBER= for an architecture declaration? Is it the end? -- %BUBBLESIG{JimLewis - 2017-03-11}% *JL:* What is =E'LINE_NUMBER= for an architecture declaration? %BR% *PL:* Where =architecture= appears. I fixed the text in version 2. -- %BUBBLESIG{PatrickLehmann - 2017-03-14}% @TODO: at meeting 16-Mar: Does lots of cool things. Got any compelling use models? -- %BUBBLESIG{JimLewis - 2017-03-16}% LCS 015 / 015a can only be used for sequential code. This LCS allows a user to get line and file information of all declared VHDL entities for reporting purposes. -- %BUBBLESIG{PatrickLehmann - 2017-03-20}% For the use case of locating a log entry made by a report statement this becomes less convenient for the user when compared to having a function. Each report statement would need a unique label. For me the whole point is to get a location of a log entry without manually inserting such IDs. Regardless if attributes or functions are used I wouldn't create many such report statements before I create a convenience function that inserts that automatically. In VUnit we solve that by preprocessing the VHDL code but the call path LCS is what I really need so that I can get the caller location. Attributes can also provide the location of any entity but I think we need to identify the value adding use cases for that. Without a strong use case I don't think this will be worth the effort. -- %BUBBLESIG{LarsAsplund - 2017-03-23}% %COMMENT%</sticky> </noautolink>
E
dit
|
A
ttach
|
P
rint version
|
H
istory
: r15
<
r14
<
r13
<
r12
<
r11
|
B
acklinks
|
V
iew topic
|
Ra
w
edit
|
M
ore topic actions
Topic revision: r15 - 2020-02-17 - 15:34:40 -
JimLewis
P1076
Log In
or
Register
P1076 Web
Create New Topic
Index
Search
Changes
Notifications
RSS Feed
Statistics
Preferences
Webs
Main
P1076
Ballots
LCS2016_080
P10761
P1647
P16661
P1685
P1734
P1735
P1778
P1800
P1801
Sandbox
TWiki
VIP
VerilogAMS
Copyright © 2008-2025 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki?
Send feedback