-
Notifications
You must be signed in to change notification settings - Fork 38
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
Rename signal as they are defined #1040
Comments
Morning @ungultig1 , There are two rules which work together to provide the feature you are looking for. Rule I am working on implementing support for camelCase in issue #924. It would be nice to have another voice in the discussion to help guide the implementation. I am currently adding support for prefixes and suffixes along with camelCase. Meanwhile, if you use the following configuration: rule:
signal_004:
disable: True and run it against your example code: 1 architecture behaviour of example is
2
3 signal sl_mySignalNaming : std_logic; -- my defined signal-naming
4
5 begin
6
7 -- vsg-default after format:
8 sl_mysignalnaming <= '1';
9
10
11 -- Propose:
12 -- a setting, which allows to format the signals-naming as defined above:
13 sl_mysignalNaming <= '1'; -- this is the wrong case while coding
14 -- after format, this will be corrected to:
15 sl_mySignalNaming <= '1'; -- as defined above
16
17
18 end behaviour; The code will be fixed to: 1 architecture behaviour of example is
2
3 signal sl_mySignalNaming : std_logic; -- my defined signal-naming
4
5 begin
6
7 -- vsg-default after format:
8 sl_mySignalNaming <= '1';
9
10 -- Propose:
11 -- a setting, which allows to format the signals-naming as defined above:
12 sl_mySignalNaming <= '1'; -- this is the wrong case while coding
13 -- after format, this will be corrected to:
14 sl_mySignalNaming <= '1'; -- as defined above
15
16 end architecture behaviour; This would be a temporary fix until the other issue is implemented. Regards, --Jeremy |
Hello @jeremiah-c-leary , yeah, deactivating signal_004-rule made the difference. Great, Thanks. Unfortunately, it wont format the signal-names, when defined inside a record. Example:
maybe I'm missing here something else. Thank you. Greetings, |
Good Afternoon @ungultig1 , There are currently no rules to enforce consistent casing in your latest example. I currently do not have a rule similar to what you are requesting so it will take a bit to implement. I have to ensure I keep the scoping correct. I think I have to plan on how to do it. --Jeremy |
Good morning @jeremiah-c-leary, were you able to create such rule? Thank you. |
Afternoon @ungultig1 , At the moment I am having an issue with scoping and ensuring a consistent case can be applied correctly when signals with similar names are used. I do not have a reasonable solution yet that does not require a significant update to the internal data structure. I believe it is something that should be implemented, I'm afraid it will take awhile before it finally is implemented. Regards, --Jeremy |
Morning @ungultig1 , So I have been thinking about this a little more and it seems there are two parts you asking for:
I believe the first one should not be that hard, and I want to think the second would could be done with my existing data structure. I just need to think on it a little more. Regards, --Jeremy |
Goog morning @jeremiah-c-leary,
I wonder, if the following feature can already be activated (and I missed it) or please could be implemented (?):
At the moment the signals-naming is defined by vsg as default.
Is there any possibility, that the signals-name are being formatted by looking at the definitions?
For instance:
As i prefer the camel-case-notation and vsg of course couldn't know how to keep the correct naming, vsg could keep a look at the signals-name definition (also considered the definitions in record-, port- signal-namings etc.)
Big thanks to you.
Greetings,
The text was updated successfully, but these errors were encountered: