| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Enable `relative-path-include-bytes-132203` rustdoc-ui test on Windows
The problem with the error message on Windows is:
- The path separators are different
- The OS error message string is different
Normalizing those two things makes the test pass on Windows.
|
|
Replace some u64 hashes with Hash64
I introduced the Hash64 and Hash128 types in https://github.com/rust-lang/rust/pull/110083, essentially as a mechanism to prevent hashes from landing in our leb128 encoding paths. If you just have a u64 or u128 field in a struct then derive Encodable/Decodable, that number gets leb128 encoding. So if you need to store a hash or some other value which behaves very close to a hash, don't store it as a u64.
This reverts part of https://github.com/rust-lang/rust/pull/117603, which turned an encoded Hash64 into a u64.
Based on https://github.com/rust-lang/rust/pull/110083, I don't expect this to be perf-sensitive on its own, though I expect that it may help stabilize some of the small rmeta size fluctuations we currently see in perf reports.
|
|
Fix const items not being allowed to be called `r#move` or `r#static`
Because of an ambiguity with const closures, the parser needs to ensure that for a const item, the `const` keyword isn't followed by a `move` or `static` keyword, as that would indicate a const closure:
```rust
fn main() {
const move // ...
}
```
This check did not take raw identifiers into account, therefore being unable to distinguish between `const move` and `const r#move`. The latter is obviously not a const closure, so it should be allowed as a const item.
This fixes the check in the parser to only treat `const ...` as a const closure if it's followed by the *proper keyword*, and not a raw identifier.
Additionally, this adds a large test that tests for all raw identifiers in all kinds of positions, including `const`, to prevent issues like this one from occurring again.
fixes #137128
|
|
`invalid_from_utf8[_unchecked]`: also lint inherent methods
Addressing https://github.com/rust-lang/rust/issues/131114#issuecomment-2646663535
Also corrected a typo: "_an_ invalid literal", not "_a_ invalid literal".
|
|
Overhaul `rustc_middle::limits`
In particular, to make `pattern_complexity` work more like other limits, which then enables some other simplifications.
r? ``@Nadrieril``
|
|
Start removing `rustc_middle::hir::map::Map`
`rustc_middle::hir::map::Map` is now just a low-value wrapper around `TyCtxt`. This PR starts removing it.
r? `@cjgillot`
|
|
|
|
|
|
|
|
The end goal is to eliminate `Map` altogether.
I added a `hir_` prefix to all of them, that seemed simplest. The
exceptions are `module_items` which became `hir_module_free_items` because
there was already a `hir_module_items`, and `items` which became
`hir_free_items` for consistency with `hir_module_free_items`.
|
|
For consistency with `recursion_limit`, `move_size_limit`, and
`type_length_limit`.
|
|
with rust-analyzer
|
|
replace "// @" with "//@ ", and fix the tests so they actually pass, after directives are checked
|
|
|
|
Because of an ambiguity with const closures, the parser needs to ensure
that for a const item, the `const` keyword isn't followed by a `move` or
`static` keyword, as that would indicate a const closure:
```rust
fn main() {
const move // ...
}
```
This check did not take raw identifiers into account, therefore being
unable to distinguish between `const move` and `const r#move`. The
latter is obviously not a const closure, so it should be allowed as a
const item.
This fixes the check in the parser to only treat `const ...` as a const
closure if it's followed by the *proper keyword*, and not a raw
identifier.
Additionally, this adds a large test that tests for all raw identifiers in
all kinds of positions, including `const`, to prevent issues like this
one from occurring again.
|
|
Fix test that relies on error language
We shouldn't care about the OS error message text in this test.
|
|
Don't project into `NonNull` when dropping a `Box`
Another step towards banning these projections.
Tracking Issue #133652
|
|
Rework `name_regions` to not rely on reverse scc graph for non-member-constrain usages
Fixes https://github.com/rust-lang/rust/issues/137015
Splits the `name_regions` into two versions: One meant for member region constraint error reporting (which I've renamed to `name_regions_for_member_constraint`), and one meant *just* to replace region vids with an external region.
Use the latter in the usage sites I added in #136559, since the regions returned by `name_regions_for_member_constraint` are also not *totally* accurate (which is fine for how they're used for member region constraint error reporting -- they're intentionally returning overapproximated universal regions so that we have something to name in `+ use<'a>` suggestions, because opaques can only capture universal regions and since member region constraints don't insert any edges into the region graph, the error region is probably gonna be shorter than a universal region) and because that function requires the reverse scc graph to have been computed which isn't done for our usages in #136559.
|
|
|
|
r=GuillaumeGomez
rustdoc: improve refdef handling in the unresolved link lint
This commit takes advantage of a feature in pulldown-cmark that makes the list of link definitions available to the consuming application. It produces unresolved link warnings for refdefs that aren't used, and can now produce exact spans for the dest even when it has escapes.
Closes #133150 since this lint would have caught the mistake in that issue, and, along with https://github.com/rust-lang/rust-clippy/pull/13707, most mistakes in this class should produce a warning from one of them.
|
|
|
|
|
|
|
|
Ignore Self in bounds check for associated types with Self:Sized
Fixes https://github.com/rust-lang/rust/issues/137053
This is morally a fix of https://github.com/rust-lang/rust/pull/112319, since the `Self: Sized` check was just missing here.
r? oli-obk
|
|
RalfJung:abi_unsupported_vector_types-better-error, r=compiler-errors
abi_unsupported_vector_types: say which type is the problem
|
|
Export kernel descriptor for amdgpu kernels
The host runtime (HIP or HSA) expects a kernel descriptor object for each kernel in the ELF file. The amdgpu LLVM backend generates the object. It is created as a symbol with the name of the kernel plus a `.kd` suffix.
Add it to the exported symbols in the linker script, so that it can be found.
For reference, the symbol is created here in LLVM: https://github.com/llvm/llvm-project/blob/d5457e4c1619e5dbeefd49841e284cbc24d35cb4/llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUTargetStreamer.cpp#L966
I wrote [a test](https://github.com/Flakebi/rust/commit/6a9115b121b48a8cd4aaf100551569dc70c6c704) for this as well, I’ll add that once the target is merged and working.
With this, all PRs to get working code for amdgpu are open (this + the target + the two patches adding addrspacecasts for alloca and global variables).
Tracking issue: #135024
r? `@workingjubilee`
|
|
non-member-constrain usages
|
|
|
|
This commit takes advantage of a feature in pulldown-cmark that
makes the list of link definitions available to the consuming
application. It produces unresolved link warnings for refdefs
that aren't used, and can now produce exact spans for the dest
even when it has escapes.
|
|
r=estebank
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.
|
|
|
|
|
|
This adds a few more statements to `next`, but optimizes better in the loops (saving 2 blocks in `forward_loop`, for example)
|
|
Probably reasonable anyway since it more obviously drops provenance.
|
|
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
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@7e3735d1a1b85cea48feb45cb7c2b5d8eaa216ae 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
|
|
r=saethlin
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
|
|
Add a new check-pass UI test for returning `impl Fn(T) -> impl Trait`
This PR closes #107883 by adding a ui test.
|
|
|
|
llvm/llvm-project@7e3735d1a1b85cea48feb45cb7c2b5d8eaa216ae introduces
`captures` annotations. Adjust regexes to be tolerant of these.
|
|
|
|
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``
|
