| Age | Commit message (Collapse) | Author | Lines |
|---|
|
r=jdonszelmann
Fix deprecation attributes on foreign statics
r? ````````@jdonszelmann````````
Fixes https://github.com/rust-lang/rust/issues/145437
|
|
Add codegen test for issue 122734
Closes rust-lang/rust#122734
|
|
Fix `-Zregparm` for LLVM builtins
This fixes the issue where `-Zregparm=N` was not working correctly when calling LLVM intrinsics
By default on `x86-32`, arguments are passed on the stack. The `-Zregparm=N` flag allows the first `N` arguments to be passed in registers instead.
When calling intrinsics like `memset`, LLVM still passes parameters on the stack, which prevents optimizations like tail calls.
As proposed by ````@tgross35,```` I fixed this by setting the `NumRegisterParameters` LLVM module flag to `N` when the `-Zregparm=N` is set.
```rust
// compiler/rust_codegen_llvm/src/context.rs#375-382
if let Some(regparm_count) = sess.opts.unstable_opts.regparm {
llvm::add_module_flag_u32(
llmod,
llvm::ModuleFlagMergeBehavior::Error,
"NumRegisterParameters",
regparm_count,
);
}
```
[Here](https://rust.godbolt.org/z/YMezreo48) is a before/after compiler explorer.
Here is the final result for the code snippet in the original issue:
```asm
entrypoint:
push esi
mov esi, eax
mov eax, ecx
mov ecx, esi
pop esi
jmp memset ; Tail call parameters in registers
```
Fixes: https://github.com/rust-lang/rust/issues/145271
|
|
Implement declarative (`macro_rules!`) derive macros (RFC 3698)
This is a draft for review, and should not be merged yet.
This is layered atop https://github.com/rust-lang/rust/pull/145153 , and has
only two additional commits atop that. The first handles parsing and provides a
test for various parse errors. The second implements expansion and handles
application.
This implements RFC 3698, "Declarative (`macro_rules!`) derive macros".
Tracking issue: https://github.com/rust-lang/rust/issues/143549
This has one remaining issue, which I could use some help debugging: in
`tests/ui/macros/macro-rules-derive-error.rs`, the diagnostics for
`derive(fn_only)` (for a `fn_only` with no `derive` rules) and
`derive(ForwardReferencedDerive)` both get emitted twice, as a duplicate
diagnostic.
From what I can tell via adding some debugging code,
`unresolved_macro_suggestions` is getting called twice from
`finalize_macro_resolutions` for each of them, because
`self.single_segment_macro_resolutions` has two entries for the macro, with two
different `parent_scope` values. I'm not clear on why that happened; it doesn't
happen with the equivalent code using attrs.
I'd welcome any suggestions for fixing this.
|
|
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.
Fixes rust-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`
|
|
|
|
Rollup of 11 pull requests
Successful merges:
- rust-lang/rust#143717 (Add `Default` impls for `Pin`ned `Box`, `Rc`, `Arc`)
- rust-lang/rust#144054 (Stabilize as_array_of_cells)
- rust-lang/rust#144907 (fix: Reject async assoc fns of const traits/impls in ast_passes)
- rust-lang/rust#144922 (Implement `#[derive(From)]`)
- rust-lang/rust#144963 (Stabilize `core::iter::chain`)
- rust-lang/rust#145436 (fix(tests/rmake/wasm-unexpected-features): change features from `WASM1` to `MVP`)
- rust-lang/rust#145453 (Remove duplicated tracing span in bootstrap)
- rust-lang/rust#145454 (Fix tracing debug representation of steps without arguments in bootstrap)
- rust-lang/rust#145455 (Do not copy files in `copy_src_dirs` in dry run)
- rust-lang/rust#145462 (Stabilize `const_exposed_provenance` feature)
- rust-lang/rust#145466 (Enable new `[range-diff]` feature in triagebot)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
fix(tests/rmake/wasm-unexpected-features): change features from `WASM1` to `MVP`
missed this in rust-lang/rust#145275
since test calls `rustc` with `-C target-cpu mvp`
try-job: `test-various`
|
|
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.
|
|
fix: Reject async assoc fns of const traits/impls in ast_passes
Fixes rust-lang/rust#117629
|
|
Stabilize as_array_of_cells
This PR stabilizes
```rust
impl<T, const N: usize> Cell<[T; N]> {
pub const fn as_array_of_cells(&self) -> &[Cell<T>; N];
}
```
Stabilization report: https://github.com/rust-lang/rust/issues/88248#issuecomment-3082986863
Closes: https://github.com/rust-lang/rust/issues/88248
|
|
`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.
|
|
Rollup of 11 pull requests
Successful merges:
- rust-lang/rust#144210 (std: thread: Return error if setting thread stack size fails)
- rust-lang/rust#145310 (Reduce usage of `compiler_for` in bootstrap)
- rust-lang/rust#145311 (ci: clean windows disk space in background)
- rust-lang/rust#145340 (Split codegen backend check step into two and don't run it with `x check compiler`)
- rust-lang/rust#145408 (Deduplicate -L search paths)
- rust-lang/rust#145412 (Windows: Replace `GetThreadId`+`GetCurrentThread` with `GetCurrentThreadId`)
- rust-lang/rust#145413 (bootstrap: Reduce dependencies)
- rust-lang/rust#145426 (Fix typos in bootstrap.example.toml)
- rust-lang/rust#145430 (Fix wrong spans with external macros in the `dropping_copy_types` lint)
- rust-lang/rust#145431 (Enhance UI test output handling for runtime errors)
- rust-lang/rust#145448 (Autolabel `src/tools/{rustfmt,rust-analyzer}` changes with `T-{rustfmt,rust-analyzer}`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
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
|
|
|
|
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.
|
|
|
|
|
|
|
|
Rollup of 21 pull requests
Successful merges:
- rust-lang/rust#118087 (Add Ref/RefMut try_map method)
- rust-lang/rust#122661 (Change the desugaring of `assert!` for better error output)
- rust-lang/rust#142640 (Implement autodiff using intrinsics)
- rust-lang/rust#143075 (compiler: Allow `extern "interrupt" fn() -> !`)
- rust-lang/rust#144865 (Fix tail calls to `#[track_caller]` functions)
- rust-lang/rust#144944 (E0793: Clarify that it applies to unions as well)
- rust-lang/rust#144947 (Fix description of unsigned `checked_exact_div`)
- rust-lang/rust#145004 (Couple of minor cleanups)
- rust-lang/rust#145005 (strip prefix of temporary file names when it exceeds filesystem name length limit)
- rust-lang/rust#145012 (Tail call diagnostics to include lifetime info)
- rust-lang/rust#145065 (resolve: Introduce `RibKind::Block`)
- rust-lang/rust#145120 (llvm: Accept new LLVM lifetime format)
- rust-lang/rust#145189 (Weekly `cargo update`)
- rust-lang/rust#145235 (Minor `[const]` tweaks)
- rust-lang/rust#145275 (fix(compiler/rustc_codegen_llvm): apply `target-cpu` attribute)
- rust-lang/rust#145322 (Resolve the prelude import in `build_reduced_graph`)
- rust-lang/rust#145331 (Make std use the edition 2024 prelude)
- rust-lang/rust#145369 (Do not ICE on private type in field of unresolved struct)
- rust-lang/rust#145378 (Add `FnContext` in parser for diagnostic)
- rust-lang/rust#145389 ([rustdoc] Revert "rustdoc search: prefer stable items in search results")
- rust-lang/rust#145392 (coverage: Remove intermediate data structures from mapping creation)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
[rustdoc] Revert "rustdoc search: prefer stable items in search results"
Reverts https://github.com/rust-lang/rust/pull/141658 and reverts https://github.com/rust-lang/rust/pull/145349.
Reopens https://github.com/rust-lang/rust/issues/138067.
r? ```@fmease```
|
|
Add `FnContext` in parser for diagnostic
Fixes rust-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
|
|
Do not ICE on private type in field of unresolved struct
Fix rust-lang/rust#145367.
|
|
r=petrochenkov
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
|
|
r=alexcrichton
fix(compiler/rustc_codegen_llvm): apply `target-cpu` attribute
Resolves rust-lang/rust#140174
r? ```@alexcrichton```
try-job: `test-various*`
|
|
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.
|
|
resolve: Introduce `RibKind::Block`
to avoid confusing module items, blocks with items, and blocks without items.
Addresses https://github.com/rust-lang/rust/pull/143141#discussion_r2254893953 and https://github.com/rust-lang/rust/pull/143141#discussion_r2258004452.
A couple of related cleanups are also added on top.
|
|
Tail call diagnostics to include lifetime info
Fixes https://github.com/rust-lang/rust/issues/144957
r? ```@WaffleLapkin``` ```@compiler-errors```
|
|
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
|
|
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 closes rust-lang/rust#144762)
Fixes https://github.com/rust-lang/rust/issues/144755
|
|
r=davidtwco
compiler: Allow `extern "interrupt" fn() -> !`
While reviewing rust-lang/rust#142633 I overlooked a few details because I was kind of excited.
- Fixes rust-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`
|
|
Rollup of 11 pull requests
Successful merges:
- rust-lang/rust#137872 (Include whitespace in "remove |" suggestion and make it hidden)
- rust-lang/rust#144631 (Fix test intrinsic-raw_eq-const-bad for big-endian)
- rust-lang/rust#145233 (cfg_select: Support unbraced expressions)
- rust-lang/rust#145261 (Improve tracing in bootstrap)
- rust-lang/rust#145324 (Rename and document `ONLY_HOSTS` in bootstrap)
- rust-lang/rust#145353 (bootstrap: Fix jemalloc 64K page support for aarch64 tools)
- rust-lang/rust#145379 (bootstrap: Support passing `--timings` to cargo)
- rust-lang/rust#145397 (Rust documentation, use `rustc-dev-guide` :3)
- rust-lang/rust#145398 (Use `default_field_values` in `Resolver`)
- rust-lang/rust#145401 (cleanup: Remove useless `[T].iter().last()`)
- rust-lang/rust#145403 (Adjust error message grammar to be less awkward)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Add infrastructure to apply a derive macro to arguments, consuming and
returning a `TokenTree` only.
Handle `SyntaxExtensionKind::MacroRules` when expanding a derive, if the
macro's kinds support derive.
Add tests covering various cases of `macro_rules` derives.
Note that due to a pre-existing FIXME in `expand.rs`, derives are
re-queued and some errors get emitted twice. Duplicate diagnostic
suppression makes them not visible, but the FIXME should still get
fixed.
|
|
This handles various kinds of errors, but does not allow applying the
derive yet.
This adds the feature gate `macro_derive`.
|
|
Adjust error message grammar to be less awkward
r? ``@estebank``
|
|
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. :)
|
|
r=compiler-errors
Fix test intrinsic-raw_eq-const-bad for big-endian
The test fails on s390x and presumably other big-endian systems, due to print of raw values. To fix the tests remove the raw output values in the error note with normalize-stderr.
|
|
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`
|
|
|
|
|
|
|
|
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
|
|
|
|
scope" help
|
