Mirrors/rust
1
0
Fork 0
mirror of https://github.com/rust-lang/rust.git synced 2026-04-30 06:43:20 +03:00
Code Issues Packages Projects Releases Wiki Activity
263,622 Commits 10 Branches 157 Tags
080c2ca2dcdf38f9337f0aedaa166ec6fbebd681
Commit Graph

2025 Commits

Author SHA1 Message Date
Guillaume Gomez 99a785d62d Rollup merge of #128994 - nnethercote:fix-Parser-look_ahead-more, r=compiler-errors 
Fix bug in `Parser::look_ahead`.

The special case was failing to handle invisible delimiters on one path.

Fixes (but doesn't close until beta backported) #128895.

r? `@davidtwco`
 2024-08-12 17:09:20 +02:00
Guillaume Gomez 7c6dca9050 Rollup merge of #128978 - compiler-errors:assert-matches, r=jieyouxu 
Use `assert_matches` around the compiler more

It's a useful assertion, especially since it actually prints out the LHS.
 2024-08-12 17:09:19 +02:00
Nicholas Nethercote 46b4c5adc5 Fix bug in Parser::look_ahead. 
The special case was failing to handle invisible delimiters on one path.

Fixes #128895.
 2024-08-12 13:00:12 +10:00
Michael Goulet c361c924a0 Use assert_matches around the compiler 2024-08-11 12:25:39 -04:00
Matthias Krüger 32e0fe129d Rollup merge of #128762 - fmease:use-more-slice-pats, r=compiler-errors 
Use more slice patterns inside the compiler

Nothing super noteworthy. Just replacing the common 'fragile' pattern of "length check followed by indexing or unwrap" with slice patterns for legibility and 'robustness'.

r? ghost
 2024-08-11 07:51:51 +02:00
许杰友 Jieyou Xu (Joe) d65f1316bb parser: ensure let stmt compound assignment removal suggestion respect codepoint boundaries 
Previously we would try to issue a suggestion for `let x <op>= 1`, i.e.
a compound assignment within a `let` binding, to remove the `<op>`. The
suggestion code unfortunately incorrectly assumed that the `<op>` is an
exactly-1-byte ASCII character, but this assumption is incorrect because
we also recover Unicode-confusables like `➖=` as `-=`. In this example,
the suggestion code used a `+ BytePos(1)` to calculate the span of the
`<op>` codepoint that looks like `-` but the mult-byte Unicode
look-alike would cause the suggested removal span to be inside a
multi-byte codepoint boundary, triggering a codepoint boundary
assertion.

Issue: <https://github.com/rust-lang/rust/issues/128845>
 2024-08-09 05:56:50 +00:00
León Orell Valerian Liehr c4c518d2d4 Use more slice patterns inside the compiler 2024-08-07 13:37:52 +02:00
Matthias Krüger 7d9ed2a864 Rollup merge of #127921 - spastorino:stabilize-unsafe-extern-blocks, r=compiler-errors 
Stabilize unsafe extern blocks (RFC 3484)

# Stabilization report

## Summary

This is a tracking issue for the RFC 3484: Unsafe Extern Blocks

We are stabilizing `#![feature(unsafe_extern_blocks)]`, as described in [Unsafe Extern Blocks RFC 3484](https://github.com/rust-lang/rfcs/pull/3484). This feature makes explicit that declaring an extern block is unsafe. Starting in Rust 2024, all extern blocks must be marked as unsafe. In all editions, items within unsafe extern blocks may be marked as safe to use.

RFC: https://github.com/rust-lang/rfcs/pull/3484
Tracking issue: #123743

## What is stabilized

### Summary of stabilization

We now need extern blocks to be marked as unsafe and items inside can also have safety modifiers (unsafe or safe), by default items with no modifiers are unsafe to offer easy migration without surprising results.

```rust
unsafe extern {
    // sqrt (from libm) may be called with any `f64`
    pub safe fn sqrt(x: f64) -> f64;

    // strlen (from libc) requires a valid pointer,
    // so we mark it as being an unsafe fn
    pub unsafe fn strlen(p: *const c_char) -> usize;

    // this function doesn't say safe or unsafe, so it defaults to unsafe
    pub fn free(p: *mut core::ffi::c_void);

    pub safe static IMPORTANT_BYTES: [u8; 256];

    pub safe static LINES: SyncUnsafeCell<i32>;
}
```

## Tests

The relevant tests are in `tests/ui/rust-2024/unsafe-extern-blocks`.

## History

- https://github.com/rust-lang/rust/pull/124482
- https://github.com/rust-lang/rust/pull/124455
- https://github.com/rust-lang/rust/pull/125077
- https://github.com/rust-lang/rust/pull/125522
- https://github.com/rust-lang/rust/issues/126738
- https://github.com/rust-lang/rust/issues/126749
- https://github.com/rust-lang/rust/issues/126755
- https://github.com/rust-lang/rust/pull/126757
- https://github.com/rust-lang/rust/pull/126758
- https://github.com/rust-lang/rust/issues/126756
- https://github.com/rust-lang/rust/pull/126973
- https://github.com/rust-lang/rust/pull/127535
- https://github.com/rust-lang/rustfmt/pull/6204

## Unresolved questions

I am not aware of any unresolved questions.
 2024-08-03 20:51:51 +02:00
Matthias Krüger dee57ce043 Rollup merge of #128483 - nnethercote:still-more-cfg-cleanups, r=petrochenkov 
Still more `cfg` cleanups

Found while looking closely at `cfg`/`cfg_attr` processing code.

r? `````````@petrochenkov`````````
 2024-08-03 11:17:44 +02:00
Matthias Krüger 29cd3103a1 Rollup merge of #128496 - clubby789:box-syntax-multipart, r=compiler-errors 
Fix removed `box_syntax` diagnostic if source isn't available

Fix #128442
 2024-08-01 18:43:41 +02:00
clubby789 e157954cce Fix removed box_syntax diagnostic if source isn't available 2024-08-01 13:11:24 +00:00
bors c0e32983f5 Auto merge of #127543 - carbotaniuman:more_unsafe_attr_verification, r=estebank,traviscross 
More unsafe attr verification

This code denies unsafe on attributes such as `#[test]` and `#[ignore]`, while also changing the `MetaItem` parsing so `unsafe` in args like `#[allow(unsafe(dead_code))]` is not accidentally allowed.

Tracking:

- https://github.com/rust-lang/rust/issues/123757
 2024-08-01 10:40:45 +00:00
Nicholas Nethercote d1f05fd184 Distinguish the two kinds of token range. 
When collecting tokens there are two kinds of range:
- a range relative to the parser's full token stream (which we get when
  we are parsing);
- a range relative to a single AST node's token stream (which we use
  within `LazyAttrTokenStreamImpl` when replacing tokens).

These are currently both represented with `Range<u32>` and it's easy to
mix them up -- until now I hadn't properly understood the difference.

This commit introduces `ParserRange` and `NodeRange` to distinguish
them. This also requires splitting `ReplaceRange` in two, giving the new
types `ParserReplacement` and `NodeReplacement`. (These latter two names
reduce the overloading of the word "range".)

The commit also rewrites some comments to be clearer.

The end result is a little more verbose, but much clearer.
 2024-08-01 19:30:40 +10:00
Nicholas Nethercote 9d77d17f71 Move a comment to a better spot. 2024-08-01 19:30:39 +10:00
Nicholas Nethercote 2eb2ef1684 Streamline attribute stitching on AST nodes. 
It can be done more concisely.
 2024-08-01 19:30:32 +10:00
Matthias Krüger 3acd910036 Rollup merge of #126697 - vincenzopalazzo:macros/find_the_expression_tok, r=eholk,compiler-errors 
[RFC] mbe: consider the `_` in 2024 an expression

This commit is adding the possibility to parse the `_` as an expression inside the esition 2024.

Link: https://rust-lang.zulipchat.com/#narrow/stream/404510-wg-macros/topic/supporting.20.60_.60.20expressions

Issue https://github.com/rust-lang/rust/issues/123742

r? `@eholk`
 2024-07-31 23:20:09 +02:00
Michael Goulet 79ef91e879 tweak comment on NonterminalKind::Expr 
Co-authored-by: Eric Holk <eric@theincredibleholk.org>
 2024-07-31 15:37:55 -04:00
Vincenzo Palazzo 276fa19c0a rustc_parser: consider the in 2024 an expression 
This commit is adding the possibility to parse the `_` as
an expression inside the esition 2024.

Link: https://rust-lang.zulipchat.com/#narrow/stream/404510-wg-macros/topic/supporting.20.60_.60.20expressions
Co-authored-by: Eric Holk <eric@theincredibleholk.org>
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
 2024-07-31 18:34:22 +00:00
Nicholas Nethercote fe647f0538 Remove LhsExpr. 
`parse_expr_assoc_with` has an awkward structure -- sometimes the lhs is
already parsed. This commit splits the post-lhs part into a new method
`parse_expr_assoc_rest_with`, which makes everything shorter and
simpler.
 2024-07-31 12:56:25 +10:00
Nicholas Nethercote 281c2fd5bf Inline and remove parse_local_mk. 
It has a single use. This makes the `let` handling case in
`parse_stmt_without_recovery` more similar to the statement path and
statement expression cases.
 2024-07-31 12:08:55 +10:00
carbotaniuman 49db8a5a99 Add toggle for parse_meta_item unsafe parsing 
This makes it possible for the `unsafe(...)` syntax to only be
valid at the top level, and the `NestedMetaItem`s will automatically
reject `unsafe(...)`.
 2024-07-30 18:28:43 -05:00
Matthias Krüger 6f0b237c72 Rollup merge of #128376 - compiler-errors:finish-ur-vegetables, r=jieyouxu 
Mark `Parser::eat`/`check` methods as `#[must_use]`

These methods return a `bool`, but we probably should either use these values or explicitly throw them away (e.g. when we just want to unconditionally eat a token if it exists).

I changed a few places from `eat` to `expect`, but otherwise I tried to leave a comment explaining why the `eat` was okay.

This also adds a test for the `pattern_type!` macro, which used to silently accept a missing `is` token.
 2024-07-30 22:51:38 +02:00
bors f8060d282d Auto merge of #128083 - Mark-Simulacrum:bump-bootstrap, r=albertlarsan68 
Bump bootstrap compiler to new beta

https://forge.rust-lang.org/release/process.html#master-bootstrap-update-t-2-day-tuesday
 2024-07-30 17:49:08 +00:00
bors 595316b400 Auto merge of #127955 - chenyukang:yukang-fix-mismatched-delimiter-issue-12786, r=nnethercote 
Add limit for unclosed delimiters in lexer diagnostic

Fixes #127868

The first commit shows the original diagnostic, and the second commit shows the changes.
 2024-07-30 13:02:16 +00:00
carbotaniuman d8bc8761a5 Deny unsafe on more builtin attributes 2024-07-29 21:00:09 -05:00
Michael Goulet e4076e34f8 Mark Parser::eat/check methods as must_use 2024-07-29 21:29:08 -04:00
Nicholas Nethercote 84ac80f192 Reformat use declarations. 
The previous commit updated `rustfmt.toml` appropriately. This commit is
the outcome of running `x fmt --all` with the new formatting options.
 2024-07-29 08:26:52 +10:00
Mark Rousskov 5eca36d27a step cfg(bootstrap) 2024-07-28 14:46:29 -04:00
Trevor Gross 9164dbd48c Rollup merge of #128207 - folkertdev:asm-parser-generalize, r=Amanieu 
improve error message when `global_asm!` uses `asm!` options

specifically, what was

    error: expected one of `)`, `att_syntax`, or `raw`, found `preserves_flags`
      --> $DIR/bad-options.rs:45:25
       |
    LL | global_asm!("", options(preserves_flags));
       |                         ^^^^^^^^^^^^^^^ expected one of `)`, `att_syntax`, or `raw`

is now

    error: the `preserves_flags` option cannot be used with `global_asm!`
      --> $DIR/bad-options.rs:45:25
       |
    LL | global_asm!("", options(preserves_flags));
       |                         ^^^^^^^^^^^^^^^ the `preserves_flags` option is not meaningful for global-scoped inline assembly

mirroring the phrasing of the [reference](https://doc.rust-lang.org/reference/inline-assembly.html#options).

This is also a bit of a refactor for a future `naked_asm!` macro (for use in `#[naked]` functions). Currently this sort of error can come up when switching from inline to global asm, or when a user just isn't that experienced with assembly. With  `naked_asm!` added to the mix hitting this error is more likely.
 2024-07-27 13:32:56 -04:00
Trevor Gross 7eaf74743b Rollup merge of #128229 - tdittr:unsafe-extern-abi-error, r=compiler-errors 
Improve `extern "<abi>" unsafe fn()` error message

These errors were already reported in #87217, and fixed by #87235 but missed the case of an explicit ABI.

This PR does not cover multiple keywords like `extern "C" pub const unsafe fn()`, but I don't know what a good way to cover this  would be. It also seems rarer than `extern "C" unsafe` which I saw happen a few times in workshops.
 2024-07-26 19:03:08 -04:00
Trevor Gross af52be2cea Rollup merge of #128224 - nnethercote:fewer-replace_ranges, r=petrochenkov 
Remove unnecessary range replacements

This PR removes an unnecessary range replacement in `collect_tokens_trailing_token`, and does a couple of other small cleanups.

r? ````@petrochenkov````
 2024-07-26 19:03:06 -04:00
Trevor Gross 553a64f412 Rollup merge of #128223 - nnethercote:refactor-collect_tokens, r=petrochenkov 
Refactor complex conditions in `collect_tokens_trailing_token`

More readability improvements for this complicated function.

r? ````@petrochenkov````
 2024-07-26 19:03:06 -04:00
Tamme Dittrich 3fdc99193e Improve error message for extern "C" unsafe fn() 
This was handled correctly already for `extern unsafe fn()`.

Co-authored-by: Folkert <folkert@folkertdev.nl>
 2024-07-26 15:14:05 +02:00
Nicholas Nethercote 55d37ae711 Remove an unnecessary block. 2024-07-26 17:37:03 +10:00
Nicholas Nethercote 6ea2da5a28 Tweak a loop. 
A fully imperative style is easier to read than a half-iterator,
half-imperative style. Also, rename `inner_attr` as `attr` because it
might be an outer attribute.
 2024-07-26 17:37:03 +10:00
Nicholas Nethercote 6e87858f26 Fix a comment. 
Imagine you have replace ranges (2..20,X) and (5..15,Y), and these tokens:
```
a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x
```
If we replace (5..15,Y) first, then (2..20,X) we get this sequence
```
a,b,c,d,e,Y,_,_,_,_,_,_,_,_,_,p,q,r,s,t,u,v,w,x
a,b,X,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,u,v,w,x
```
which is what we want.

If we do it in the other order, we get this:
```
a,b,X,_,_,_,_,_,_,_,_,_,_,_,_,p,q,r,s,t,u,v,w,x
a,b,X,_,_,Y,_,_,_,_,_,_,_,_,_,_,_,_,_,_,u,v,w,x
```
which is wrong. So it's true that we need the `.rev()` but the comment
is wrong about why.
 2024-07-26 17:37:03 +10:00
Nicholas Nethercote a560810a69 Don't include inner attribute ranges in CaptureState. 
The current code is this:
```
self.capture_state.replace_ranges.push((start_pos..end_pos, Some(target)));
self.capture_state.replace_ranges.extend(inner_attr_replace_ranges);
```
What's not obvious is that every range in `inner_attr_replace_ranges`
must be a strict sub-range of `start_pos..end_pos`. Which means, in
`LazyAttrTokenStreamImpl::to_attr_token_stream`, they will be done
first, and then the `start_pos..end_pos` replacement will just overwrite
them. So they aren't needed.
 2024-07-26 14:18:20 +10:00
Nicholas Nethercote e631b1ebfa Invert the sense of is_complete and rename it as needs_tokens. 
I have always found `is_complete` an unhelpful name. The new name (and
inverted sense) fits in better with the conditions at its call sites.
 2024-07-26 09:58:34 +10:00
Nicholas Nethercote 3d363c3d99 Move is_complete to the module that uses it. 
And make it non-`pub`.
 2024-07-26 09:44:39 +10:00
Nicholas Nethercote 4288edb219 Inline and remove AttrWrapper::is_complete. 
It has a single call site. This change makes the two `needs_collect`
conditions more similar to each other, and therefore easier to
understand.
 2024-07-26 09:44:07 +10:00
Nicholas Nethercote caee195bdd Invert early exit conditions in collect_tokens_trailing_token. 
This has been bugging me for a while. I find complex "if any of these
are true" conditions easier to think about than complex "if all of these
are true" conditions, because you can stop as soon as one is true.
 2024-07-26 09:43:41 +10:00
Folkert d3858f7465 improve error message when global_asm! uses asm! options 2024-07-25 22:33:52 +02:00
surechen 4ac60601d3 Fix a span error when parsing a wrong param of function. 
fixes #128042
 2024-07-25 22:33:45 +08:00
yukang 94a3fd7678 add limit for unclosed delimiters in lexer diagnostic 2024-07-25 17:01:32 +08:00
Matthias Krüger cfc5f25b3d Rollup merge of #127054 - compiler-errors:bound-ordering, r=fmease 
Reorder trait bound modifiers *after* `for<...>` binder in trait bounds

This PR suggests changing the grammar of trait bounds from:

```
[CONSTNESS] [ASYNCNESS] [?] [BINDER] [TRAIT_PATH]

const async ? for<'a> Sized
```

to

```
([BINDER] [CONSTNESS] [ASYNCNESS] | [?]) [TRAIT_PATH]
```

i.e., either

```
? Sized
```

or

```
for<'a> const async Sized
```

(but not both)

### Why?

I think it's strange that the binder applies "more tightly" than the `?` trait polarity. This becomes even weirder when considering that we (or at least, I) want to have `async` trait bounds expressed like:

```
where T: for<'a> async Fn(&'a ()) -> i32,
```

and not:

```
where T: async for<'a> Fn(&'a ()) -> i32,
```

### Fallout

No crates on crater use this syntax, presumably because it's literally useless. This will require modifying the reference grammar, though.

### Alternatives

If this is not desirable, then we can alternatively keep parsing `for<'a>` after the `?` but deprecate it with either an FCW (or an immediate hard error), and begin parsing `for<'a>` *before* the `?`.
 2024-07-25 04:43:18 +02:00
León Orell Valerian Liehr 7da751a108 Apply suggestions from code review 2024-07-25 03:00:04 +02:00
Santiago Pastorino 8366c7fe9c Stabilize unsafe extern blocks (RFC 3484) 2024-07-23 00:29:39 -03:00
Oli Scherer 8d290058c9 Always pass the visitor as the first argument to walk* functions 2024-07-22 14:01:24 +00:00
Oli Scherer 754bdef793 Sync mut_visit function names with immut visit ones (s/noop_visit/walk/) 2024-07-22 14:01:24 +00:00
bors 3811f40d27 Auto merge of #127957 - matthiaskrgr:rollup-1u5ivck, r=matthiaskrgr 
Rollup of 6 pull requests

Successful merges:

 - #127350 (Parser: Suggest Placing the Return Type After Function Parameters)
 - #127621 (Rewrite and rename `issue-22131` and `issue-26006` `run-make` tests to rmake)
 - #127662 (When finding item gated behind a `cfg` flag, point at it)
 - #127903 (`force_collect` improvements)
 - #127932 (rustdoc: fix `current` class on sidebar modnav)
 - #127943 (Don't allow unsafe statics outside of extern blocks)

r? `@ghost`
`@rustbot` modify labels: rollup
 2024-07-19 13:39:12 +00:00