Skip to content
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

Nested parenthesis within a port instantiation breaks syntax highlighting pattern on the next line #188

Open
birdybro opened this issue Oct 26, 2022 · 4 comments

Comments

@birdybro
Copy link

https://github.com/MiSTer-devel/SMS_MiSTer/blob/master/SMS.sv#L477-L478

image

@birdybro birdybro changed the title Conditional assignments within a port instantiation break syntax highlighting pattern on the next line Conditional assignments within a port instantiation breaks syntax highlighting pattern on the next line Oct 26, 2022
@birdybro birdybro changed the title Conditional assignments within a port instantiation breaks syntax highlighting pattern on the next line Nested conditional assignments within a port instantiation breaks syntax highlighting pattern on the next line Oct 26, 2022
@joecrop
Copy link
Collaborator

joecrop commented Jan 22, 2023

I'll be honest, this is low on the priority list because must commercial linting tools would scream bloody murder when you put this amount of logic directly in a port instantiation. An easy fix is to just assign this into a net before passing it to the port.

@birdybro
Copy link
Author

Agreed on principle for sure, but I figured I'd report it anyways regardless as it was unexpected behavior.

This extension does handle it correctly, but I prefer yours :P

@joecrop
Copy link
Collaborator

joecrop commented Sep 12, 2023

OK, I finally had time to dig into this and I have some bad... well maybe good? news. I can't recreate the problem in a VSCode environment with just the systemVerilog extension installed.

image

I wonder if you have another extension installed that is either overriding this extension or conflicting wtih it.

@birdybro
Copy link
Author

birdybro commented Sep 13, 2023

I just disabled the other extension from Masahiro Hiramori, I reinstalled yours, and the issue comes back. Maybe your color scheme youa re using doesn't differentiate between the two? Also is this the current release that is up on the vscode extension store you are using? I'm using the Dracula Pro color scheme which might make a distinction between two elements and yours might treat them as the same color... hrmmm

image

I used the file from the time I made this issue --> https://github.com/MiSTer-devel/SMS_MiSTer/blob/901ff4b5683d12929614c4250d13c4ca4e8b62b0/SMS.sv

Using the latest version makes no difference, just wanted to make sure there wasn't a change in code that somehow altered this.

Just confirmed, I changed to Dark Modern (not part of the Dracula color scheme) and sure enough they are the same color now. So whatever special distinction dracula makes between these two is not represented in probably a lot of other color schemes. Not a false positive, but probably not a thing most people would see unless they happened to use your extension combined with using Dracula color themes.

I don't know how to debug linters to see how the output differs to the perspective of how the color scheme is applied to different elements, or else I would help provide more info.

https://draculatheme.com/visual-studio-code - Here is the theme to recreate the issue.

EDIT: The green color is used to highlight functions names, function decorators, and function objects:

    - markup.inserted

    - markup.inline.raw
    - markup.raw.restructuredtext

    - fenced_code.block.language
    - markup.raw.inner.restructuredtext
    - markup.fenced_code.block.markdown punctuation.definition.markdown

    - entity.other.attribute-name

    - entity.name.function
    - meta.function-call.object
    - meta.function-call.php
    - meta.function-call.static
    - meta.method-call.java meta.method
    - meta.method.groovy
    - support.function.any-method.lua
    - keyword.operator.function.infix

    - meta.decorator variable.other.readwrite
    - meta.decorator variable.other.property

    - meta.decorator variable.other.object

    - variable.other.alias.yaml

    - meta.assertion.look-ahead.regexp

These ones that are undefined in your linter might be the culprit? Sorry, a bit out of my depth, just trying to help.

- meta.function-call
- meta.method-call
- meta.method
- keyword.operator.function
- meta.decorator variable
- variable.other.alias
- meta.assertion

EDIT2: Having fun learning how the linter works now... I don't know much about regex, but it looks like it should be working...

image

I did notice one thing however... The moldule's name (e.g. altddio_out) doesn't seem to get picked up if it is a parameterized module. The regexr.com generator shows the same result. Maybe this is associated?

image

image

Nvm, this last one is due to a line break before the # to designate parameter ports.

Demonstrated what part is causing the linting difference:

image

It's nested parenthesis within that seem to do it (again best to just assign it to a wire externally, I agree with that haha)

@birdybro birdybro changed the title Nested conditional assignments within a port instantiation breaks syntax highlighting pattern on the next line Nested ~~conditional assignments~~ parenthesis within a port instantiation breaks syntax highlighting pattern on the next line Sep 13, 2023
@birdybro birdybro changed the title Nested ~~conditional assignments~~ parenthesis within a port instantiation breaks syntax highlighting pattern on the next line Nested parenthesis within a port instantiation breaks syntax highlighting pattern on the next line Sep 13, 2023
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

No branches or pull requests

2 participants