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

Test functions should work when defined inside other functions #3532

Closed
brson opened this issue Sep 19, 2012 · 7 comments
Closed

Test functions should work when defined inside other functions #3532

brson opened this issue Sep 19, 2012 · 7 comments
Labels
A-frontend Area: Compiler frontend (errors, parsing and HIR) A-testsuite Area: The testsuite used to check the correctness of rustc E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot.

Comments

@brson
Copy link
Contributor

brson commented Sep 19, 2012

This doesn't work, but I frequently want to do it

fn foo() {

  ...

  #[test]
  fn test1() { }
}

The generated code for running test functions uses paths to the tests, and it's not possible to generate a path to test1. The test runner already breaks resolution rules to run private tests, so maybe we can break yet more.

We would want to consider though how this could work with reflection-based test runners - the way we currently break visibility rules to run tests is already bad news for reflection.

@graydon
Copy link
Contributor

graydon commented May 8, 2013

I would not be wholly opposed to permitting references to items inside functions this way. It's not like they do dynamic environment capture. But I suspect there's a namespace-theoretic reason why we can't (i.e. the reason for the type/module and value namespaces to be separate still exists?)

Alternatives to that seem to me like they'd be difficult to express in AST code without some even-more-odious magic (naming by defid?) and in any case, obvious workarounds exist and this bug is entirely backwards compatible if we ever make it work. I think this is probably far-future if anything.

I'm curious what you mean by reflection-based runners. Did you want to switch the test-running strategy to do that at some point? We don't really have a bug open for crate-structure reflection. Maybe we should!

@msullivan
Copy link
Contributor

Still unimplemented, still backwards compatible, still not pressing at all.

@brson
Copy link
Contributor Author

brson commented Jul 19, 2013

@graydon I would like to be able to load tests via reflection, yes, but at this point the model we've got is ok so I don't feel any pressing need.

@pnkfelix
Copy link
Member

pnkfelix commented Oct 1, 2013

visiting for triage, email from 2013 sep 30.

nominating for milestone "far future."

@catamorphism
Copy link
Contributor

de-nominated

@steveklabnik
Copy link
Member

What is the use-case for this feature? I'm curious.

@steveklabnik
Copy link
Member

I'm pulling a massive triage effort to get us ready for 1.0. As part of this, I'm moving stuff that's wishlist-like to the RFCs repo, as that's where major new things should get discussed/prioritized.

This issue has been moved to the RFCs repo: rust-lang/rfcs#612

RalfJung pushed a commit to RalfJung/rust that referenced this issue May 4, 2024
Tree Borrows: first apply transition, then check protector with new 'initialized'
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-frontend Area: Compiler frontend (errors, parsing and HIR) A-testsuite Area: The testsuite used to check the correctness of rustc E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot.
Projects
None yet
Development

No branches or pull requests

6 participants