Print regions in `type_name`.
Currently they are skipped, which is a bit weird, and it sometimes causes malformed output like `Foo<>` and `dyn Bar<, A = u32>`.
Most regions are erased by the time `type_name` does its work. So all regions are now printed as `'_` in non-optional places. Not perfect, but better than the status quo.
`c_name` is updated to trim lifetimes from MIR pass names, so that the `PASS_NAMES` sanity check still works. It is also renamed as `simplify_pass_type_name` and made non-const, because it doesn't need to be const and the non-const implementation is much shorter.
The commit also renames `should_print_region` as `should_print_optional_region`, which makes it clearer that it only applies to some regions.
Fixesrust-lang/rust#145168.
r? `@lcnr`
const-eval: full support for pointer fragments
This fixes https://github.com/rust-lang/const-eval/issues/72 and makes `swap_nonoverlapping` fully work in const-eval by enhancing per-byte provenance tracking with tracking of *which* of the bytes of the pointer this one is. Later, if we see all the same bytes in the exact same order, we can treat it like a whole pointer again without ever risking a leak of the data bytes (that encode the offset into the allocation). This lifts the limitation that was discussed quite a bit in https://github.com/rust-lang/rust/pull/137280.
For a concrete piece of code that used to fail and now works properly consider this example doing a byte-for-byte memcpy in const without using intrinsics:
```rust
use std::{mem::{self, MaybeUninit}, ptr};
type Byte = MaybeUninit<u8>;
const unsafe fn memcpy(dst: *mut Byte, src: *const Byte, n: usize) {
let mut i = 0;
while i < n {
*dst.add(i) = *src.add(i);
i += 1;
}
}
const _MEMCPY: () = unsafe {
let ptr = &42;
let mut ptr2 = ptr::null::<i32>();
// Copy from ptr to ptr2.
memcpy(&mut ptr2 as *mut _ as *mut _, &ptr as *const _ as *const _, mem::size_of::<&i32>());
assert!(*ptr2 == 42);
};
```
What makes this code tricky is that pointers are "opaque blobs" in const-eval, we cannot just let people look at the individual bytes since *we don't know what those bytes look like* -- that depends on the absolute address the pointed-to object will be placed at. The code above "breaks apart" a pointer into individual bytes, and then puts them back together in the same order elsewhere. This PR implements the logic to properly track how those individual bytes relate to the original pointer, and to recognize when they are in the right order again.
We still reject constants where the final value contains a not-fully-put-together pointer: I have no idea how one could construct an LLVM global where one byte is defined as "the 3rd byte of a pointer to that other global over there" -- and even if LLVM supports this somehow, we can leave implementing that to a future PR. It seems unlikely to me anyone would even want this, but who knows.^^
This also changes the behavior of Miri, by tracking the order of bytes with provenance and only considering a pointer to have valid provenance if all bytes are in the original order again. This is related to https://github.com/rust-lang/unsafe-code-guidelines/issues/558. It means one cannot implement XOR linked lists with strict provenance any more, which is however only of theoretical interest. Practically I am curious if anyone will show up with any code that Miri now complains about - that would be interesting data. Cc `@rust-lang/opsem`
Revert "Partially outline code inside the panic! macro".
This reverts https://github.com/rust-lang/rust/pull/115670
Without any tests/benchmarks that show some improvement, it's hard to know whether the change had any positive effect. (And if it did, whether that effect is still achieved today.)
Implement `#[derive(From)]`
Implements the `#[derive(From)]` feature ([tracking issue](https://github.com/rust-lang/rust/issues/144889), [RFC](https://github.com/rust-lang/rfcs/pull/3809)).
It allows deriving the `From` impl on structs and tuple structs with exactly one field. Some implementation notes:
- I wasn't exactly sure which spans to use in the derive generating code, so I just used `span` everywhere. I don't know if it's the Right Thing To Do. In particular the errors when `#[derive(From)]` is used on a struct with an unsized field are weirdly duplicated.
- I had to solve an import stability problem, where if I just added the unstable `macro From` to `core::convert`, previously working code like `use std::convert::From` would suddenly require an unstable feature gate, because rustc would think that you're trying to import the unstable macro. `@petrochenkov` suggested that I add the macro the the core prelude instead. This has worked well, although it only works in edition 2021+. Not sure if I botched the prelude somehow and it should live elsewhere (?).
- I had to add `Ty::AstTy`, because the `from` function receives an argument with the type of the single field, and the existing variants of the `Ty` enum couldn't represent an arbitrary type.
`apply_member_constraints`: fix placeholder check
Checking whether the member region is *an existential region from a higher universe* is just wrong and I am pretty sure we've added that check by accident as the naming was just horribly confusing before rust-lang/rust#140466.
I've encountered this issue separately while working on rust-lang/rust#139587, but feel like it's probably easier to separately FCP this change. This allows the following code to compile
```rust
trait Proj<'a> {
type Assoc;
}
impl<'a, 'b, F: FnOnce() -> &'b ()> Proj<'a> for F {
type Assoc = ();
}
fn is_proj<F: for<'a> Proj<'a>>(f: F) {}
fn define<'a>() -> impl Sized + use<'a> {
// This adds a use of `opaque::<'a>` with hidden type `&'unconstrained_b ()`.
// 'unconstrained_b is an inference variable from a higher universe as it gets
// created inside of the binder of `F: for<'a> Proj<'a>`. This previously
// caused us to not apply member constraints. We now do, constraining
// it to `'a`.
is_proj(define::<'a>);
&()
}
fn main() {}
```
This should not be breaking change, even in theory. Applying member constraints is incomplete in rare circumstances which means that applying them in more cases can cause spurious errors, cc rust-lang/rust#140569/rust-lang/rust#142073. However, as we always skipped these member regions in `apply_member_constraints` the skipped region is guaranteed to cause an error in `check_member_constraints` later on.
Fix wrong spans with external macros in the `dropping_copy_types` lint
This PR fixes some wrong spans manipulations when external macros are involved.
Specifically we didn't make sure the spans had the same context, which kind-of make our spans manipulations go wrong and produce weird spans. We fix that by making sure they have the same context.
Fixes https://github.com/rust-lang/rust/issues/145427
Deduplicate -L search paths
For each -L passed to the compiler, we eagerly scan the whole directory. If it has a lot of files, that results in a lot of allocations. So it's needless to do this if some -L paths are actually duplicated (which can happen e.g. in the situation in the linked issue).
This PR both deduplicates the args, and also teaches rustdoc not to pass duplicated args to merged doctests.
Fixes: https://github.com/rust-lang/rust/issues/145375
ignore head usages from ignored candidates
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/210. The test now takes 0.8s to compile, which seems good enough to me. We are actually still walking the entire graph here, we're just avoiding unnecessary reruns.
The basic idea is that if we've only accessed a cycle head inside of a candidate which didn't impact the final result of our goal, we don't need to rerun that cycle head even if is the used provisional result differs from the final result.
We also use this information when rebasing goals over their cycle heads. If a goal doesn't actually depend on the result of that cycle head, rebasing always succeeds. However, we still need to make sure we track the fact that we relied on the cycle head at all to avoid query instability.
It is implemented by tracking the number of `HeadUsages` for every head while evaluating goals. We then also track the head usages while evaluating a single candidate, which the search graph returns as `CandidateHeadUsages`. If there is now an always applicable candidate candidate we know that all other candidates with that source did not matter. We then call `fn ignore_candidate_head_usages` to remove the usages while evaluating this single candidate from the total. If the final `HeadUsages` end up empty, we know that the result of this cycle head did not matter when evaluating its nested goals.
coverage: Remove intermediate data structures from mapping creation
The data structures in `coverage::mappings` were historically very useful for isolating the details of mapping-extraction from the details of how coverage mappings are stored in MIR.
But because of various changes that have taken place over time, they now provide little value, and cause difficulty for the coordinated changes that will be needed for introducing expansion mapping support.
In the future, the pendulum might eventually swing back towards these being useful again, but we can always reintroduce suitable intermediate data structures if and when that happens. For now, the simplicity of not having this intermediate layer is a higher priority.
There should be no changes to compiler output.
Add `FnContext` in parser for diagnostic
Fixesrust-lang/rust#144968
Inspired by https://github.com/rust-lang/rust/issues/144968#issuecomment-3156094581, I implemented `FnContext` to indicate whether a function should have a self parameter, for example, whether the function is a trait method, whether it is in an impl block. And I removed the outdated note.
I made two commits to show the difference.
cc ``@estebank`` ``@djc``
r? compiler
Resolve the prelude import in `build_reduced_graph`
This pr tries to resolve the prelude import at the `build_reduced_graph` stage.
Part of batched import resolution in rust-lang/rust#145108 (cherry picked commit) and maybe needed for rust-lang/rust#139493.
r? petrochenkov
llvm: Accept new LLVM lifetime format
In llvm/llvm-project#150248 LLVM removed the size parameter from the lifetime format. Tolerate not having that size parameter.
strip prefix of temporary file names when it exceeds filesystem name length limit
When doing lto, rustc generates filenames that are concatenating many information.
In the case of this testcase, it is concatenating crate name and rust file name, plus some hash, and the extension. In some other cases it will concatenate even more information reducing the maximum effective crate name to about 110 chars on linux filesystems where filename max length is 255
This commit is ensuring that the temporary file names are limited in size, while still reasonably ensuring the unicity (with hashing of the stripped part)
Fix: rust-lang/rust#49914
E0793: Clarify that it applies to unions as well
pick up inactive PR: https://github.com/rust-lang/rust/pull/131472
Also:
Adjust the language slightly to be more consistent with other similar messages (was created instead of got created).
Add a short section on union.
Add an example line showing referencing a field in a packed struct is safe if the field's type isn't more strictly aligned than the pack.
r? compiler-errors
Fix tail calls to `#[track_caller]` functions
We want `#[track_caller]` to be semver independent, i.e. it should not be a breaking change to add or remove it. Since it changes ABI of a function (adding an additional argument) we have to be careful to preserve this property when adding tail calls.
The only way to achieve this that I can see is:
- we forbid tail calls in functions which are marked with `#[track_caller]` (already implemented)
- tail-calling a `#[track_caller]` marked function downgrades the tail-call to a normal call (or equivalently tail-calls the shim made by fn def to fn ptr cast) (this pr)
Ideally the downgrade would be performed by a MIR pass, but that requires post mono MIR opts (cc ```@saethlin,``` rust-lang/rust#131650). For now I've changed code in cg_ssa to accomodate this behaviour (+ added a hack to mono collector so that the shim is actually generated)
Additionally I added a lint, although I don't think it's strictly necessary.
Alternative to rust-lang/rust#144762 (and thus closesrust-lang/rust#144762)
Fixes https://github.com/rust-lang/rust/issues/144755
compiler: Allow `extern "interrupt" fn() -> !`
While reviewing rust-lang/rust#142633 I overlooked a few details because I was kind of excited.
- Fixesrust-lang/rust#143072
Implement autodiff using intrinsics
This PR aims to move autodiff logic to `autodiff` intrinsic. Allowing us to delete a great part of our frontend code and overall, simplify the compilation pipeline of autodiff functions.
Change the desugaring of `assert!` for better error output
In the desugaring of `assert!`, we now expand to a `match` expression instead of `if !cond {..}`.
The span of incorrect conditions will point only at the expression, and not the whole `assert!` invocation.
```
error[E0308]: mismatched types
--> $DIR/issue-14091.rs:2:13
|
LL | assert!(1,1);
| ^ expected `bool`, found integer
```
We no longer mention the expression needing to implement the `Not` trait.
```
error[E0308]: mismatched types
--> $DIR/issue-14091-2.rs:15:13
|
LL | assert!(x, x);
| ^ expected `bool`, found `BytePos`
```
Now `assert!(val)` desugars to:
```rust
match val {
true => {},
_ => $crate::panic::panic_2021!(),
}
```
Fix#122159.
Patterns: represent constants as valtrees
Const patterns are always valtrees now. Let's represent that in the types. We use `ty::Value` for this since it nicely packages value and type, and has some convenient methods.
Cc `@Nadrieril` `@BoxyUwU`
Use `default_field_values` in `Resolver`
Change `Resolver` to use `feature(default_field_values)`. This change is non-exhaustive, as fields may have been added since I made this commit, and `Fx(Index/Hash)(Map/Set)` types would need to have a `const` constructable to change the majority of the fields left over.
Using default field values should make it easier to review when we add or remove fields to `Resolver` in the future, and highlight which fields are run-time dependent in `Resolver::new`.
r? ``@petrochenkov``
cfg_select: Support unbraced expressions
Tracking issue for `cfg_select`: rust-lang/rust#115585
When operating on expressions, `cfg_select!` can now handle expressions
without braces. (It still requires braces for other things, such as
items.)
Expand the test coverage and documentation accordingly.
---
I'm not sure whether deciding to extend `cfg_select!` in this way is T-lang or T-libs-api. I've labeled for both, with the request that both teams don't block on each other. :)
Include whitespace in "remove |" suggestion and make it hidden
Tweak error rendering of patterns with an extra `|` on either end.
Built on #137409. Only last commit is relevant.
? ``@compiler-errors``
Rework target checking for built-in attributes
This is a refactoring of target checking for built-in attributes.
This PR has the following goals:
- Only refactor the 80% of the attributes that are simple to target check. More complicated ones like `#[repr]` will be in a future PR. Tho I have written the code in such a way that this will be possible to add in the future.
- No breaking changes.
- This part of the codebase is not very well tested though, we can do a crater run if we want to be sure.
- I've spotted quite a few weird situations (like I don't think an impl block should be deprecated?). We can propose fixing these to in a future PR
Fixes https://github.com/rust-lang/rust/issues/143780
Fixes https://github.com/rust-lang/rust/issues/138510
I've split it in commits and left a description on some of the commits to help review.
r? `@jdonszelmann`
