| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
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`````
|
|
|
|
|
|
default data address space
|
|
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+.
|
|
|
|
|
|
Introduce `ByteSymbol`
It's like `Symbol` but for byte strings. The interner is now used for both `Symbol` and `ByteSymbol`. E.g. if you intern `"dog"` and `b"dog"` you'll get a `Symbol` and a `ByteSymbol` with the same index and the characters will only be stored once.
The motivation for this is to eliminate the `Arc`s in `ast::LitKind`, to make `ast::LitKind` impl `Copy`, and to avoid the need to arena-allocate `ast::LitKind` in HIR. The latter change reduces peak memory by a non-trivial amount on literal-heavy benchmarks such as `deep-vector` and `tuple-stress`.
`Encoder`, `Decoder`, `SpanEncoder`, and `SpanDecoder` all get some changes so that they can handle normal strings and byte strings.
|
|
It's like `Symbol` but for byte strings. The interner is now used for
both `Symbol` and `ByteSymbol`. E.g. if you intern `"dog"` and `b"dog"`
you'll get a `Symbol` and a `ByteSymbol` with the same index and the
characters will only be stored once.
The motivation for this is to eliminate the `Arc`s in `ast::LitKind`, to
make `ast::LitKind` impl `Copy`, and to avoid the need to arena-allocate
`ast::LitKind` in HIR. The latter change reduces peak memory by a
non-trivial amount on literal-heavy benchmarks such as `deep-vector` and
`tuple-stress`.
`Encoder`, `Decoder`, `SpanEncoder`, and `SpanDecoder` all get some
changes so that they can handle normal strings and byte strings.
This change does slow down compilation of programs that use
`include_bytes!` on large files, because the contents of those files are
now interned (hashed). This makes `include_bytes!` more similar to
`include_str!`, though `include_bytes!` contents still aren't escaped,
and hashing is still much cheaper than escaping.
|
|
|
|
|
|
such constants as patterns
|
|
interpret/allocation: Fixup type for `alloc_bytes`
This can be `FnOnce`, which helps us avoid an extra clone in rust-lang/miri#4343
r? RalfJung
|
|
GCI: At their def site, actually wfcheck the where-clause & always eval free lifetime-generic constants
* 1st commit: Partially addresses [#136204](https://github.com/rust-lang/rust/issues/136204) by turning const eval errors from post to pre-mono for free lifetime-generic constants.
* As the linked issue/comment states, on master there's a difference between `const _: () = panic!();` (pre-mono error) and `const _<'a>: () = panic!();` (post-mono error) which feels wrong.
* With this PR, both become pre-mono ones!
* 2nd commit: Oof, yeah, I missed that in the initial impl!
This doesn't fully address #136204 because I still haven't figured out how & where to properly & best suppress const eval of free constants whose predicates don't hold at the def site. The motivating example is `const _UNUSED: () = () where for<'_delay> String: Copy;` which can also be found over at the tracking issue #113521.
r? compiler-errors or reassign
|
|
|
|
|
|
intrinsics, ScalarInt: minor cleanup
Taken out of https://github.com/rust-lang/rust/pull/141507 while we resolve technical disagreements in that PR.
r? ``@bjorn3``
|
|
|
|
|
|
|
|
interpret: better error message for out-of-bounds pointer arithmetic and accesses
Fixes https://github.com/rust-lang/rust/issues/93881
r? `@saethlin`
|
|
accesses
|
|
|
|
|
|
|
|
Add a .bss-like scheme for encoded const allocs
This check if all bytes are zero feel like it should be too slow, and instead we should have a flag that we track, but that seems hard. Let's see how this perfs first.
Also we can probably stash the "it's all zero actually" flag inside one of the other struct members that's already not using an entire byte. This optimization doesn't fire all that often, so it's possible that by sticking it in the varint length field, this PR actually makes rmeta size worse.
|
|
Convert `ShardedHashMap` to use `hashbrown::HashTable`
The `hash_raw_entry` feature (#56167) has finished fcp-close, so the compiler
should stop using it to allow its removal. Several `Sharded` maps were
using raw entries to avoid re-hashing between shard and map lookup, and
we can do that with `hashbrown::HashTable` instead.
|
|
memory FFI can access
|
|
The `hash_raw_entry` feature has finished fcp-close, so the compiler
should stop using it to allow its removal. Several `Sharded` maps were
using raw entries to avoid re-hashing between shard and map lookup, and
we can do that with `hashbrown::HashTable` instead.
|
|
r=compiler-errors
compiler: Use `size_of` from the prelude instead of imported
Use `std::mem::{size_of, size_of_val, align_of, align_of_val}` from the prelude instead of importing or qualifying them. Apply this change across the compiler.
These functions were added to all preludes in Rust 1.80.
r? ``@compiler-errors``
|
|
Use `std::mem::{size_of, size_of_val, align_of, align_of_val}` from the
prelude instead of importing or qualifying them.
These functions were added to all preludes in Rust 1.80.
|
|
interpret/provenance_map: consistently use range_is_empty
https://github.com/rust-lang/rust/pull/137704 started using this for per-ptr provenance; let's be consistent and use it also for the per-byte provenance check. Also rename the methods to avoid having both "get" and "is_empty" in the name.
r? ````@oli-obk````
|
|
Revert "store ScalarPair via memset when one side is undef and the other side can be memset"
cc #137892
reverts #135335
r? oli-obk
|
|
|
|
This reverts commit a7a6c64a657f68113301c2ffe0745b49a16442d1, reversing
changes made to ebbe63891f1fae21734cb97f2f863b08b1d44bf8.
|
|
Currently it gets the pointers in the range and checks if the result is
empty, but it can be done faster if you combine those two steps.
|
|
Make it so that every structured error annotated with `#[derive(Diagnostic)]` that has a field of type `Ty<'_>`, the printing of that value into a `String` will look at the thread-local storage `TyCtxt` in order to shorten to a length appropriate with the terminal width. When this happen, the resulting error will have a note with the file where the full type name was written to.
```
error[E0618]: expected function, found `((..., ..., ..., ...), ..., ..., ...)``
--> long.rs:7:5
|
6 | fn foo(x: D) { //~ `x` has type `(...
| - `x` has type `((..., ..., ..., ...), ..., ..., ...)`
7 | x(); //~ ERROR expected function, found `(...
| ^--
| |
| call expression requires function
|
= note: the full name for the type has been written to 'long.long-type-14182675702747116984.txt'
= note: consider using `--verbose` to print the full type name to the console
```
|
|
|
|
|
|
|
|
Simplify intra-crate qualifiers.
The following is a weird pattern for a file within `rustc_middle`:
```
use rustc_middle::aaa;
use crate::bbb;
```
More sensible and standard would be this:
```
use crate::{aaa, bbb};
```
I.e. we generally prefer using `crate::` to using a crate's own name. (Exceptions are things like in macros where `crate::` doesn't work because the macro is used in multiple crates.)
This commit fixes a bunch of these weird qualifiers.
r? `@jieyouxu`
|
|
The following is a weird pattern for a file within `rustc_middle`:
```
use rustc_middle::aaa;
use crate::bbb;
```
More sensible and standard would be this:
```
use crate::{aaa, bbb};
```
I.e. we generally prefer using `crate::` to using a crate's own name.
(Exceptions are things like in macros where `crate::` doesn't work
because the macro is used in multiple crates.)
This commit fixes a bunch of these weird qualifiers.
|
|
We cannot produce anything useful if asked to compile unknown targets.
We should handle the error immediately at the point of discovery instead
of propagating it upward, and preferably in the simplest way: Die.
This allows cleaning up our "error-handling" spread across 5 crates.
|
|
|
|
We have four macros for generating trivial traversal (fold/visit) and
lift impls.
- `rustc_ir::TrivialTypeTraversalImpls`
- `rustc_middle::TrivialTypeTraversalImpls`
- `rustc_middle::TrivialLiftImpls`
- `rustc_middle::TrivialTypeTraversalAndLiftImpls`
The first two are very similar. The last one just combines the second
and third one.
The macros themselves are ok, but their use is a mess. This commit does
the following.
- Removes types that no longer need a lift and/or traversal impl from
the macro calls.
- Consolidates the macro calls into the smallest number of calls
possible, with each one mentioning as many types as possible.
- Orders the types within those macro calls alphabetically, and makes
the module qualification more consistent.
- Eliminates `rustc_middle::mir::type_foldable`, because the macro calls
were merged and the manual `TypeFoldable` impls are better placed in
`structural_impls.rs`, alongside all the other ones.
This makes the code more concise. Moving forward, it also makes it more
obvious where new types should be added.
|
|
Shard AllocMap Lock
This improves performance on many-seed parallel (-Zthreads=32) miri executions from managing to use ~8 cores to using 27-28 cores, which is about the same as what I see with the data structure proposed in https://github.com/rust-lang/rust/pull/136105 - I haven't analyzed but I suspect the sharding might actually work out better if we commonly insert "densely" since sharding would split the cache lines and the OnceVec packs locks close together. Of course, we could do something similar with the bitset lock too.
Either way, this seems like a very reasonable starting point that solves the problem ~equally well on what I can test locally.
r? `@RalfJung`
|
|
This improves performance on many-seed parallel (-Zthreads=32) miri
executions from managing to use ~8 cores to using 27-28 cores. That's
pretty reasonable scaling for the simplicity of this solution.
|
|
|
