Skip to content

tests/ui: A New Order [10/N] #142217

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

Open
wants to merge 9 commits into
base: master
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 7 additions & 0 deletions tests/ui/allocator/empty-alloc-deref-rvalue.rs
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
//! Test dereferencing empty allocation rvalues is safe
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Problem: I think this is actually a regression test for #13360, IOW it has nothing to do with this comment, but was rather testing that boxed (?) ZSTs don't get freed (?). This test also doesn't really have to do with allocator/. Maybe check if there's a similar test under tests/ui/box/, otherwise I'd move this test under tests/ui/box/ and repurpose this as a smoke test for checking that we can dereference a boxed ZST.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

something like?

//! Regression test for github.com/rust-lang/rust/issues/13360
//! dereferencing boxed zero-sized types should not cause improper deallocation


//@ run-pass

pub fn main() {
let _: () = *Box::new(());
}
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
// issue #20126
//! Regression test for issue #20126: Copy and Drop traits are mutually exclusive

#[derive(Copy, Clone)] //~ ERROR the trait `Copy` cannot be implemented
struct Foo;
Expand Down
Original file line number Diff line number Diff line change
@@ -1,11 +1,11 @@
error[E0184]: the trait `Copy` cannot be implemented for this type; the type has a destructor
--> $DIR/exclusive-drop-and-copy.rs:3:10
--> $DIR/copy-drop-mutually-exclusive.rs:3:10
|
LL | #[derive(Copy, Clone)]
| ^^^^ `Copy` not allowed on types with destructors

error[E0184]: the trait `Copy` cannot be implemented for this type; the type has a destructor
--> $DIR/exclusive-drop-and-copy.rs:10:10
--> $DIR/copy-drop-mutually-exclusive.rs:10:10
|
LL | #[derive(Copy, Clone)]
| ^^^^ `Copy` not allowed on types with destructors
Expand Down
7 changes: 0 additions & 7 deletions tests/ui/empty-allocation-rvalue-non-null.rs

This file was deleted.

24 changes: 0 additions & 24 deletions tests/ui/empty-type-parameter-list.rs

This file was deleted.

7 changes: 0 additions & 7 deletions tests/ui/error-should-say-copy-not-pod.rs

This file was deleted.

22 changes: 0 additions & 22 deletions tests/ui/error-should-say-copy-not-pod.stderr

This file was deleted.

13 changes: 0 additions & 13 deletions tests/ui/explicit-i-suffix.rs

This file was deleted.

2 changes: 0 additions & 2 deletions tests/ui/ext-nonexistent.rs

This file was deleted.

8 changes: 0 additions & 8 deletions tests/ui/ext-nonexistent.stderr

This file was deleted.

26 changes: 0 additions & 26 deletions tests/ui/fact.rs
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Discussion: this might be useful as a control-flow smoke test, but it would need to //@ check-run-results and uncomment out the printlns to be of any actual value.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we can keep this if you think so, but in my opinion this is very simple test, and we already have more complex recursive tests

This file was deleted.

32 changes: 32 additions & 0 deletions tests/ui/generics/empty-generic-brackets-equiv.rs
Original file line number Diff line number Diff line change
@@ -0,0 +1,32 @@
//! Test that empty type parameter list <> is equivalent to no type parameters
//!
//! Verifies that empty angle brackets <> are syntactically valid and equivalent
//! to omitting type parameters entirely across various language constructs.

//@ run-pass

struct S;
trait T {} //~ WARN trait `T` is never used
enum E {
V,
}

impl T for S {}
impl T for E {}

fn foo() {}
fn bar() {}

fn main() {
let _ = S;
let _ = S;
let _ = E::V;
let _ = E::V;

foo();
foo();

// Test that we can supply <> to non-generic things
bar();
let _: i32;
}
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
warning: trait `T` is never used
--> $DIR/empty-type-parameter-list.rs:6:7
--> $DIR/empty-generic-brackets-equiv.rs:9:7
|
LL | trait T<> {}
LL | trait T {}
| ^
|
= note: `#[warn(dead_code)]` on by default
Expand Down
Original file line number Diff line number Diff line change
@@ -1,3 +1,5 @@
//! Test nested macro expansion with concat! macros

//@ run-pass

static FOO : &'static str = concat!(concat!("hel", "lo"), "world");
Expand Down
6 changes: 6 additions & 0 deletions tests/ui/macros/nonexistent-macro.rs
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question: do we not have a tests/ui/resolve/ test that checks undefined macros are rejected? 🤔

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suprisingly but no, we dont have anything like this in resolve

maximum that ive found is

//@ edition:2018

foo!(); //~ ERROR cannot find macro `foo` in this scope

pub(in ::bar) struct Baz {} //~ ERROR cannot determine resolution for the visibility

fn main() {}

Original file line number Diff line number Diff line change
@@ -0,0 +1,6 @@
//! Test error handling for undefined macro calls

fn main() {
iamnotanextensionthatexists!("");
//~^ ERROR cannot find macro `iamnotanextensionthatexists` in this scope
}
8 changes: 8 additions & 0 deletions tests/ui/macros/nonexistent-macro.stderr
Original file line number Diff line number Diff line change
@@ -0,0 +1,8 @@
error: cannot find macro `iamnotanextensionthatexists` in this scope
--> $DIR/nonexistent-macro.rs:4:5
|
LL | iamnotanextensionthatexists!("");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to 1 previous error

133 changes: 133 additions & 0 deletions tests/ui/stability-attribute/auxiliary/pub-and-stability.rs
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question: I'm slightly confused, where did this file come from?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is from tests/ui/auxiliary

Original file line number Diff line number Diff line change
@@ -0,0 +1,133 @@
// This crate attempts to enumerate the various scenarios for how a
// type can define fields and methods with various visibilities and
// stabilities.
//
// The basic stability pattern in this file has four cases:
// 1. no stability attribute at all
// 2. a stable attribute (feature "unit_test")
// 3. an unstable attribute that unit test enables (feature "unstable_declared")
// 4. an unstable attribute that unit test fails to enable (feature "unstable_undeclared")
//
// This file also covers four kinds of visibility: private,
// pub(module), pub(crate), and pub.
//
// However, since stability attributes can only be observed in
// cross-crate linkage scenarios, there is little reason to take the
// cross-product (4 stability cases * 4 visibility cases), because the
// first three visibility cases cannot be accessed outside this crate,
// and therefore stability is only relevant when the visibility is pub
// to the whole universe.
//
// (The only reason to do so would be if one were worried about the
// compiler having some subtle bug where adding a stability attribute
// introduces a privacy violation. As a way to provide evidence that
// this is not occurring, I have put stability attributes on some
// non-pub fields, marked with SILLY below)

#![feature(staged_api)]

#![stable(feature = "unit_test", since = "1.0.0")]

#[stable(feature = "unit_test", since = "1.0.0")]
pub use m::{Record, Trait, Tuple};

mod m {
#[derive(Default)]
#[stable(feature = "unit_test", since = "1.0.0")]
pub struct Record {
#[stable(feature = "unit_test", since = "1.0.0")]
pub a_stable_pub: i32,
#[unstable(feature = "unstable_declared", issue = "38412")]
pub a_unstable_declared_pub: i32,
#[unstable(feature = "unstable_undeclared", issue = "38412")]
pub a_unstable_undeclared_pub: i32,
#[unstable(feature = "unstable_undeclared", issue = "38412")] // SILLY
pub(crate) b_crate: i32,
#[unstable(feature = "unstable_declared", issue = "38412")] // SILLY
pub(in crate::m) c_mod: i32,
#[stable(feature = "unit_test", since = "1.0.0")] // SILLY
d_priv: i32
}

#[derive(Default)]
#[stable(feature = "unit_test", since = "1.0.0")]
pub struct Tuple(
#[stable(feature = "unit_test", since = "1.0.0")]
pub i32,
#[unstable(feature = "unstable_declared", issue = "38412")]
pub i32,
#[unstable(feature = "unstable_undeclared", issue = "38412")]
pub i32,

pub(crate) i32,
pub(in crate::m) i32,
i32);

impl Record {
#[stable(feature = "unit_test", since = "1.0.0")]
pub fn new() -> Self { Default::default() }
}

impl Tuple {
#[stable(feature = "unit_test", since = "1.0.0")]
pub fn new() -> Self { Default::default() }
}


#[stable(feature = "unit_test", since = "1.0.0")]
pub trait Trait {
#[stable(feature = "unit_test", since = "1.0.0")]
type Type;
#[stable(feature = "unit_test", since = "1.0.0")]
fn stable_trait_method(&self) -> Self::Type;
#[unstable(feature = "unstable_undeclared", issue = "38412")]
fn unstable_undeclared_trait_method(&self) -> Self::Type;
#[unstable(feature = "unstable_declared", issue = "38412")]
fn unstable_declared_trait_method(&self) -> Self::Type;
}

#[stable(feature = "unit_test", since = "1.0.0")]
impl Trait for Record {
type Type = i32;
fn stable_trait_method(&self) -> i32 { self.d_priv }
fn unstable_undeclared_trait_method(&self) -> i32 { self.d_priv }
fn unstable_declared_trait_method(&self) -> i32 { self.d_priv }
}

#[stable(feature = "unit_test", since = "1.0.0")]
impl Trait for Tuple {
type Type = i32;
fn stable_trait_method(&self) -> i32 { self.3 }
fn unstable_undeclared_trait_method(&self) -> i32 { self.3 }
fn unstable_declared_trait_method(&self) -> i32 { self.3 }
}

impl Record {
#[unstable(feature = "unstable_undeclared", issue = "38412")]
pub fn unstable_undeclared(&self) -> i32 { self.d_priv }
#[unstable(feature = "unstable_declared", issue = "38412")]
pub fn unstable_declared(&self) -> i32 { self.d_priv }
#[stable(feature = "unit_test", since = "1.0.0")]
pub fn stable(&self) -> i32 { self.d_priv }

#[unstable(feature = "unstable_undeclared", issue = "38412")] // SILLY
pub(crate) fn pub_crate(&self) -> i32 { self.d_priv }
#[unstable(feature = "unstable_declared", issue = "38412")] // SILLY
pub(in crate::m) fn pub_mod(&self) -> i32 { self.d_priv }
#[stable(feature = "unit_test", since = "1.0.0")] // SILLY
fn private(&self) -> i32 { self.d_priv }
}

impl Tuple {
#[unstable(feature = "unstable_undeclared", issue = "38412")]
pub fn unstable_undeclared(&self) -> i32 { self.0 }
#[unstable(feature = "unstable_declared", issue = "38412")]
pub fn unstable_declared(&self) -> i32 { self.0 }
#[stable(feature = "unit_test", since = "1.0.0")]
pub fn stable(&self) -> i32 { self.0 }

pub(crate) fn pub_crate(&self) -> i32 { self.0 }
pub(in crate::m) fn pub_mod(&self) -> i32 { self.0 }
fn private(&self) -> i32 { self.0 }
}
}
Loading
Loading