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

Compile-time macro confuses function names #19489

Closed
lUNuXl opened this issue Oct 1, 2023 · 1 comment · Fixed by #19768
Closed

Compile-time macro confuses function names #19489

lUNuXl opened this issue Oct 1, 2023 · 1 comment · Fixed by #19768
Assignees
Labels
Bug This tag is applied to issues which reports bugs. Status: Confirmed This bug has been confirmed to be valid by a contributor. Unit: cgen Bugs/feature requests, that are related to the default C generating backend. Unit: Compiler Bugs/feature requests, that are related to the V compiler in general.

Comments

@lUNuXl
Copy link

lUNuXl commented Oct 1, 2023

Describe the bug

@spytheman on discord told me that in this bug the compile-time step confuses function named value for a value it's prividing named value

I suppose, some kind of way to hint to the compiler that I actually want to reference my function instead of whatever it is providing would be useful.

The proposed fix workaround is to change my function name from "value" to something else, which works, however it'd be nice if there was a better way of doing things.

Reproduction Steps

enum CharacterGroup {
    chars
    alphanumerics
    numeric
    special
}

fn (self CharacterGroup) value() string {
    return match self {
        .chars { "first" }
        .alphanumerics { "second"}
        .numeric { "third"}
        .special { "fourth"}
    }
}

fn CharacterGroup.values() []CharacterGroup {
    mut res := []CharacterGroup{}
    $for item in CharacterGroup.values {
        res << CharacterGroup(item.value)
    }
    return res
}

fn main() {
    println("Char group values: ${CharacterGroup.values()}")
    println("For loop over the values")
    for entry in CharacterGroup.values() {
        println("Value: $entry  ${entry.value()}")
    }
}

Expected Behavior

Char group values: [chars, alphanumerics, numeric, special]
For loop over the values
Value: chars  first
Value: alphanumerics  second
Value: numerics  third
Value: special  fourth

Current Behavior

Char group values: [unknown enum value, unknown enum value, unknown enum value, unknown enum value]
For loop over the values
Value: unknown enum value  fourth
Value: unknown enum value  fourth
Value: unknown enum value  fourth
Value: unknown enum value  fourth

Possible Solution

As I said before: @spytheman suggested changing function name to avoid collision which works

Additional Information/Context

No response

V version

V 0.4.1 12ee3fa

Environment details (OS name and version, etc.)

V full version: V 0.4.1 12ee3fa
OS: linux, "Arch Linux"
Processor: 8 cpus, 64bit, little endian, Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz

getwd: /home/larry
vexe: /home/larry/v/v
vexe mtime: 2023-09-27 09:53:28

vroot: OK, value: /home/larry/v
VMODULES: OK, value: /home/larry/.vmodules
VTMP: OK, value: /tmp/v_1000

Git version: git version 2.42.0
Git vroot status: Error: fatal: not a git repository (or any parent up to mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
.git/config present: false

CC version: cc (GCC) 13.2.1 20230801
thirdparty/tcc: N/A

Note

You can vote for this issue using the 👍 reaction. More votes increase the issue's priority for developers.

Take into account that only the 👍 reaction counts as a vote.
Only reactions to the issue itself will be counted as votes, not comments.

@lUNuXl lUNuXl added the Bug This tag is applied to issues which reports bugs. label Oct 1, 2023
@spytheman spytheman added Unit: cgen Bugs/feature requests, that are related to the default C generating backend. Unit: Compiler Bugs/feature requests, that are related to the V compiler in general. Status: Confirmed This bug has been confirmed to be valid by a contributor. labels Oct 1, 2023
@spytheman
Copy link
Member

What I suggested (the name change), is not a fix, but more of a workaround, until the compiler is fixed. The code should be working as you wrote it, that it does not, is a compiler bug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug This tag is applied to issues which reports bugs. Status: Confirmed This bug has been confirmed to be valid by a contributor. Unit: cgen Bugs/feature requests, that are related to the default C generating backend. Unit: Compiler Bugs/feature requests, that are related to the V compiler in general.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants