Skip to content

Non-#[test] fns calling #[test] fns passes compiler with --test flag #2858

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

Closed
Havvy opened this issue Jul 10, 2012 · 7 comments
Closed

Non-#[test] fns calling #[test] fns passes compiler with --test flag #2858

Havvy opened this issue Jul 10, 2012 · 7 comments
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`) A-testsuite Area: The testsuite used to check the correctness of rustc

Comments

@Havvy
Copy link
Contributor

Havvy commented Jul 10, 2012

use std;

fn main () {
    nonTest()
}

fn nonTest() {
    anotherTest ()
}

#[test]
fn test () {
    nonTest()
}

#[test]
fn anotherTest () {

}

This code obviously doesn't compile without any flags, but it does compile with rustc --test.

From my perspective I cannot see why the parser allows nonTest to call anotherTest. Ever. Except in an example to show that it doesn't work.

Though, this is probably low priority.

@nikomatsakis
Copy link
Contributor

I think the proper way to detect this, if we want to, would be as a lint pass.

@brson
Copy link
Contributor

brson commented Jul 11, 2012

I'm not sure how to handle this. From (most of) the compiler's perspective a function marked with #[test] is just like a function marked with #[cfg(test)], so we would likely want to solve this for general conditional compilation, not just tests.

Functions that don't get compiled get stripped from the AST very early on, so I guess we would need to generate another side table of items that were removed from the AST. Then resolve could peek into that table when it fails.

@nikomatsakis
Copy link
Contributor

I figured that the warning would only be generated when running with --test. That is, if the functions get stripped out, then there will be an error anyhow. The warning is for the case where the functions were not stripped out but an error would result if they were.

@nikomatsakis
Copy link
Contributor

of course keeping a side table so we could give better error msgs would be nice, but it seems like a lot of complexity...you kind of have to run "what would resolve have done had these fns been present"

@brson
Copy link
Contributor

brson commented Jul 11, 2012

I see. Yeah, that would be easy to implement.

@pcwalton
Copy link
Contributor

Since this is a suggested lint pass, I don't believe this is backwards incompatible. Renominating.

@graydon
Copy link
Contributor

graydon commented Jun 6, 2013

closing WONTFIX, working as intended

@graydon graydon closed this as completed Jun 6, 2013
RalfJung pushed a commit to RalfJung/rust that referenced this issue Apr 28, 2023
Bump libffi-sys to 2.3.0

Bump libffi-sys to 2.3.0 that includes LoongArch support.

Thanks
RalfJung pushed a commit to RalfJung/rust that referenced this issue Apr 30, 2023
Bump libffi-sys to 2.3.0

Bump libffi-sys to 2.3.0 that includes LoongArch support.

Thanks
celinval pushed a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
Update to the latest Rust toolchain (2023-11-06).

The relevant changes are:
- rust-lang#117507: this required changing
the import of `Span` from `rustc_span::source_map::Span` to
`rustc_span::Span`.
- rust-lang#114208: this changed the data
field for the `OffsetOf` variant of `NullOp` from `List<FieldIdx>` to
`List<(VariantIdx, FieldIdx)>`, which required updating the relevant
code in `rvalue.rs`.
- rust-lang#115626: the unchecked shift
operators have been separated from the `unchecked_math` feature, so this
required changing the feature annotation in
`tests/ui/should-panic-attribute/unexpected-failures/test.rs`
- Some rustc change (not sure which one) result in a line in
`tests/coverage/unreachable/variant/main.rs` getting optimized out. To
maintain what this test is testing, I changed the `match` to make it a
bit less-prone to optimization.
- A change in `cargo` (rust-lang/cargo#12779)
resulted in an update to Kani's workspace `Cargo.toml` when `cargo add`
is executed inside `tests/script-based-pre/build-cache-bin`. This is
apparently intended behavior, so I had to make the `exclude` in the
`Cargo.toml` more specific to make sure this doesn't happen (I tried
using a glob, but that didn't work, apparently because of
rust-lang/cargo#6009.

Resolves rust-lang#2848 

By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache 2.0 and MIT licenses.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`) A-testsuite Area: The testsuite used to check the correctness of rustc
Projects
None yet
Development

No branches or pull requests

5 participants