Try to recover from path sep error in type parsing
Fixes#129273
Error using `:` in the argument list may mess up the parser.
case `tests/ui/suggestions/struct-field-type-including-single-colon` also changed, seems it's the same meaning, should be OK.
r? `@estebank`
Do not allow attributes on struct field rest patterns
Fixes#81282.
This removes support for attributes on struct field rest patterns (the `..` bit) from the parser. Previously any attributes were being parsed but dropped from the AST, so didn't work and were deleted by rustfmt.
This needs an equivalent change to the reference but I wanted to see how this PR is received first.
The error message it produces isn't great, however it does match the error you get if you try to add attributes to .. in struct expressions atm, although I can understand wanting to do better given this was previously accepted. I think I could move attribute parsing back up to where it was and then emit a specific new error for this case, however I might need some guidance as this is the first time I've messed around inside the compiler.
While this is technically breaking I don't think it's much of an issue: attributes in this position don't currently do anything and rustfmt outright deletes them, meaning it's incredibly unlikely to affect anyone. I have already made the equivalent change to *add* support for attributes (mostly) but the conversation in the linked issue suggested it would be more reasonable to just remove them (and pointed out it's much easier to add support later if we realise we need them).
Fix crate name validation
Reject macro calls inside attribute `#![crate_name]` like in `#![crate_name = concat!("na", "me")]`.
Prior to #117584, the result of the expansion (here: `"name"`) would actually be properly picked up by the compiler and used as the crate name. However since #117584 / on master, we extract the "value" (i.e., the *literal* string literal) of the `#![crate_name]` much earlier in the pipeline way before macro expansion and **skip**/**ignore** any `#![crate_name]`s "assigned to" a macro call. See also #122001.
T-lang has ruled to reject `#![crate_name = MACRO!(...)]` outright very similar to other built-in attributes whose value we need early like `#![crate_type]`. See accepted FCP: https://github.com/rust-lang/rust/issues/122001#issuecomment-2023203182.
Note that the check as implemented in this PR is even more "aggressive" compared to the one of `#![crate_type]` by running as early as possible in order to reject `#![crate_name = MACRO!(...)]` even in "non-normal" executions of `rustc`, namely on *print requests* (e.g., `--print=crate-name` and `--print=file-names`). If I were to move the validation step a bit further back close to the `#![crate_type]` one, `--print=crate-name` (etc.) would *not* exit fatally with an error in this kind of situation but happily report an incorrect crate name (i.e., the "crate name" as if `#![crate_name]` didn't exist / deduced from other sources like `--crate-name` or the file name) which would match the behavior on master. Again, see also #122001.
I'm mentioning this explicitly because I'm not sure if it was that clear in the FCP'ed issue. I argue that my current approach is the most reasonable one. I know (from reading the code and from past experiments) that various print requests are still quite broken (mostly lack of validation).
To the best of my knowledge, there's no print request whose output references/contains a crate *type*, so there's no "inherent need" to move `#![crate_type]`'s validation to happen earlier.
---
Fixes#122001.
https://github.com/rust-lang/rust/labels/relnotes: Compatibility. Breaking change.
Gets rid of two top-level UI tests which is always great.
Furthermore, move `need-crate-arg-ignore-tidy$x.rs`
from `command/` to `invalid-compile-flags/`.
`command/` concerns `std::process::Command` tests, not CLI tests.
llvm: Tolerate captures in tests
llvm/llvm-project@7e3735d1a1 introduces `captures` annotations. Adjust regexes to be tolerant of these.
`@rustbot` label:+llvm-main
add x86-sse2 (32bit) ABI that requires SSE2 target feature
This is the first commit of https://github.com/rust-lang/rust/pull/135408:
The primary goal of this is to make SSE2 required for our i686 targets (at least for the ones that use Pentium 4 as their baseline), to ensure they cannot be affected by https://github.com/rust-lang/rust/issues/114479. This has been MCPd in https://github.com/rust-lang/compiler-team/issues/808, and is tracked in https://github.com/rust-lang/rust/issues/133611.
We do this by defining a new ABI that these targets select, and making SSE2 required by the ABI (that's the first commit). That's kind of a hack, but it is the easiest way to make a target feature required via the target spec. In a follow-up change (https://github.com/rust-lang/rust/pull/135408), we can actually make use of SSE2 for the ABI, but that is running into some infrastructure issues.
r? `@workingjubilee`
try-job: aarch64-apple
try-job: aarch64-gnu
try-job: aarch64-gnu-debug
try-job: test-various
try-job: x86_64-gnu-nopt
try-job: dist-i586-gnu-i586-i686-musl
Normalize closure instance before eagerly monomorphizing it
We were monomorphizing two versions of the closure (or in the original issue, coroutine) -- one with normalized captures and one with unnormalized captures. This led to a symbol collision.
Fixes#137009
r? `@saethlin` or reassign
Rollup of 9 pull requests
Successful merges:
- #135778 (account for `c_enum_min_bits` in `multiple-reprs` UI test)
- #136052 (Correct comment for FreeBSD and DragonFly BSD in unix/thread)
- #136886 (Remove the common prelude module)
- #136956 (add vendor directory to .gitignore)
- #136958 (Fix presentation of purely "additive" replacement suggestion parts)
- #136967 (Use `slice::fill` in `io::Repeat` implementation)
- #136976 (alloc boxed: docs: use MaybeUninit::write instead of as_mut_ptr)
- #137007 (Emit MIR for each bit with on `dont_reset_cast_kind_without_updating_operand`)
- #137008 (Move code into `rustc_mir_transform`)
r? `@ghost`
`@rustbot` modify labels: rollup
Emit MIR for each bit with on `dont_reset_cast_kind_without_updating_operand`
PR #136450 introduced a diff that includes a pointer-sized alloc. This doesn't cause any problems on the compiler test suite but it affects the test suite that ferrocene has for `aarch64-unknown-none` as the snapshot of the diff only includes a 32-bit alloc even though this should be a 64-bit alloc on `aarch64-unknown-none`.
r? ``@compiler-errors``
Fix presentation of purely "additive" replacement suggestion parts
#127541 changes replacement suggestions to use the "diff" view always, which I think is really verbose in cases where a replacement snippet is a "superset" of the snippet that is being replaced.
Consider:
```
LL - Self::Baz: Clone,
LL + Self::Baz: Clone, T: std::clone::Clone
```
In this code, we suggest replacing `", "` with `", T: std::clone::Clone"`. This is a consequence of how the snippet is constructed. I believe that since the string that is being replaced is a subset of the replacement string, it's not providing much value to present this as a diff. Users should be able to clearly understand what's being suggested here using the `~` underline view we've been suggesting for some time now.
Given that this affects ~100 tests out of the ~1000 UI tests affected, I expect this to be a pretty meaningful improvement of the fallout of #127541.
---
In the last commit, this PR also "trims" replacement parts so that they are turned into their purely additive subset, if possible. See the diff for what this means.
---
r? estebank
Remove the common prelude module
This fixes the issues described in https://github.com/rust-lang/rust/issues/136102. Primarily, this resolves some issues with how the documentation for the prelude is generated:
- It avoids showing "unstable" for macros in the prelude that are actually stable.
- Avoids duplication of some pages due to the previous lack of `doc(no_inline)`.
- Makes the different edition preludes consistent, and sets a pattern that can be used by future editions.
We may need to rearrange these modules in the future if we decide to remove anything from the prelude again. If we do, I think we should look into a different solution that avoids the documentation problems.
Closes https://github.com/rust-lang/rust/issues/136102
Set both `nuw` and `nsw` in slice size calculation
There's an old note in the code to do this, and now that [LLVM-C has an API for it](f0b8ff1251/llvm/include/llvm-c/Core.h (L4403-L4408)), we might as well. And it's been there since what looks like LLVM 17 de9b6aa341 so doesn't even need to be conditional.
(There's other places, like `RawVecInner` or `Layout`, that might want to do things like this too, but I'll leave those for a future PR.)
Change description from compiletest to regression test
Co-authored-by: 许杰友 Jieyou Xu (Joe) <39484203+jieyouxu@users.noreply.github.com>
Improve test name, location, and description
Update tests/ui/impl-trait/impl-fn-rpit-opaque-107883.rs
Co-authored-by: waffle <waffle.lapkin@gmail.com>
`transmute` should also assume non-null pointers
Previously it only did integer-ABI things, but this way it does data pointers too. That gives more information in general to the backend, and allows slightly simplifying one of the helpers in slice iterators.
coverage: Eliminate more counters by giving them to unreachable nodes
When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero.
Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed.
This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
debuginfo: Set bitwidth appropriately in enum variant tags
Previously, we unconditionally set the bitwidth to 128-bits, the largest an enum would possibly be. Then, LLVM would cut down the constant by chopping off leading zeroes before emitting the DWARF. LLVM only supported 64-bit enumerators, so this would also have occasionally resulted in truncated data.
LLVM added support for 128-bit enumerators in llvm/llvm-project#125578
That patchset trusts the constant to describe how wide the variant tag is, so the high 64-bits of zeros are considered potentially load-bearing.
As a result, we went from emitting tags that looked like:
DW_AT_discr_value (0xfe)
(because `dwarf::BestForm` selected `data1`)
to emitting tags that looked like:
DW_AT_discr_value (<0x10> fe ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 )
This makes the `DW_AT_discr_value` encode at the bitwidth of the tag, which:
1. Is probably closer to our intentions in terms of describing the data.
2. Doesn't invoke the 128-bit support which may not be supported by all debuggers / downstream tools.
3. Will result in smaller debug information.
Rollup of 8 pull requests
Successful merges:
- #134999 (Add cygwin target.)
- #136559 (Resolve named regions when reporting type test failures in NLL)
- #136660 (Use a trait to enforce field validity for union fields + `unsafe` fields + `unsafe<>` binder types)
- #136858 (Parallel-compiler-related cleanup)
- #136881 (cg_llvm: Reduce visibility of all functions in the llvm module)
- #136888 (Always perform discr read for never pattern in EUV)
- #136948 (Split out the `extern_system_varargs` feature)
- #136949 (Fix import in bench for wasm)
r? `@ghost`
`@rustbot` modify labels: rollup
Split out the `extern_system_varargs` feature
After the stabilization PR was opened, `extern "system"` functions were added to `extended_varargs_abi_support`. This has a number of questions regarding it that were not discussed and were somewhat surprising. It deserves to be considered as its own feature, separate from `extended_varargs_abi_support`.
Tracking issue:
- https://github.com/rust-lang/rust/issues/136946
Always perform discr read for never pattern in EUV
Always perform a read of `!` discriminants to ensure that it's captured by closures in expr use visitor
Fixes#136852
r? Nadrieril or reassign
Use a trait to enforce field validity for union fields + `unsafe` fields + `unsafe<>` binder types
This PR introduces a new, internal-only trait called `BikeshedGuaranteedNoDrop`[^1] to faithfully model the field check that used to be implemented manually by `allowed_union_or_unsafe_field`.
942db6782f/compiler/rustc_hir_analysis/src/check/check.rs (L84-L115)
Copying over the doc comment from the trait:
```rust
/// Marker trait for the types that are allowed in union fields, unsafe fields,
/// and unsafe binder types.
///
/// Implemented for:
/// * `&T`, `&mut T` for all `T`,
/// * `ManuallyDrop<T>` for all `T`,
/// * tuples and arrays whose elements implement `BikeshedGuaranteedNoDrop`,
/// * or otherwise, all types that are `Copy`.
///
/// Notably, this doesn't include all trivially-destructible types for semver
/// reasons.
///
/// Bikeshed name for now.
```
As far as I am aware, there's no new behavior being guaranteed by this trait, since it operates the same as the manually implemented check. We could easily rip out this trait and go back to using the manually implemented check for union fields, however using a trait means that this code can be shared by WF for `unsafe<>` binders too. See the last commit.
The only diagnostic changes are that this now fires false-negatives for fields that are ill-formed. I don't consider that to be much of a problem though.
r? oli-obk
[^1]: Please let's not bikeshed this name lol. There's no good name for `ValidForUnsafeFieldsUnsafeBindersAndUnionFields`.
