| Age | Commit message (Collapse) | Author | Lines |
|
|
|
|
|
Add a tidy check for files with over 3,000 lines
Files with a large number of lines can cause issues in GitHub (e.g. https://github.com/rust-lang/rust/issues/60015) and also tend to be indicative of opportunities to refactor into less monolithic structures.
This adds a new check to tidy to warn against files that have more than 3,000 lines, as suggested in https://github.com/rust-lang/rust/issues/60015#issuecomment-483868594. (This number was chosen fairly arbitrarily as a reasonable indicator of size.) This check can be ignored with `// ignore-tidy-filelength`.
Existing files with greater than 3,000 lines currently ignore the check, but this helps us spot when files are getting too large. (We might try to split up all files larger than this in the future, as in https://github.com/rust-lang/rust/issues/60015).
|
|
|
|
|
|
|
|
|
|
|
|
add Miri error variant for process exit
This is to support https://github.com/rust-lang/miri/pull/702
r? @oli-obk
|
|
|
|
Refactor Adjust and CastKind
fixes rust-lang#59588
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Miri: refactor new allocation tagging
Tagging and initializing `AllocExtra` now go hand-in-hand so one cannot forget to do one when doing the other. In particular, `memory.allocate` is now much easier to use correctly (because it will already return a tagged pointer).
r? @oli-obk
|
|
|
|
|
|
HirIdify hir::Def
cc @ljedrz
r? @oli-obk
|
|
Increase `Span` from 4 bytes to 8 bytes.
This increases the size of some important types, such as `ast::Expr` and
`mir::Statement`. However, it drastically reduces how much the interner
is used, and the fields are more natural sizes that don't require bit
operations to extract.
As a result, instruction counts drop across a range of workloads, by as
much as 10% for `script-servo` incremental builds.
Peak memory usage goes up a little for some cases, but down by more for
some other cases -- as much as 18% for non-incremental builds of
`packed-simd`.
The commit also:
- removes the `repr(packed)`, because it has negligible effect, but can
cause undefined behaviour;
- replaces explicit impls of common traits (`Copy`, `PartialEq`, etc.)
with derived ones.
r? @petrochenkov
|
|
|
|
It is now exactly equivalent to lookup_char_pos.
|
|
This increases the size of some important types, such as `ast::Expr` and
`mir::Statement`. However, it drastically reduces how much the interner
is used, and the fields are more natural sizes that don't require bit
operations to extract.
As a result, instruction counts drop across a range of workloads, by as
much as 12% for incremental "check" builds of `script-servo`.
Peak memory usage goes up a little for some cases, but down by more for
some other cases -- as much as 18% for non-incremental builds of
`packed-simd`.
The commit also:
- removes the `repr(packed)`, because it has negligible effect, but can
cause undefined behaviour;
- replaces explicit impls of common traits (`Copy`, `PartialEq`, etc.)
with derived ones.
|
|
|
|
Shrink `mir::Statement`.
The `InlineAsm` variant is extremely rare, and `mir::Statement` often
contributes significantly to peak memory usage.
|
|
Remove adt_def from projections and downcasts in MIR
As part of optimizing generator layouts in MIR, we'd like to allow downcasting generators to variants which do not have a corresponding `def_id`, since they are created by the compiler.
This refactor hopes to allow that, without regressing perf.
r? @eddyb
|
|
The `InlineAsm` variant is extremely rare, and `mir::Statement` often
contributes significantly to peak memory usage.
|
|
|
|
|
|
|
|
|
|
Renames `EvalContext` to `InterpretCx`
This PR renames `EvalContext` to `InterpretCx` in `src/librustc_mir`.
This PR is related to #54395 .
|
|
|
|
Merge `Promoted` and `Static` in `mir::Place`
fixes #53848
|
|
|
|
This commit makes two changes - separating the `NodeId` that identifies
an enum variant from the `NodeId` that identifies the variant's
constructor; and no longer creating a `NodeId` for `Struct`-style enum
variants and structs.
Separation of the variant id and variant constructor id will allow the
rest of RFC 2008 to be implemented by lowering the visibility of the
variant's constructor without lowering the visbility of the variant
itself.
No longer creating a `NodeId` for `Struct`-style enum variants and
structs mostly simplifies logic as previously this `NodeId` wasn't used.
There were various cases where the `NodeId` wouldn't be used unless
there was an unit or tuple struct or enum variant but not all uses of
this `NodeId` had that condition, by removing this `NodeId`, this must
be explicitly dealt with. This change mostly applied cleanly, but there
were one or two cases in name resolution and one case in type check
where the existing logic required a id for `Struct`-style enum variants
and structs.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Optimize copying large ranges of undefmask blocks
Hopefully fixes #58523
|
|
|
|
|
|
|