Remove the `#[no_sanitize]` attribute in favor of `#[sanitize(xyz = "on|off")]`
This came up during the sanitizer stabilization (rust-lang/rust#123617). Instead of a `#[no_sanitize(xyz)]` attribute, we would like to have a `#[sanitize(xyz = "on|off")]` attribute, which is more powerful and allows to be extended in the future (instead
of just focusing on turning sanitizers off). The implementation is done according to what was [discussed on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/343119-project-exploit-mitigations/topic/Stabilize.20the.20.60no_sanitize.60.20attribute/with/495377292)).
The new attribute also works on modules, traits and impl items and thus enables usage as the following:
```rust
#[sanitize(address = "off")]
mod foo {
fn unsanitized(..) {}
#[sanitize(address = "on")]
fn sanitized(..) {}
}
trait MyTrait {
#[sanitize(address = "off")]
fn unsanitized_default(..) {}
}
#[sanitize(thread = "off")]
impl MyTrait for () {
...
}
```
r? ```@rcvalle```
`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
Just like we implemented relatively complex rules to imply other extensions
**from** "C" (and some others), this commit implements implication
**to** the "C" extension from others, complying the following text
in the ISA Manual (although there's no direct imply/depend references).
> The C extension is the superset of the following extensions:
>
> - Zca
> - Zcf if F is specified (RV32 only)
> - Zcd if D is specified
This is formally verified so that no other extension combinations
(*not* in this implementation) can (currently) imply the "C" extension.
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).
This requires making the `deref_addrof` lint a late lint instead of an
early lint to check for types.
changelog: [`deref_addrof`]: do not suggest implicit `DerefMut` on
`ManuallyDrop` union fields
Fixrust-lang/rust-clippy#14386
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.
