fix(parser): Disallow CR in frontmatter
T-lang came back on the stabilization PR (rust-lang/rust#148051) asking for CR to be disallowed
to leave room for all stray CRs to be rejected in the future.
At that point, the test can remain but the implementation can be
removed.
If that plan does not go through, we'll need to re-evaluate
- whether this is more lint-like and should defer to the calling tool
that is managing the frontmatter
- how much Rust should treat the frontmatter as Rust and apply the same
grammar restrictions of "no stray CR" (like raw string literals)
Part of rust-lang/rust#136889
T-lang came back on the stabilization PR asking for CR to be disallowed
to leave room for all stray CRs to be rejected in the future.
At that point, the test can remain but the implementation can be
removed.
If that plan does not go through, we'll need to re-evaluate
- whether this is more lint-like and should defer to the calling tool
that is managing the frontmatter
- how much Rust should treat the frontmatter as Rust and apply the same
grammar restrictions of "no stray CR" (like raw string literals)
Based on earlier work by León Orell Valerian Liehr.
Co-authored-by: León Orell Valerian Liehr <me@fmease.dev>
Signed-off-by: Usman Akinyemi <uniqueusman@archlinux>
`const` blocks as a `mod` item
Tracking issue: rust-lang/rust#149226
This adds support for writing `const { ... }` as an item in a module. In the current implementation, this is a unique AST item that gets lowered to `const _: () = const { ... };` in HIR.
rustfmt support included.
TODO:
- `pub const { ... }` does not make sense (see rust-lang/rust#147136). Reject it. Should this be rejected by the parser or smth?
- Improve diagnostics (preferably they should not mention the fake `_` ident).
Do not recover from `Trait()` if generic list is unterminated
If we encounter `fn foo<T: Trait()`, the recovery logic would it as if `Trait` was intended to use the Fn-like trait syntax, but if we don't know for certain that we've parsed a full trait bound (`fn foo<T: Trait()>`), we bail from the recovery as more likely there could have been a missing closing `>` and the `(` corresponds to the start of the fn parameter list.
Fixrust-lang/rust#141436.
If we encounter `fn foo<T: Trait()`, the recovery logic would it as if `Trait` was intended to use the Fn-like trait syntax, but if we don't know for certain that we've parsed a full trait bound (`fn foo<T: Trait()>`), we bail from the recovery as more likely there could have been a missing closing `>` and the `(` corresponds to the start of the fn parameter list.
Recover parse gracefully from `<const N>`
When a const param doesn't have a `: Type`, recover the parser state and provide a structured suggestion. This not only provides guidance on what was missing, but it also makes subsuequent errors to be emitted that would otherwise be silenced.
```
error: expected `:`, found `>`
--> $DIR/incorrect-const-param.rs:26:16
|
LL | impl<T, const N> From<[T; N]> for VecWrapper<T>
| ^ expected `:`
|
help: you might have meant to write the type of the const parameter here
|
LL | impl<T, const N: /* Type */> From<[T; N]> for VecWrapper<T>
| ++++++++++++
```
r? @fmease
Follow up to rust-lang/rust#151077. Fixrust-lang/rust#84327.
Don't try to recover keyword as non-keyword identifier
Fixesrust-lang/rust#149692.
On beta after rust-lang/rust#146978, we ICE on
```rs
macro_rules! m {
($id:item()) => {}
}
m!(Self());
```
where `Self` in the macro invocation is a keyword not a "normal" identifier, while attempting to recover an missing keyword before an identifier. Except, `Self` *is* a keyword, so trying to parse that as a non-reserved identifier expectedly fails.
I suspect rust-lang/rust#146978 merely unmasked a possible code path to hit this case; this logic has been so for a good while. Previously, on stable, the error message looks something like
```rs
error: expected identifier, found keyword `Self`
--> src/lib.rs:5:4
|
5 | m!(Self());
| ^^^^ expected identifier, found keyword
error: missing `fn` or `struct` for function or struct definition
--> src/lib.rs:5:4
|
2 | ($id:item()) => {}
| -------- while parsing argument for this `item` macro fragment
...
5 | m!(Self());
| ^^^^
|
help: if you meant to call a macro, try
|
5 | m!(Self!());
| +
```
I considered restoring this diagnostic, but I'm not super convinced it's worth the complexity (and to me, it's not super clear what the user actually intended here).
When a const param doesn't have a `: Type`, recover the parser state and provide a structured suggestion. This not only provides guidance on what was missing, but it also makes subsuequent errors to be emitted that would otherwise be silenced.
```
error: expected `:`, found `>`
--> $DIR/incorrect-const-param.rs:26:16
|
LL | impl<T, const N> From<[T; N]> for VecWrapper<T>
| ^ expected `:`
|
help: you might have meant to write the type of the const parameter here
|
LL | impl<T, const N: /* Type */> From<[T; N]> for VecWrapper<T>
| ++++++++++++
```
feat: invisible character help string
I was playing around with zero width spaces in different programming languages and thought that this error message could be more helpful. Hopefully it's a good first contribution! :)
enrich error info when tries to dlopen Enzyme
In rust-lang/rust#127273 I added a test and a FIXME comment pointing out how it does the wrong thing. In the next commit I fixed the problem but forgot to remove the FIXME comment, whoops.
In #127273 I added a test and a FIXME comment pointing out how it does
the wrong thing. In the next commit I fixed the problem but forgot to
remove the FIXME comment, whoops.
Use more principled check for generics in const ops
Fixesrust-lang/rust#144547.
Fixesrust-lang/rust#140891.
In the future, we likely want to make the check less likely to be missed by reducing the number of external entry points to HIR type lowering.
Note: If this causes pass->error regressions (not truly regressions because those cases were mistakenly accepted), they can easily be avoided for the time being by only running the check if `is_self_alias` is true or mgca is enabled.
- **Fix parsing of mgca const blocks in array repeat exprs**
- **Use more principled check for generics in const ops**
There was an inconsistency where in the case of array repeat
expressions, we forgot to eat the `const` keyword of mgca const blocks.
Thus, we ended up parsing them as an anon const containing an inline
const, instead of simply an anon const as they should be.
This commit fixes that issue and also makes the parsing for mgca const
blocks more consistent and simpler in general. For example, we avoid
doing a lookahead check to ensure there's a curly brace coming. There
should always be one after a `const` keyword in an expression context,
and that's handled by the mgca const block parsing function.
Fix ICE by rejecting const blocks in patterns during AST lowering (closes#148138)
This PR fixes the ICE reported in rust-lang/rust#148138.
The root cause is that `const` blocks aren’t allowed in pattern position, but the AST lowering logic still attempted to create `PatExprKind::ConstBlock`, allowing invalid HIR to reach type checking and trigger a `span_bug!`.
Following the discussion in the issue, this patch removes the `ConstBlock` lowering path from `lower_expr_within_pat`. Any `ExprKind::ConstBlock` inside a pattern is now handled consistently with other invalid pattern expressions.
A new UI test is included to ensure the compiler reports a proper error and to prevent regressions.
Closesrust-lang/rust#148138.
parser/lexer: bump to Unicode 17, use faster unicode-ident
Hello,
Bump the unicode version used by lexer/parser to 17.0.0 by updating:
- `unicode-normalization` to 0.1.25
- `unicode-properties` to 0.1.4
- `unicode-width` to 0.2.2
and by replacing `unicode-xid` with `unicode-ident` which is also 6 times faster.
I think it might be worth to run the benchmarks to double check.
(`unicode-ident` is already in `src/tools/tidy/src/deps.rs`)
Thanks!
Don't use `matches!` when `==` suffices
In the codebase we sometimes use `matches!` for values that can actually just be compared. Replace them with `==`.
Subset of rust-lang/rust#149933.
Add a compile time check in rustc_lexer and rustc_parse ensuring that unicode-related dependencies within the crate use the same unicode version.
These checks are inspired by the examples privided by @clarfonthey.
This fixes the ICE reported by rejecting `const` blocks in
pattern position during AST lowering.
Previously, `ExprKind::ConstBlock` could reach HIR as `PatExprKind::ConstBlock`,
allowing invalid patterns to be type-checked and triggering an ICE.
This patch removes the lowering path for const blocks in patterns
and emits a proper diagnostic instead.
A new UI test is added to ensure the compiler reports a regular error
and to prevent regressions.
Externally implementable items
Supersedes https://github.com/rust-lang/rust/pull/140010
Tracking issue: https://github.com/rust-lang/rust/issues/125418
Getting started:
```rust
#![feature(eii)]
#[eii(eii1)]
pub fn decl1(x: u64)
// body optional (it's the default)
{
println!("default {x}");
}
// in another crate, maybe
#[eii1]
pub fn decl2(x: u64) {
println!("explicit {x}");
}
fn main() {
decl1(4);
}
```
- tiny perf regression, underlying issue makes multiple things in the compiler slow, not just EII, planning to solve those separately.
- No codegen_gcc support, they don't have bindings for weak symbols yet but could
- No windows support yet for weak definitions
This PR merges the implementation of EII for just llvm + not windows, doesn't yet contain like a new panic handler implementation or alloc handler. With this implementation, it would support implementing the panic handler in terms of EII already since it requires no default implementation so no weak symbols
The PR has been open in various forms for about a year now, but I feel that having some implementation merged to build upon
