Skip to content

Using the #[start] attribute causes --test to be silently ignored #11766

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
nmsmith opened this issue Jan 24, 2014 · 3 comments
Closed

Using the #[start] attribute causes --test to be silently ignored #11766

nmsmith opened this issue Jan 24, 2014 · 3 comments
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`)

Comments

@nmsmith
Copy link

nmsmith commented Jan 24, 2014

Example:

#[test]
fn test() {
    assert!(false);
}

#[start]
fn start(argc: int, argv: **u8) -> int {
    return 1;
}

Running rustc with the --test flag here causes compilation to occur as if it wasn't used.

@steveklabnik
Copy link
Member

This sample is now

#[start]
fn start(_argc: int, _argv: *const *const u8) -> int {
    0
}

But it still does ignore the --test.

@steveklabnik
Copy link
Member

A warning might be appropriate here, as @klutzy suggests. maybe a lint.

@frewsxcv
Copy link
Member

Visiting for triage: this is still an issue

coreyf@frewbook-air /tmp> cat hello-world.rs
#![feature(start)]

#[test]
fn test() {
    assert!(false);
}

#[start]
fn start(_argc: isize, _argv: *const *const u8) -> isize {
    0
}
coreyf@frewbook-air /tmp> rustc --test hello-world.rs
coreyf@frewbook-air /tmp> echo $status
0
coreyf@frewbook-air /tmp> ./hello-world
coreyf@frewbook-air /tmp> echo $status
0

wthrowe added a commit to wthrowe/rust that referenced this issue Aug 25, 2015
bors added a commit that referenced this issue Aug 26, 2015
* Suppresses warnings that main is unused when testing (#12327)
* Makes `--test` work with explicit `#[start]` (#11766)
* Fixes some cases where the normal main would not be disabled by `--test`, resulting in compilation failures.
bors added a commit to rust-lang-ci/rust that referenced this issue Jul 25, 2022
fix(extract_module) resolving import panics and improve import resolution

- Should solve rust-lang#11766
- While adding a test case for this issue, I observed another issue:
For this test case:
```rust
            mod x {
                pub struct Foo;
                pub struct Bar;
            }

            use x::{Bar, Foo};

            $0type A = (Foo, Bar);$0
```
extract module should yield this:

```rust
            mod x {
                pub struct Foo;
                pub struct Bar;
            }

            use x::{};

            mod modname {
                use super::x::Bar;

                use super::x::Foo;

                pub(crate) type A = (Foo, Bar);
            }
```

instead it gave:

```rust
            mod x {
                pub struct Foo;
                pub struct Bar;
            }

            use x::{};

            mod modname {
                use x::Bar;

                use x::Foo;

                pub(crate) type A = (Foo, Bar);
            }
```

So fixed this problem with second commit
flip1995 pushed a commit to flip1995/rust that referenced this issue Jan 25, 2024
`read_zero_byte_vec` refactor for better heuristics

Fixes rust-lang#9274

Previously, the implementation of `read_zero_byte_vec` only checks for the next statement after the vec init. This fails when there is a block with statements that are expanded and walked by the old visitor.

This PR refactors so that:

1. It checks if there is a `resize`	on the vec
2. It works on blocks properly

e.g. This should properly lint now:

```
    let mut v = Vec::new();
    {
        f.read(&mut v)?;
        //~^ ERROR: reading zero byte data to `Vec`
    }
```

changelog: [`read_zero_byte_vec`] Refactored for better heuristics
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`)
Projects
None yet
Development

No branches or pull requests

3 participants