| Age | Commit message (Collapse) | Author | Lines |
|---|
|
And rename a closure argument.
|
|
Structurally normalize weak and inherent in new solver
It seems pretty obvious to me that we should be normalizing weak and inherent aliases too, since they can always be normalized. This PR still leaves open the question of what to do with opaques, though 💀
**Also**, we need to structurally resolve the target of a coercion, for the UI test to work.
r? `@lcnr`
|
|
r=oli-obk
Store the laziness of type aliases in their `DefKind`
Previously, we would treat paths referring to type aliases as *lazy* type aliases if the current crate had lazy type aliases enabled independently of whether the crate which the alias was defined in had the feature enabled or not.
With this PR, the laziness of a type alias depends on the crate it is defined in. This generally makes more sense to me especially if / once lazy type aliases become the default in a new edition and we need to think about *edition interoperability*:
Consider the hypothetical case where the dependency crate has an older edition (and thus eager type aliases), it exports a type alias with bounds & a where-clause (which are void but technically valid), the dependent crate has the latest edition (and thus lazy type aliases) and it uses that type alias. Arguably, the bounds should *not* be checked since at any time, the dependency crate should be allowed to change the bounds at will with a *non*-major version bump & without negatively affecting downstream crates.
As for the reverse case (dependency: lazy type aliases, dependent: eager type aliases), I guess it rules out anything from slight confusion to mild annoyance from upstream crate authors that would be caused by the compiler ignoring the bounds of their type aliases in downstream crates with older editions.
---
This fixes #114468 since before, my assumption that the type alias associated with a given weak projection was lazy (and therefore had its variances computed) did not necessarily hold in cross-crate scenarios (which [I kinda had a hunch about](https://github.com/rust-lang/rust/pull/114253#discussion_r1278608099)) as outlined above. Now it does hold.
`@rustbot` label F-lazy_type_alias
r? `@oli-obk`
|
|
Remove arm crypto target feature
Follow-up to https://github.com/rust-lang/stdarch/pull/1407.
LLVM has moved away from a combined `crypto` feature on both aarch64 and arm, and we did the same on aarch64, but were deferred from doing the same on arm due to compatibility with older LLVM.
As the minimum LLVM version has increased, we can now remove this (unstable) target feature on arm.
r? `@Amanieu`
|
|
Revert #98333 "Re-enable atomic loads and stores for all RISC-V targets"
This reverts #98333.
As said in https://github.com/rust-lang/rust/pull/98333#issuecomment-1666375293, `forced-atomics` target feature is also needed to enable atomic load/store on these targets (otherwise, libcalls are generated): https://godbolt.org/z/433qeG7vd
However, `forced-atomics` target feature is currently broken (https://github.com/rust-lang/rust/issues/114153), so AFAIK, there is currently no way to enable atomic load/store (via core::intrinsics) on these targets properly.
r? `@Amanieu`
|
|
Warn when #[macro_export] is applied on decl macros
The existing code checks if `#[macro_export]` is being applied to an item other than a macro, and warns in that case, but fails to take into account macros 2.0/decl macros, despite the attribute having no effect on these macros.
This PR adds a special case for decl macros with the aforementioned attribute, so that the warning is a bit more precise. Instead of just saying "this attribute has no effect", hint towards the fact that decl macros get exported and resolved like regular items.
It also removes a `#[macro_export]` attribute which was applied on one of `core`'s decl macros.
- core: Remove #[macro_export] from `debug_assert_matches`
- check_attrs: Warn when #[macro_export] is used on macros 2.0
|
|
inferiorhumanorgans:rustc-codegen-ssa-duplicate-export, r=wesleywiser
Avoid exporting __rust_alloc_error_handler_should_panic more than once.
Exporting `__rust_alloc_error_handler_should_panic` multiple times causes `ld.gold` to balk with: `error: version script assignment of to symbol __rust_alloc_error_handler_should_panic failed: symbol not defined`
Specifically this breaks builds of 1.70.0 and newer on DragonFly and YoctoProject with `ld.gold`. Builds with `ld.bfd` and `lld` should be unaffected.
http://errors.yoctoproject.org/Errors/Details/708194/
|
|
The compiler should emit a more specific error when the `#[macro_export]`
attribute is present on a decl macro, instead of silently ignoring it.
This commit adds the required error message in rustc_passes/messages.ftl,
as well as a note. A new variant is added to the `errors::MacroExport`
enum, specifically for the case where the attribute is added to a macro
2.0.
|
|
|
|
|
|
These types changed in LLVM 18, not LLVM 17.
|
|
Function pointer alignment is specified since https://reviews.llvm.org/D147016.
|
|
The bundled version now uses the LLVM 17 code path.
|
|
Rollup of 9 pull requests
Successful merges:
- #113568 (Fix spurious test failure with `panic=abort`)
- #114196 (Bubble up nested goals from equation in `predicates_for_object_candidate`)
- #114485 (Add trait decls to SMIR)
- #114495 (Set max_atomic_width for AVR to 16)
- #114496 (Set max_atomic_width for sparc-unknown-linux-gnu to 32)
- #114510 (llvm-wrapper: adapt for LLVM API changes)
- #114562 (stabilize abi_thiscall)
- #114570 ([miri][typo] Fix a typo in a vector_block comment.)
- #114573 (CI: do not hide error logs in a group)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
stabilize abi_thiscall
Closes https://github.com/rust-lang/rust/issues/42202, stabilizing the use of the "thiscall" ABI.
FCP was substituted by a poll, and the poll has been accepted.
|
|
llvm-wrapper: adapt for LLVM API changes
No functional changes intended.
Adapts llvm-wrapper for https://github.com/llvm/llvm-project/commit/65e57bbed06d55cab7bb64d54891d33ccb2d4159.
Found by our experimental rust + llvm @ HEAD CI:
https://buildkite.com/llvm-project/rust-llvm-integrate-prototype/builds/21304#0189c526-86cd-4db9-bdbc-dd0132dfc22b/197-500
|
|
Set max_atomic_width for sparc-unknown-linux-gnu to 32
This is currently set to 64
https://github.com/rust-lang/rust/blob/90f0b24ad3e7fc0dc0e419c9da30d74629cd5736/compiler/rustc_target/src/spec/sparc_unknown_linux_gnu.rs#L8
However, AFAIK, this architecture doesn't support 64-bit atomics, and LLVM generates libcalls: https://godbolt.org/z/chzThWGG1
(Currently, attempts to run `cargo test` for this target result in "undefined reference to `__sync_val_compare_and_swap_8'" error. https://github.com/taiki-e/rust-cross-toolchain/commit/02efe1e74f2280f06662eaf275690883b2f9c7ae)
r? `@Amanieu`
|
|
Set max_atomic_width for AVR to 16
This is currently set to 0
https://github.com/rust-lang/rust/blob/90f0b24ad3e7fc0dc0e419c9da30d74629cd5736/compiler/rustc_target/src/spec/avr_gnu_base.rs#L26-L27
However, LLVM supports {8,16}-bit atomic load/store on AVR (support for RMW is still quite incomplete and only partially supported).
https://github.com/llvm/llvm-project/blob/llvmorg-15.0.0/llvm/test/CodeGen/AVR/atomics/load8.ll#L5-L13
https://github.com/llvm/llvm-project/blob/llvmorg-15.0.0/llvm/test/CodeGen/AVR/atomics/load16.ll#L3-L12
https://github.com/llvm/llvm-project/blob/llvmorg-15.0.0/llvm/test/CodeGen/AVR/atomics/store.ll#L3-L22
cc #99668
r? `@Amanieu`
|
|
Add trait decls to SMIR
r? `@oli-obk`
Closes https://github.com/rust-lang/project-stable-mir/issues/20
|
|
Bubble up nested goals from equation in `predicates_for_object_candidate`
This used to be needed for https://github.com/rust-lang/rust/pull/114036#discussion_r1273987510, but since it's no longer, I'm opening this as a separate PR. This also fixes one ICEing UI test: (`tests/ui/unboxed-closures/issue-53448.rs`)
r? `@lcnr`
|
|
|
|
Make `unconditional_recursion` warning detect recursive drops
Closes #55388
Also closes #50049 unless we want to keep it for the second example which this PR does not solve, but I think it is better to track that work in #57965.
r? `@oli-obk` since you are the mentor for #55388
Unresolved questions:
- [x] There are two false positives that must be fixed before merging (see diff). I suspect the best way to solve them is to perform analysis after drop elaboration instead of before, as now, but I have not explored that any further yet. Could that be an option? **Answer:** Yes, that solved the problem.
`@rustbot` label +T-compiler +C-enhancement +A-lint
|
|
|
|
|
|
|
|
|
|
|
|
Style fix and refactor on resolve diagnostics
- coding style
- refactor api of `span_look_ahead`
|
|
Add a new `compare_bytes` intrinsic instead of calling `memcmp` directly
As discussed in #113435, this lets the backends be the place that can have the "don't call the function if n == 0" logic, if it's needed for the target. (I didn't actually *add* those checks, though, since as I understood it we didn't actually need them on known targets?)
Doing this also let me make it `const` (unstable), which I don't think `extern "C" fn memcmp` can be.
cc `@RalfJung` `@Amanieu`
|
|
Rollup of 6 pull requests
Successful merges:
- #114535 (bump schannel, miow to drop windows-sys 0.42)
- #114542 (interpret: use ConstPropNonsense for more const-prop induced issues)
- #114543 (add tests for some fixed ConstProp ICEs)
- #114550 (Generate better function argument names in global_allocator expansion)
- #114556 (Issue numbers are enforced on active features; remove FIXME)
- #114558 (Remove FIXME about NLL diagnostic that is already improved)
Failed merges:
- #114485 (Add trait decls to SMIR)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Co-authored-by: Ralf Jung <post@ralfj.de>
|
|
|
|
Issue numbers are enforced on active features; remove FIXME
Since https://github.com/rust-lang/rust/pull/51090 tidy enforces that active features have an issue number, so remove the FIXME.
This PR is part of #44366 which is E-help-wanted.
|
|
Generate better function argument names in global_allocator expansion
Generated code for `#[global_allocator] static ALLOCATOR: Allocator = Allocator;`—
**Before:**
```rust
const _: () = {
#[rustc_std_internal_symbol]
unsafe fn __rust_alloc(arg0: usize, arg1: usize) -> *mut u8 {
::core::alloc::GlobalAlloc::alloc(
&ALLOCATOR,
::core::alloc::Layout::from_size_align_unchecked(arg0, arg1),
)
}
#[rustc_std_internal_symbol]
unsafe fn __rust_dealloc(arg0: *mut u8, arg1: usize, arg2: usize) -> () {
::core::alloc::GlobalAlloc::dealloc(
&ALLOCATOR,
arg0,
::core::alloc::Layout::from_size_align_unchecked(arg1, arg2),
)
}
#[rustc_std_internal_symbol]
unsafe fn __rust_realloc(
arg0: *mut u8,
arg1: usize,
arg2: usize,
arg3: usize,
) -> *mut u8 {
::core::alloc::GlobalAlloc::realloc(
&ALLOCATOR,
arg0,
::core::alloc::Layout::from_size_align_unchecked(arg1, arg2),
arg3,
)
}
#[rustc_std_internal_symbol]
unsafe fn __rust_alloc_zeroed(arg0: usize, arg1: usize) -> *mut u8 {
::core::alloc::GlobalAlloc::alloc_zeroed(
&ALLOCATOR,
::core::alloc::Layout::from_size_align_unchecked(arg0, arg1),
)
}
};
```
**After:**
```rust
const _: () = {
#[rustc_std_internal_symbol]
unsafe fn __rust_alloc(size: usize, align: usize) -> *mut u8 {
::core::alloc::GlobalAlloc::alloc(
&ALLOCATOR,
::core::alloc::Layout::from_size_align_unchecked(size, align),
)
}
#[rustc_std_internal_symbol]
unsafe fn __rust_dealloc(ptr: *mut u8, size: usize, align: usize) -> () {
::core::alloc::GlobalAlloc::dealloc(
&ALLOCATOR,
ptr,
::core::alloc::Layout::from_size_align_unchecked(size, align),
)
}
#[rustc_std_internal_symbol]
unsafe fn __rust_realloc(
ptr: *mut u8,
size: usize,
align: usize,
new_size: usize,
) -> *mut u8 {
::core::alloc::GlobalAlloc::realloc(
&ALLOCATOR,
ptr,
::core::alloc::Layout::from_size_align_unchecked(size, align),
new_size,
)
}
#[rustc_std_internal_symbol]
unsafe fn __rust_alloc_zeroed(size: usize, align: usize) -> *mut u8 {
::core::alloc::GlobalAlloc::alloc_zeroed(
&ALLOCATOR,
::core::alloc::Layout::from_size_align_unchecked(size, align),
)
}
};
```
|
|
interpret: use ConstPropNonsense for more const-prop induced issues
|
|
Steal MIR for CTFE when possible.
Some bodies, like constants, have CTFE MIR but no optimized MIR.
In that case, have `mir_for_ctfe` steal the MIR instead of cloning it.
|
|
Rollup of 5 pull requests
Successful merges:
- #114466 (Add Allocation to SMIR)
- #114505 (Add documentation to has_deref)
- #114519 (use offset_of! to calculate dirent64 field offsets)
- #114537 (Migrate GUI colors test to original CSS color format)
- #114539 (linkchecker: Remove unneeded FIXME about intra-doc links)
Failed merges:
- #114485 (Add trait decls to SMIR)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
parent_module_from_def_id does not need to be a query.
r? `@ghost`
|
|
|
|
Add documentation to has_deref
Documentation of `has_deref` needed some polish to be more clear about where it should be used and what's it's purpose.
cc https://github.com/rust-lang/rust/issues/114401
r? `@RalfJung`
|
|
Add Allocation to SMIR
As it's discussed [here ](https://rust-lang.zulipchat.com/#narrow/stream/320896-project-stable-mir/topic/Representing.20Constants.20in.20smir)this is an attempt to cover Constants for smir in a different way compared to https://github.com/rust-lang/rust/pull/114342
cc https://github.com/rust-lang/project-stable-mir/issues/15
r? ``@oli-obk``
|
|
don't replace opaque types under binders with infer vars
Fixes an ICE in the ui test code.
Fixes #109636
Fixes #109281
Fixes #86800
r? `@oli-obk`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Consolidate opaque ty and async fn lowering code
The codepaths for lowering "regular" opaques and async fn were almost identical, modulo some bookkeeping that seemed pretty easy to consolidate.
r? `@cjgillot`
|
|
|
