| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
Some `let chains` clean-up
Not sure if this kind of clean-up is welcoming because of size, but I decided to try out one
r? compiler
|
|
|
|
`loop_match`: suggest extracting to a `const` item
tracking issue: https://github.com/rust-lang/rust/issues/132306
fixes https://github.com/rust-lang/rust/issues/143310
fixes https://github.com/rust-lang/rust/issues/143936
|
|
Because doc code does not get automatically formatted, some doc code has
creative placements of comments that automatic formatting can't handle.
Reformat those comments to make the resulting code support standard Rust
formatting without breaking; this is generally an improvement to
readability as well.
Some comments are not indented to the prevailing indent, and are instead
aligned under some bit of code. Indent them to the prevailing indent,
and put spaces *inside* the comments to align them with code.
Some comments span several lines of code (which aren't the line the
comment is about) and expect alignment. Reformat them into one comment
not broken up by unrelated intervening code.
Some comments are placed on the same line as an opening brace, placing
them effectively inside the subsequent block, such that formatting would
typically format them like a line of that block. Move those comments to
attach them to what they apply to.
Some comments are placed on the same line as a one-line braced block,
effectively attaching them to the closing brace, even though they're
about the code inside the block. Reformat to make sure the comment will
stay on the same line as the code it's commenting.
|
|
if the expression cannot be evaluated in a straightforward way
|
|
MIR-build: No longer emit assumes in enum-as casting
This just uses the `valid_range` from the backend, so it's duplicating the range metadata that now we include on parameters and loads, and thus no longer seems to be useful -- notably there's no codegen test failures from removing it.
(Because it's using data from the same source as the backend annotations, it doesn't do anything to mitigate things like rust-lang/rust#144388 where the range in the layout is more permissive than the actual possible discriminants. A variant of this that actually checked the discriminants more specifically might be useful, so could potentially be added in future, but I don't think the *current* checks are actually providing value.)
r? mir
Randomly turns out that this
Fixes https://github.com/rust-lang/rust/issues/121097
|
|
This just uses the `valid_range` from the backend, so it's duplicating the range metadata that now we include on parameters and loads.
|
|
|
|
|
|
Port `#[automatically_derived]` to the new attribute parsing infrastructure
Ports `#[automatically_derived]` to the new attribute parsing infrastructure for https://github.com/rust-lang/rust/issues/131229#issuecomment-2971351163
r? `@oli-obk`
cc `@jdonszelmann`
|
|
|
|
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
|
|
`rustc_pattern_analysis`: always check that deref patterns don't match on the same place as normal constructors
In rust-lang/rust#140106, deref pattern validation was tied to the `deref_patterns` feature to temporarily avoid affecting perf. However:
- As of rust-lang/rust#143414, box patterns are represented as deref patterns in `rustc_pattern_analysis`. Since they can be used by enabling `box_patterns` instead of `deref_patterns`, it was possible for them to skip validation, resulting in an ICE. This fixes that and adds a regression test.
- External tooling (e.g. rust-analyzer) will also need to validate matches containing deref patterns, which was not possible. This fixes that by making `compute_match_usefulness` validate deref patterns by default.
In order to avoid doing an extra pass for anything with patterns, the second commit makes `RustcPatCtxt` keep track of whether it encounters a deref pattern, so that it only does the check if so. This is purely for performance. If the perf impact of the first commit is negligible and the complexity cost introduced by the second commit is significant, it may be worth dropping the latter.
r? `@Nadrieril`
|
|
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
|
|
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
|
|
|
|
default data address space
|
|
|
|
|
|
This removes special-casing of boxes from `rustc_pattern_analysis`, as a
first step in replacing `box_patterns` with `deref_patterns`.
Incidentally, it fixes a bug caused by box patterns being represented as
structs rather than pointers, where `exhaustive_patterns` could generate
spurious `unreachable_patterns` lints on arms required for
exhaustiveness; following the lint's advice would result in an error.
|
|
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+.
|
|
|
|
fixes issue 143203
|
|
|
|
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.
|
|
Avoid introducing a large number of changes when adding optional initialization fields.
|
|
Add runtime check to avoid overwrite arg in `Diag`
## Origin PR description
At first, I set up a `debug_assert` check for the arg method to make sure that `args` in `Diag` aren't easily overwritten, and I added the `remove_arg()` method, so that if you do need to overwrite an arg, then you can explicitly call `remove_arg()` to remove it first, then call `arg()` to overwrite it.
For the code before the rust-lang/rust#142015 change, it won't compile because it will report an error
```
arg `instance`already exists.
```
This PR also modifies all diagnostics that fail the check to pass the check. There are two cases of check failure:
1. ~~Between *the parent diagnostic and the subdiagnostic*, or *between the subdiagnostics* have the same field between them. In this case, I renamed the conflicting fields.~~
2. ~~For subdiagnostics stored in `Vec`, the rendering may iteratively write the same arg over and over again. In this case, I changed the auto-generation with `derive(SubDiagnostic)` to manually implementing `SubDiagnostic` and manually rendered it with `eagerly_translate()`, similar to https://github.com/rust-lang/rust/issues/142031#issuecomment-2984812090, and after rendering it I manually deleted useless arg with the newly added `remove_arg` method.~~
## Final Decision
After trying and discussing, we made a final decision.
For `#[derive(Subdiagnostic)]`, This PR made two changes:
1. After the subdiagnostic is rendered, remove all args of this subdiagnostic, which allows for usage like `Vec<Subdiag>`.
2. Store `diag.args` before setting arguments, so that you can restore the contents of the main diagnostic after deleting the arguments after subdiagnostic is rendered, to avoid deleting the main diagnostic's arg when they have the same name args.
|
|
|
|
restore snapshot when set subdiag arg
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
r=oli-obk,traviscross
Add `#[loop_match]` for improved DFA codegen
tracking issue: https://github.com/rust-lang/rust/issues/132306
project goal: https://github.com/rust-lang/rust-project-goals/issues/258
This PR adds the `#[loop_match]` attribute, which aims to improve code generation for state machines. For some (very exciting) benchmarks, see https://github.com/rust-lang/rust-project-goals/issues/258#issuecomment-2732965199
Currently, a very restricted syntax pattern is accepted. We'd like to get feedback and merge this now before we go too far in a direction that others have concerns with.
## current state
We accept code that looks like this
```rust
#[loop_match]
loop {
state = 'blk: {
match state {
State::A => {
#[const_continue]
break 'blk State::B
}
State::B => { /* ... */ }
/* ... */
}
}
}
```
- a loop should have the same semantics with and without `#[loop_match]`: normal `continue` and `break` continue to work
- `#[const_continue]` is only allowed in loops annotated with `#[loop_match]`
- the loop body needs to have this particular shape (a single assignment to the match scrutinee, with the body a labelled block containing just a match)
## future work
- perform const evaluation on the `break` value
- support more state/scrutinee types
## maybe future work
- allow `continue 'label value` syntax, which `#[const_continue]` could then use.
- allow the match to be on an arbitrary expression (e.g. `State::Initial`)
- attempt to also optimize `break`/`continue` expressions that are not marked with `#[const_continue]`
r? ``@traviscross``
|
|
Co-authored-by: Folkert de Vries <folkert@folkertdev.nl>
|
|
|
|
|
|
|
|
Ensure stack in two places that affect s390x
In our Fedora s390x test results, we found two tests that started hitting stack
overflows in the 1.87.0 update. It seems to be related in some part to our use
of PGO as well, probably inlining more into stack frames that were already
recursive. The main points of recursion that I identified were:
- `ui/parser/survive-peano-lesson-queue.rs` in `ThirBuildCx::mirror_exprs`
- `ui/associated-consts/issue-93775.rs` in `Parser::parse_ty`
A couple new `ensure_sufficient_stack` calls will solve these tests.
|
|
|
|
This solve a stack overflow found on Fedora s390x when building
`tests/ui/parser/survive-peano-lesson-queue.rs`. Note that the singular
`mirror_expr` method already has this stack check, but in this case the
plural method was the one recursing too deeply.
|
|
Overhaul `UsePath`
It currently uses `SmallVec<[Res; 3]>` which is really weird. Details in the individual commits.
r? `@petrochenkov`
|
|
`UsePath` contains a `SmallVec<[Res; 3]>`. This holds up to three `Res`
results, one per namespace (type, value, or macro). `lower_import_res`
takes a `PerNS<Option<Res<NodeId>>>` result and lowers it into the
`SmallVec`. This is pretty weird. The input `PerNS` makes it clear which
`Res` belongs to which namespace, but the `SmallVec` throws that
information away.
And code that operates on the `SmallVec` tends to use iteration (or even
just grabbing the first entry!) without knowing which namespace the
`Res` belongs to. Even weirder! Also, `SmallVec` is an overly flexible
type to use here, because it can contain any number of elements (even
though it's optimized for 3 in this case).
This commit changes `UsePath` so it also contains a
`PerNS<Option<Res<HirId>>>`. This type preserves more information and is
more self-documenting. The commit also changes a lot of the use sites to
access the result for a particular namespace. E.g. if you're looking up
a trait, it will be in the `Res` for the type namespace if it's present;
it's silly to look in the `Res` for the value namespace or macro
namespace. Overall I find the new code much easier to understand.
However, some use sites still iterate. These now use `present_items`
because that filters out the `None` results.
Also, `redundant_pub_crate.rs` gets a bigger change. A
`UseKind:ListStem` item gets no `Res` results, which means the old `all`
call in `is_not_macro_export` would succeed (because `all` succeeds on
an empty iterator) and the `ListStem` would be ignored. This is what we
want, but was more by luck than design. The new code detects `ListStem`
explicitly. The commit generalizes the name of that function
accordingly.
Finally, the commit also removes the `use_path` arena, because
`PerNS<Option<Res>>` impls `Copy` (unlike `SmallVec`) and it can be
allocated in the arena shared by all `Copy` types.
|
|
|
|
Hir item kind field order
A follow-up to rust-lang/rust#141675.
r? `@fee1-dead`
|
|
Specifically `TyAlias`, `Enum`, `Struct`, `Union`. So the fields match
the textual order in the source code.
The interesting part of the change is in
`compiler/rustc_hir/src/hir.rs`. The rest is extremely mechanical
refactoring.
|
|
|
|
Handle ed2021 precise capturing of unsafe binder
Missing pieces from last pr.
r? oli-obk
Fixes https://github.com/rust-lang/rust/issues/141655
|
|
Drop-build cleanups
Some cleanups I made while trying to speed up the program in rust-lang/rust#134404.
r? ```@matthewjasper```
|
|
|
