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
[BUG] __call_location().file_name
returns incorrect information
#2534
Comments
FYI @laszlokindrat |
__call_location().file_name
return incorrect information__call_location().file_name
returns incorrect information
Following the new update to nightly/mojo, I've expended on the test code, taking into @Arthur Evans's wise words about not inlining the main fn 😮 Now we have... fn main():
test_fn() # <== Reports this location!
@always_inline("nodebug")
fn test_fn():
var file_name = __call_location().file_name
var line = __call_location().line
print(file_name)
print(line)
# Output of test
#
# [Fri May 10 2024 12:24PM (BST+0100)] (main) [*] 🐍 v3.12.1
# ~/Code/Mojo/ca_mojo/ca_lib/research mojo main.mojo
# /Users/carlcaulkett/Code/Mojo/ca_mojo/ca_lib/research/main.mojo
# 4 The behaviour is improved, source location is now reported as the call point to the function. It's difference from how it used to be, but by chance this behaviour may suit me in my particular use case 😉 Note that this code still returns the baked in Modular source path... from builtin._location import __call_location, _SourceLocation
@always_inline("nodebug")
fn main():
var st = __call_location().file_name
print(st) |
Thanks for opening the ticket! Regarding the OP: this is sort of expected behavior, since the |
Bug description
It seems that the
__call_location()
function is returning incorrect data.It's been suggested that, "It looks to be baking in our internal source code path into the Mojo binary which isn't good.".
Steps to reproduce
I ran the following code...
This is what I saw...
System information
The text was updated successfully, but these errors were encountered: