-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
most of the run-make tests could be silently passing on cases that should fail #13746
Comments
pnkfelix
changed the title
most of the run-make tests are silently passing on cases that should fail
most of the run-make tests could be silently passing on cases that should fail
Apr 25, 2014
pnkfelix
added a commit
to pnkfelix/rust
that referenced
this issue
Apr 25, 2014
What this commit does: * Pass both of the (newly introduced) HOST and TARGET rpath setup vars to `maketest.py` * Update `maketest.py` to no longer update the LD_LIBRARY_PATH itself Instead, it passes along the HOST and TARGET rpath setup vars in environment variables `HOST_RPATH_ENV` and `TARGET_RPATH_ENV` * Cleanup: Distinguish in tools.mk between the command to run (`RUN`) and the file to generate to drive that command (`RUN_BINFILE`). The main thing this enables is that `RUN` can now setup the `TARGET_RPATH_ENV` without having to dirty up the runner code in each of the `run-make` Makefiles. I should have tried to fix rust-lang#13746 but I got distracted, and decided fixing that is orthgonal to the changes in this branch of work. Note that even with these changes, `make check-stage1` still does not work all the way to completion. (It just gets further than it did before, but still breaks down in the `run-make` tests.)
pnkfelix
added a commit
to pnkfelix/rust
that referenced
this issue
Apr 25, 2014
(Note that most tests are not using FAILS anyway, due to rust-lang#13746.)
Yuck. Nice catch. |
part of #8058 |
bors
added a commit
that referenced
this issue
May 18, 2014
Fix #13732. This is a revised, much less hacky form of PR #13753 The changes here: * add instrumentation to aid debugging of linkage errors, * fine tune some things in the Makefile where we are telling binaries to use a host-oriented path for finding dynamic libraries, when it should be feeding the binaries a target-oriented path for dynamic libraries. * pass along the current stage number to run-make tests, and * skip certain tests when running atop stage1. Fix #13746 as well.
arcnmx
pushed a commit
to arcnmx/rust
that referenced
this issue
Dec 17, 2022
…as-schievink fix: make make_body respect comments in extract_function Possible fix for rust-lang#13621 ### Points to help in review: - Earlier we were only considering statements in a block expr and hence comments were being ignored, now we handle tokens hence making it aware of comments and then preserving them using `hacky_block_expr_with_comments` Seems like I am not able to attach output video, github is glitching for it :(
flip1995
added a commit
to flip1995/rust
that referenced
this issue
Nov 28, 2024
r? @ghost changelog: none
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Makefiles unfortunately do not error on undefined variable references; they just silently expand into an empty string. And an empty string is also not an invalid command in a recipe.
So, a recipe like this (observe highlighted line): run-make/dylib-chain/Makefile
does not actually work because of this: run-make/tools.mk
because
$(call FAIL,main)
is going to expand into an empty string; what was wanted was$(call FAILS,main)
Although it looks like most of the tests are using
$(call FAIL,xxx)
, so its probably simpler to just changetools.mk
to use the nameFAIL
instead ofFAILS
:(The bigger question is whether attempting to implement this fix is going to actually expose latent bugs...)
The text was updated successfully, but these errors were encountered: