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

Remove __rust_force_expr. #126929

Merged
merged 1 commit into from
Jun 27, 2024
Merged
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
18 changes: 4 additions & 14 deletions library/alloc/src/macros.rs
Original file line number Diff line number Diff line change
Expand Up @@ -41,18 +41,18 @@
#[allow_internal_unstable(rustc_attrs, liballoc_internals)]
macro_rules! vec {
() => (
$crate::__rust_force_expr!($crate::vec::Vec::new())
$crate::vec::Vec::new()
);
($elem:expr; $n:expr) => (
$crate::__rust_force_expr!($crate::vec::from_elem($elem, $n))
$crate::vec::from_elem($elem, $n)
);
($($x:expr),+ $(,)?) => (
$crate::__rust_force_expr!(<[_]>::into_vec(
<[_]>::into_vec(
// This rustc_box is not required, but it produces a dramatic improvement in compile
// time when constructing arrays with many elements.
#[rustc_box]
$crate::boxed::Box::new([$($x),+])
))
)
);
}

Expand Down Expand Up @@ -126,13 +126,3 @@ macro_rules! format {
res
}}
}

/// Force AST node to an expression to improve diagnostics in pattern position.
#[doc(hidden)]
#[macro_export]
#[unstable(feature = "liballoc_internals", issue = "none", reason = "implementation detail")]
macro_rules! __rust_force_expr {
($e:expr) => {
$e
};
}
2 changes: 1 addition & 1 deletion tests/ui/macros/vec-macro-in-pattern.rs
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@

fn main() {
match Some(vec![42]) {
Some(vec![43]) => {} //~ ERROR arbitrary expressions aren't allowed in patterns
Some(vec![43]) => {} //~ ERROR expected pattern, found `#`
Copy link
Contributor

@klensy klensy Jun 26, 2024

Choose a reason for hiding this comment

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

Now that error not very helpful, as there no # in test source code. Error message refers to expanded code?

_ => {}
}
}
7 changes: 5 additions & 2 deletions tests/ui/macros/vec-macro-in-pattern.stderr
Original file line number Diff line number Diff line change
@@ -1,10 +1,13 @@
error: arbitrary expressions aren't allowed in patterns
error: expected pattern, found `#`
--> $DIR/vec-macro-in-pattern.rs:7:14
|
LL | Some(vec![43]) => {}
| ^^^^^^^^
| |
| expected pattern
| in this macro invocation
| this macro call doesn't expand to a pattern
|
Copy link
Contributor

Choose a reason for hiding this comment

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

hmm... does the compiler know what it expands to?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't understand the question. Are you suggesting changing the error message?

Copy link
Contributor

Choose a reason for hiding this comment

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

well, I was wondering if we even have the information reliably to change the error message to "this macro call expands to an expression, not a pattern"

Copy link
Contributor Author

@nnethercote nnethercote Jun 26, 2024

Choose a reason for hiding this comment

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

Let's see... the error is emitted by annotate_err_with_kind, which is called in this case from emit_frag_parse_err, which is called from ParserAnyMacro::make after the call to parse_ast_fragment fails.

I think it's hard to do what you suggest. We try to parse as a pattern and when that fails there's no easy way to determine what we actually had instead of a pattern, short of reparsing it in a bunch of different ways to see if anything succeeds, which feels clumsy.

Copy link
Contributor

Choose a reason for hiding this comment

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

yea no, that's wrong. Thanks for checking

= note: the `expr` fragment specifier forces the metavariable's content to be an expression
= note: this error originates in the macro `vec` (in Nightly builds, run with -Z macro-backtrace for more info)

error: aborting due to 1 previous error
Expand Down
Loading