`impl PartialEq<{str,String}> for {Path,PathBuf}`
This is a revival of #105877
Comparison of paths and strings is expected to be possible and needed e.g. in tests. This change adds the impls os `PartialEq` between strings and paths, both owned and unsized, in both directions.
ACP: https://github.com/rust-lang/libs-team/issues/151
library: Migrate from `cfg_if` to `cfg_select`
Migrate the standard library from using the external `cfg_if` crate to using the now-built-in `cfg_select` macro.
This does not yet eliminate the dependency from `library/std/Cargo.toml`, because while the standard library itself no longer uses `cfg_if`, it also incorporates the `backtrace` crate, which does.
Migration assisted by the following vim command (after selecting the full `cfg_if!` invocation):
```
'<,'>s/\(cfg_if::\)\?cfg_if/cfg_select/ | '<,'>s/^\( *\)} else {/\1}\r\1_ => {/c | '<,'>s/^\( *\)} else if #\[cfg(\(.*\))\] /\1}\r\1\2 => /e | '<,'>s/if #\[cfg(\(.*\))\] {/\1 => {/e
```
This is imperfect, but substantially accelerated the process. This prompts for confirmation on the `} else {` since that can also appear inside one of the arms. This also requires manual intervention to handle any multi-line conditions.
Resolve several ./x test failures on RISC-V caused by ABI and codegen
differences. Update multiple codegen-llvm tests for compatibility, and
explicitly set the target for transmute-scalar.rs to x86_64 to ensure
consistent behavior across hosts.
We had an issue on our LLVM-head Rust builder where it got stuck with
this test failing because it was reusing the tmpdir between runs and
something broke the incremental compile. Everything seems to work fine
with run_in_tmpdir in this test. tests/run-make/uefi-qemu also uses the
same tmpdir across runs, but I don't have the right environment to test
that so I didn't try fixing it. That is the only use of
std::env::temp_dir left in run-make tests after this fix.
Third-party programs running on the VEX V5
platform need a linker script to ensure code and
data are always placed in the allowed range
`0x3800000-0x8000000` which is read/write/execute.
However, users can also configure the operating
system to preload a separate file at any location
between these two addresses before the program
starts (as a sort of basic linking system).
Programs have to know about this at
compile time - in the linker script - to avoid
placing data in a spot that overlaps where the
file will be loaded. This is a very popular
feature with existing V5 runtimes because it can be
used to modify a program's behavior without
re-uploading the entire binary to the robot
controller. Also, while VEXos's user-exposed
file system APIs may only read data from an external
SD card, linked files have the advantage of being
able to load data directly from the device's
onboard storage.
This PR adds the `__linked_file_start` symbol
to the existing VEX V5 linker script which can be
used to shrink the stack and heap so that they
do not overlap with the memory region containing a
linked file.
With these changes, a developer targeting VEX V5
might add a second linker script to their project
by specifying `-Clink-arg=-Tcustom.ld` and creating
the file `custom.ld` to configure their custom
memory layout:
```ld
/* Reserve 10MiB for a linked file. */
/* (0x7600000-0x8000000) */
__linked_file_start = __linked_file_end - 10M;
/* Optional: specify one or more sections that */
/* represent the developer's custom format. */
SECTIONS {
.linked_file_metadata (NOLOAD) : {
__linked_file_metadata_start = .
. += 1M;
__linked_file_metadata_end = .
}
.linked_file_data (NOLOAD) : {
__linked_file_data_start = .
. += 9M;
__linked_file_data_end = .
}
} INSERT AFTER .stack;
```
Then, using an external tool like the `vex-v5-serial`
crate, they would configure the metadata of their
uploaded program to specify the path of their linked file
and the address where it should be loaded into memory
(in this example, 0x7600000).
Implement the accepted ACP for methods that find the index of the least
significant (lowest) and most significant (highest) set bit in an
integer for signed, unsigned, and NonZero types.
Also add unit tests for all these types.
This removes the #[no_sanitize] attribute, which was behind an unstable
feature named no_sanitize. Instead, we introduce the sanitize attribute
which is more powerful and allows to be extended in the future (instead
of just focusing on turning sanitizers off).
This also makes sanitize(kernel_address = ..) attribute work with
-Zsanitize=address
To do it the same as how clang disables address sanitizer, we now
disable ASAN on sanitize(kernel_address = "off") and KASAN on
sanitize(address = "off").
The same was added to clang in https://reviews.llvm.org/D44981.
This change implements the #[sanitize(..)] attribute, which opts to
replace the currently unstable #[no_sanitize]. Essentially the new
attribute works similar as #[no_sanitize], just with more flexible
options regarding where it is applied. E.g. it is possible to turn
a certain sanitizer either on or off:
`#[sanitize(address = "on|off")]`
This attribute now also applies to more places, e.g. it is possible
to turn off a sanitizer for an entire module or impl block:
```rust
\#[sanitize(address = "off")]
mod foo {
fn unsanitized(..) {}
#[sanitize(address = "on")]
fn sanitized(..) {}
}
\#[sanitize(thread = "off")]
impl MyTrait for () {
...
}
```
This attribute is enabled behind the unstable `sanitize` feature.
Speedup `copy_src_dirs` in bootstrap
I was kinda offended by how slow it was. Just the `copy_src_dirs` part took ~3s locally in the `x dist rustc-src` step. In release mode it was just 1s, but that's kind of cheating (I wonder if we should build bootstrap in release mode on CI though...).
Did some basic optimizations to bring it down to ~1s also in debug mode.
Maybe it's overkill, due to https://github.com/rust-lang/rust/pull/145455. Up to you whether we should merge it or close it :)
r? `````````@jieyouxu`````````
cg_llvm: Use LLVM-C bindings for `LLVMSetTailCallKind`, `LLVMGetTypeKind`
This PR replaces two existing `LLVMRust` bindings with equivalent calls to the LLVM-C API.
For `LLVMGetTypeKind`, we avoid the UB hazard by declaring the foreign function to return `RawEnum<TypeKind>` (which is a wrapper around `u32`), and then perform checked conversion from `u32` to `TypeKind`.
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.
Fix outdated doc comment
This updates the documentation comment for `Type::is_doc_subtype_of` to more accurately describe its purpose as a subtyping check, rather than equality
fixesrust-lang/rust#138572
r? ````````````@tgross35````````````
