| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Generalize `unsize` and `unsize_into` destinations
Just something that I noticed during other work. We do this for most such functions, so let's do it here, too.
r? ``@RalfJung``
|
|
Show the offset, length and memory of uninit read errors
r? ``@RalfJung``
I want to improve memory dumps in general. Not sure yet how to do so best within rust diagnostics, but in a perfect world I could generate a dummy in-memory file (that contains the rendered memory dump) that we then can then provide regular rustc `Span`s to. So we'd basically report normal diagnostics for them with squiggly lines and everything.
|
|
|
|
|
|
fix `-Zsanitizer=kcfi` on `#[naked]` functions
fixes https://github.com/rust-lang/rust/issues/143266
With `-Zsanitizer=kcfi`, indirect calls happen via generated intermediate shim that forwards the call. The generated shim preserves the attributes of the original, including `#[unsafe(naked)]`. The shim is not a naked function though, and violates its invariants (like having a body that consists of a single `naked_asm!` call).
My fix here is to match on the `InstanceKind`, and only use `codegen_naked_asm` when the instance is not a `ReifyShim`. That does beg the question whether there are other `InstanceKind`s that could come up. As far as I can tell the answer is no: calling via `dyn` seems to work find, and `#[track_caller]` is disallowed in combination with `#[naked]`.
r? codegen
````@rustbot```` label +A-naked
cc ````@maurer```` ````@rcvalle````
|
|
|
|
parse `const trait Trait`
r? oli-obk or anyone from project-const-traits
cc `@rust-lang/project-const-traits`
|
|
|
|
type_id_eq: check that the hash fully matches the type
The previous logic wouldn't always detect when the hash mismatches the provenance. Fix that by adding a new helper, `read_type_id`, that reads a single type ID while fully checking it for validity and consistency.
r? ``@oli-obk``
|
|
Make frame spans appear on a separate trace line
This PR changes tracing_chrome's `tracing::Layer` so that if a span has the "tracing_separate_line" field as one of the span arguments, that span is put on a separate trace line. See https://github.com/rust-lang/miri/pull/4451 for an earlier attempt and for screenshots explaining better what I mean by "separate trace line".
This PR also makes the "frame" span use this feature (so it appears on a separate trace line, see https://github.com/rust-lang/miri/pull/4451 for motivation), but passes `tracing::field::Empty` as the span parameter value so it is ignored by other tracing layers (e.g. the logger):
```rust
info_span!("frame", tracing_separate_line = Empty, "{}", instance);
```
<details><summary>Also see the following discussion I had with ``@RalfJung</summary>``
> Is there no way to attach metadata we could use instead?
[These](https://docs.rs/tracing-core/0.1.34/src/tracing_core/metadata.rs.html#57) are the **static** metadata items we can control about a span. We can't add more metadata outside of them. The most relevant are:
- `name` (for the frame span it's currently "frame")
- `target` which acts as the category (for the frame span it's currently "rustc_const_eval::interpret::stack" by default)
- `fields` which contains a list of the *names* of each of the arguments passed to the `span!` macro (for the frame span it's currently ["message"], where "message" is the default identifier for data passed in the `format!` syntax)
When the tracing code is called at runtime, the **dynamic** values of the arguments are collected into a [`ValueSet`](https://docs.rs/tracing-core/0.1.34/src/tracing_core/field.rs.html#166). Each argument value stored there corresponds with one of the static names stored in `fields` (see above).
---
We have already determined that filtering out spans by `name` is not a good idea, and I would say the same goes for `target`. Both the `name` and the `target` fields are printed to stderr when `MIRI_LOG=` is enabled, so changing them to contain an identifier (e.g. "frame:tracing_separate_root" instead of "frame" as the name) would uselessly clutter the text logs (unless we add one more filter [there](https://github.com/rust-lang/rust/blob/master/compiler/rustc_log/src/lib.rs#L137), but then it gets even more complicated).
```rust
// examples of how the above (problematic) solutions would look like
info_span!("frame:tracing_separate_root", "{}", instance);
info_span!(target: "tracing_separate_root", "frame", "{}", instance);
```
---
So that leaves us with `fields` and their runtime values. Now, my initial thought (inspired by [this comment](https://github.com/rust-lang/miri/pull/4451#issuecomment-3068072303)) was to use a field with the static name "tracing_separate_root" and with a dynamic boolean value of "true". In `tracing_chrome.rs` we can easily check if this field is true and act accordingly. This would work but then again this field would also be picked up by the logger when `MIRI_LOG=` is enabled, and would uselessly clutter the text logs.
```rust
// example of how the above (problematic) solution would look like
info_span!("frame", tracing_separate_root = true, "{}", instance);
```
---
To avoid cluttering the text logs, we can instead set "tracing_separate_root" to the dynamic value of `tracing::field::Empty`. Citing from [here](https://docs.rs/tracing/0.1.41/tracing/field/struct.Empty.html), "when a field’s value is `Empty`, it will not be recorded". "not being recorded" means that the field and its value won't be printed to stderr text logs, nor will it be printed by any other tracing layers that might be attached in the future. In `tracing_chrome.rs` we would still be able to check if "tracing_separate_root" is in the list of static `fields`, and act accordingly. So I believe this solution would effectively allow us to attach metadata to a span in a way that does not clutter logs and still allows being read in `tracing_chrome.rs`.
If we ever wanted to pass arbitrary metadata (i.e. not just a present/not present flag), it would be possible with a custom `Empty` that also holds data and implement `Value` without doing anything ([like `Empty` does](https://docs.rs/tracing-core/0.1.34/src/tracing_core/field.rs.html#775)).
```rust
// example of how the above solution would look like
info_span!("frame", tracing_separate_root = tracing::field::Empty, "{}", instance);
```
</details>
|
|
r=RalfJung,fee1-dead
add `const_make_global`; err for `const_allocate` ptrs if didn't call
Implements as discussed on Zulip: [#t-compiler/const-eval > const heap](https://rust-lang.zulipchat.com/#narrow/channel/146212-t-compiler.2Fconst-eval/topic/const.20heap/with/527125421)
r? ```@rust-lang/wg-const-eval```
Fixes https://github.com/rust-lang/rust/issues/129233
|
|
|
|
Add tracing to `InterpCx::fn_abi_of_instance/fn_abi_of_fn_ptr`
This PR adds tracing to the `InterpCx::fn_abi_of_instance`/`::fn_abi_of_fn_ptr` functions by shadowing `FnAbiOf`'s trait methods with inherent methods on `InterpCx`, like done in rust-lang/rust#142721. The reason why I am targeting these two functions is because they are used for Miri interpretation, and they make a `layout_of` query down the line without passing through the `layout_of` that was traced in rust-lang/rust#142721.
There are other places where `layout_of` is called without being traced (see the analysis below), but that's because the `Machine` used there is not `MiriMachine` but rather `CompileTimeMachine` which does not implement `enter_trace_span()`. But after discussing with ```````@RalfJung``````` we agreed that the const-eval part should not be traced together with Miri, that's why I am ignoring the other places where `layout_of` is called.
r? ```````@RalfJung```````
<details><summary>Analysis of the places where <code>layout_of</code> is called</summary>
I did some analysis for https://github.com/rust-lang/rust/pull/142721#discussion_r2171494841, and these are all the places where the query `tcx.layout_of` is called (directly or indirectly) outside of a traced `InterpCx::layout_of` while a program is being interpreted by Miri:
```
adjust_for_rust_scalar at ./compiler/rustc_ty_utils/src/abi.rs:302:35
{closure#2} at ./compiler/rustc_ty_utils/src/abi.rs:522:25
eval_body_using_ecx<> at ./compiler/rustc_const_eval/src/const_eval/eval_queries.rs:49:22
{closure#1}<> at ./compiler/rustc_const_eval/src/interpret/operand.rs:851:76
{closure#0}<> at ./compiler/rustc_const_eval/src/interpret/stack.rs:612:18
size_and_align at ./compiler/rustc_middle/src/mir/interpret/mod.rs:387:38
```
I got these by:
- patching rustc with this patch that adds a span to the `layout_of` query which prints the backtrace:
[layout_of_other_places.diff.txt](https://github.com/user-attachments/files/21235523/layout_of_other_places.diff.txt)
- adding this to my bootstrap.toml to have debug symbols inside the Miri binary: `rust.debuginfo-level = "line-tables-only"` and also `build.tool.miri.features = ["tracing"]`
- obtaining a trace file with `MIRI_TRACING=1 ./x.py run miri --stage 1 --warnings warn --args src/tools/miri/tests/pass/hello.rs` (note: maybe using a file different than "src/tools/miri/tests/pass/hello.rs" would lead to more places where layout_of is called?)
- running this query in Perfetto to select all `layout_of` spans that have as a direct parent a span named "frame" (as opposed to the parent being `InterpCx::layout_of`) and extract their backtrace: `select args.string_value from slice left join args on slice.arg_set_id = args.id where slice.name = "tcx.layout_of" and slice.parent_id in (select slice2.id from slice as slice2 where slice2.name = "frame") group by args.string_value`
- exporting the data as `.tsv` and processing that file through this Python script. It finds the first path in the backtraces where "layout" isn't mentioned, which imo is a good heuristic to not consider `layout_of` wrappers/friends as call places, but rather go down the backtrace until an actual call place is reached. [layout_of_other_places.py.txt](https://github.com/user-attachments/files/21235529/layout_of_other_places.py.txt)
</details>
|
|
miri: fix out-of-bounds error for ptrs with negative offsets
r? ```````@oli-obk```````
|
|
|
|
|
|
This was done by making the tracing_chrome tracing layer check if "tracing_separate_line" was in the arguments of a span, and act accordingly.
|
|
|
|
Co-Authored-By: Ralf Jung <post@ralfj.de>
|
|
|
|
Co-Authored-By: Ralf Jung <post@ralfj.de>
Co-Authored-By: Oli Scherer <github333195615777966@oli-obk.de>
|
|
|
|
|
|
interpret/allocation: expose init + write_wildcards on a range
Part of https://github.com/rust-lang/miri/pull/4456, so that we can mark down when a foreign access to our memory happened. Should this also move `prepare_for_native_access()` itself into Miri, given that everything there can be implemented on Miri's side?
r? `````@RalfJung`````
|
|
|
|
|
|
interpreter
|
|
|
|
|
|
|
|
Hopefully this will make tracing calls be optimized out properly when tracing is disabled
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#132469 (Do not suggest borrow that is already there in fully-qualified call)
- rust-lang/rust#143340 (awhile -> a while where appropriate)
- rust-lang/rust#143438 (Fix the link in `rustdoc.md`)
- rust-lang/rust#143539 (Regression tests for repr ICEs)
- rust-lang/rust#143566 (Fix `x86_64-unknown-netbsd` platform support page)
- rust-lang/rust#143572 (Remove unused allow attrs)
- rust-lang/rust#143583 (`loop_match`: fix 'no terminator on block')
- rust-lang/rust#143584 (make `Machine::load_mir` infallible)
- rust-lang/rust#143591 (Fix missing words in future tracking issue)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
make `Machine::load_mir` infallible
it doesn't need to return an `InterpResult`.
|
|
Allow custom default address spaces and parse `p-` specifications in the datalayout string
Some targets, such as CHERI, use as default an address space different from the "normal" default address space `0` (in the case of CHERI, [200 is used](https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-877.pdf)). Currently, `rustc` does not allow to specify custom address spaces and does not take into consideration [`p-` specifications in the datalayout string](https://llvm.org/docs/LangRef.html#langref-datalayout).
This patch tries to mitigate these problems by allowing targets to define a custom default address space (while keeping the default value to address space `0`) and adding the code to parse the `p-` specifications in `rustc_abi`. The main changes are that `TargetDataLayout` now uses functions to refer to pointer-related informations, instead of having specific fields for the size and alignment of pointers in the default address space; furthermore, the two `pointer_size` and `pointer_align` fields in `TargetDataLayout` are replaced with an `FxHashMap` that holds info for all the possible address spaces, as parsed by the `p-` specifications.
The potential performance drawbacks of not having ad-hoc fields for the default address space will be tested in this PR's CI run.
r? workingjubilee
|
|
it doesn't need to return an `InterpResult`.
|
|
default data address space
|
|
|
|
use `is_multiple_of` and `div_ceil`
In tricky logic, these functions are much more informative than the manual implementations. They also catch subtle bugs:
- the manual `is_multiple_of` often does not handle division by zero
- manual `div_ceil` often does not consider overflow
The transformation is free for `is_multiple_of` if the divisor is compile-time known to be non-zero. For `div_ceil` there is a small cost to considering overflow. Here is some assembly https://godbolt.org/z/5zP8KaE1d.
|
|
|
|
|
|
Port `#[target_feature]` to new attribute parsing infrastructure
Ports `target_feature` to the new attribute parsing infrastructure for https://github.com/rust-lang/rust/issues/131229#issuecomment-2971353197
r? ``@jdonszelmann``
|
|
setup typos check in CI
This allows to check typos in CI, currently for compiler only (to reduce commit size with fixes). With current setup, exclude list is quite short, so it worth trying?
Also includes commits with actual typo fixes.
MCP: https://github.com/rust-lang/compiler-team/issues/817
typos check currently turned for:
* ./compiler
* ./library
* ./src/bootstrap
* ./src/librustdoc
After merging, PRs which enables checks for other crates (tools) can be implemented too.
Found typos will **not break** other jobs immediately: (tests, building compiler for perf run). Job will be marked as red on completion in ~ 20 secs, so you will not forget to fix it whenever you want, before merging pr.
Check typos: `python x.py test tidy --extra-checks=spellcheck`
Apply typo fixes: `python x.py test tidy --extra-checks=spellcheck:fix` (in case if there only 1 suggestion of each typo)
Current fail in this pr is expected and shows how typo errors emitted. Commit with error will be removed after r+.
|
|
|
|
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
|
|
miri: improve errors for type validity assertion failures
Miri has pretty nice errors for type validity violations, printing which field in the type the problem occurs at and so on.
However, we don't see these errors when using e.g. `mem::zeroed` as that uses `assert_zero_valid` to bail out before Miri can detect the UB.
Similar to what we did with `@saethlin's` UB checks, I think we should disable such language UB checks in Miri so that we can get better error messages. If we go for this we should probably say this in the intrinsic docs as well so that people don't think they can rely on these intrinsics catching anything.
Furthermore, I slightly changed `MaybeUninit::assume_init` so that the `.value` field does not show up in error messages any more.
`@rust-lang/miri` what do you think?
|
|
|
|
|
