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

Interrupting configure makes the build process unhappy #1727

Closed
catamorphism opened this issue Feb 1, 2012 · 1 comment
Closed

Interrupting configure makes the build process unhappy #1727

catamorphism opened this issue Feb 1, 2012 · 1 comment

Comments

@catamorphism
Copy link
Contributor

If I hit Ctrl-C during configure (at least on a Mac), I get:

make: *** Deleting file config.mk'`

which means that if I subsequently do make check:

Makefile:51: config.mk: No such file or directory
[snip]
make: *** No rule to make target `/mk/tests.mk'.  Stop.

I have to manually re-run ./configure to get it to work. This seems wrong, since I didn't have to run ./configure initially -- it was triggered by doing a git update and the contents of the relevant files changing.

@graydon
Copy link
Contributor

graydon commented Apr 4, 2012

This was fixed (indirectly) by 418c6bc

@graydon graydon closed this as completed Apr 4, 2012
RalfJung pushed a commit to RalfJung/rust that referenced this issue Jun 29, 2024
…id_fixup-03, r=RalfJung

Remove GetCurrentProcessId's frame_in_std check

Most of the support required to close rust-lang#1727 was actually added a while back, in rust-lang#2215.

However, for some reason, even though the Unix/Linux syscall equivalent has no `frame_in_std()` check, the Windows `GetCurrentProcessId` check did. While the vast majority of use cases use `std::process::id`, there's no particular reason to penalize any Windows code that is no_std or for whatever other reason choses to call the function directly (e.g. via the generated [windows-sys](https://docs.rs/windows-sys/latest/windows_sys/Win32/System/Threading/fn.GetCurrentProcessId.html) method). The emulation should still work fine. Given there's no reason not to, we might as well simplify the code a tiny bit and save that branch / frame check during runtime too.

This PR removes the `frame_in_std` restriction for `GetCurrentProcessId`, and also moves it into the environment related shim section per discussion in rust-lang/miri#1727 (comment).

Still passes existing tests/pass/getpid.rs test.

Closes rust-lang#1727 unless we wish to give a dummy value when isolated, which we don't seem to want to do at this time.
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