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

Function prelude associates with caller's source position #8442

Closed
jdm opened this issue Aug 10, 2013 · 2 comments
Closed

Function prelude associates with caller's source position #8442

jdm opened this issue Aug 10, 2013 · 2 comments
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.)

Comments

@jdm
Copy link
Contributor

jdm commented Aug 10, 2013

With a simple setup like

pub fn f() {
  io::println("foo");
}

pub fn main() {
  f();
}

breaking in main and stepping into f yields odd behaviour in gdb. Specifically, the first step into f shows pub fn main() {, the second shows f();, and the third takes us to the proper io::println("foo");. Disassembling at each step shows the first step takes us inside f into its prelude, so obviously we're not updating the source position correctly when generating the function.

@jdm
Copy link
Contributor Author

jdm commented Aug 10, 2013

Tagging @michaelwoerister so he sees this.

@jdm
Copy link
Contributor Author

jdm commented Aug 22, 2013

Can't reproduce this any more with master. Shrug.

@jdm jdm closed this as completed Aug 22, 2013
bors added a commit that referenced this issue Aug 23, 2013
… r=jdm

This PR contains some code cleanup and the fix for issue #8670.
~~I am not sure about issue #8442 (could not reproduce it). @jdm, could check after this is merged and possibly close the issue then?~~ (closed now)

Some interesting facts: With this commit, it should be possible to compile libstd with `-Zdebug-info` (it does not work yet with `-Zextra-debug-info` but we are getting there). Switching debug info on increases the compile time for libstd by about 2 seconds.

@catamorphism I get one failing test in rustpkg:
`package_script_with_default_build` says: `task <unnamed> failed at 'Couldn't copy file', /home/mw/rust/src/librustpkg/tests.rs:689`
Would you have any idea what that is about? Seems be something wrong on my machine...

Cheers,
Michael

Fixes #8670
flip1995 pushed a commit to flip1995/rust that referenced this issue Feb 24, 2022
trigger  `ptr_as_ptr` inside macros

This PR makes `ptr_as_ptr` trigger inside macros

Fixes issue rust-lang#8120

changelog: ``[`ptr_as_ptr`]`` is now triggered inside macros

r? `@llogiq`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.)
Projects
None yet
Development

No branches or pull requests

1 participant