Comments (14)
It's improving -- RLS and Clippy will soon be available on stable via rustup. As for this tool, there aren't any plans, but perhaps once the custom test framework stuff happens?
from compiletest-rs.
@laumann, @Manishearth Let's get a new release out with a7d5757
from compiletest-rs.
@SergioBenitez I'm putting together 0.3.11 now.
from compiletest-rs.
Of course, I meant 0.3.12
from compiletest-rs.
This seems like a breaking change for the stable
feature, isn't it?
I've written several tests locally, they all work as expected on my nightly toolchain, but the CI was failing.
I added features = ["stable"]
to check if things would work on stable, but immediately all the tests failed with:
failure produced the wrong error: exit code: 101
from compiletest-rs.
@JeanMertz This was discussed recently in #124. The short summary is that supporting stable is something that'd be nice to do, but it's becoming harder to maintain.
The switch from error code 101
to 1
on nightly means even more maintenance for the stable
feature, and I see that as just the beginning of an escalating headache.
But short answer, yes and sorry, the stable
feature should probably be regarded as broken since 0.3.12.
from compiletest-rs.
Ouch, okay.
I get where you're coming from. As a new Rustacean, it's quite annoying to see all these awesome tools out here that "force" you to use nightly to use them. That's not a complaint towards you, but to the ecosystem in general. I also see the upsides of that choice (combining both stability with the rapid experimentation on nightly), but it's still annoying to deal with (as it is as a maintainer as well, I'm sure).
from compiletest-rs.
@JeanMertz Well, I'm also lazy :-) And I understand your frustration. This project exists primarily as a Ctrl-C Ctrl-V from rustc/compiletest. I just wanted to make compiletest available outside of rustc somehow.
Ideally this project should be independent from rustc's version (I believe @SergioBenitez has made that argument before) and work on both stable and nightly. Maybe even targeting stable as the primary usecase would be the best. It'd be fair to call it a hack, but as it turns out a useful hack.
But I honestly don't actively develop this as much (because "development" really just means merging in the latest changes from rustc/compiletest). I'm very glad to take updates and proposed changes though!
from compiletest-rs.
But I honestly don't actively develop this as much (because "development" really just means merging in the latest changes from rustc/compiletest). I'm very glad to take updates and proposed changes though!
Correct me if I'm wrong, but if I made a change that basically pulled out the current hard-coded 1
exit code integer into its own function, and add a second (equally named) function that returns 101
, and then have either one enabled based on if you've enabled the stable
feature, would at least make this problem go away, correct?
Is that a PR you'd be willing to take?
edit:
I see that it's defined as a constant, so that would have to be changed, but I don't think that would be an issue.
I could also copy the check_correct_failure_status
implementation from both nightly and stable, and use the correct one based on the stable
feature flag.
from compiletest-rs.
Maybe, I'd need some convincing arguments though :-) @fpoli actually made that specific change in #120 (see #120 (comment)) and I had him roll it back.
But I don't know if we should just roll with it for now? When the current nightly becomes stable, then the exit code should also "stabilize" to 1
, right?
from compiletest-rs.
Maybe, I'd need some convincing arguments though :-) @fpoli actually made that specific change in #120 (see #120 (comment)) and I had him roll it back.
Ah right, I missed that (collapsed) comment. I see your point about maintainability.
But I don't know if we should just roll with it for now? When the current nightly becomes stable, then the exit code should also "stabilize" to
1
, right?
I'm not sure what determines when something migrates to stable, is it a given that the exit code change will be part of the next release?
Either way, I'm fine rolling with it for now and only run the compiletest
test suites on nightly for now 👍
from compiletest-rs.
OK, thanks. (Re-reading my previous comment, I meant for us to roll with the added maintenance complexity and just make the change to support exit code 101
on stable :-) Sorry if it came off as snarky.)
If you want, we could make a PR to bring back stable support (just this return code stuff), and I'll try to get people's opinion on it? If more people want it, I see no harm in merging it.
from compiletest-rs.
OK, thanks. (Re-reading my previous comment, I meant for us to roll with the added maintenance complexity and just make the change to support exit code 101 on stable :-) Sorry if it came off as snarky.)
Re-reading your comment, I now realise I took it the wrong way 😓
If you want, we could make a PR to bring back stable support (just this return code stuff), and I'll try to get people's opinion on it? If more people want it, I see no harm in merging it.
Thanks for the offer, I suggest we wait for the next stable release, and see if the new exit code becomes stable with that release. If not, I'll open up a PR with the required change.
Until then, I'll just run the compiletest tests on nightly builds, and the regular tests on stable.
from compiletest-rs.
OK, we'll do that. 👍
from compiletest-rs.
Related Issues (20)
- Remove all references to "stable" feature
- run-pass tests with non-zero exit code is considered passing HOT 6
- Overwriting "-Aunused" does not work any more HOT 3
- panic if TERM environment variable is "dumb" HOT 5
- Filter testcases by regex instead of by (sub)string HOT 1
- Move to Github Actions HOT 1
- Adding `bless` support HOT 2
- Can't run compiletests on Mac when `DYLD_LIBRARY_PATH` is unset or empty HOT 1
- Human-readable output HOT 1
- Moving repository out HOT 11
- Remove dependency on `test` crate HOT 1
- Unify with in-tree compiletest-rs HOT 7
- Adding a CHANGELOG
- Allow certain lints in `.fixed` compile test HOT 3
- does not build if HOST is not set HOT 1
- cd test-project && cargo +nightly hack test --feature-powerset fails with duplicate rlibs
- [Question] how do I get compiletest-rs to find the parent crate? HOT 2
- Cross-compilation support HOT 2
- allow for external diff tools
- Make `compiletest` build `std` when it runs
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from compiletest-rs.