| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Remove `ItemKind::descr` method
Follow-up of rust-lang/rust#143234.
After this PR is merged, it will remain two `descr` methods:
* `hir::GenericArg::descr`
* `hir::AssocItemConstraintKind::descr`
For both these enums, I don't think there is the right equivalent in `hir::DefKind` so unless I missed something, we can't remove these two methods because we can't convert these enums into `hir::DefKind`.
r? `@oli-obk`
|
|
mir: Mark `Statement` and `BasicBlockData` as `#[non_exhaustive]`
Ensure they are always created using constructors.
r? oli-obk
|
|
r=oli-obk
Port `#[rustc_object_lifetime_default]` to the new attribute parsing …
Ports rustc_object_lifetime_default to the new attribute parsing infrastructure for https://github.com/rust-lang/rust/issues/131229#issuecomment-2971353197
r? `@oli-obk`
cc `@jdonszelmann`
|
|
Improve testing and error messages for malformed attributes
This PR has been split into 5 commits for reviewability, I recommend reviewing them one-by-one.
This first commit introduces more tests, the other 4 commits fix 4 bugs discovered by the test.
r? `@oli-obk`
cc `@jdonszelmann`
Fixes https://github.com/rust-lang/rust/issues/143136
|
|
Start moving wf checking away from HIR
I'm trying to only access the HIR in the error path. My hope is that once we move significant portions of wfcheck off HIR that incremental will be able to cache wfcheck queries significantly better.
I think I am reaching a blocker because we normally need to provide good spans to `ObligationCause`, so that the trait solver can report good errors. In some cases I have been able to use bad spans and improve them depending on the `ObligationCauseCode` (by loading HIR in the case where we actually want to error). To scale that further we'll likely need to remove spans from the `ObligationCause` entirely (leaving it to some variants of `ObligationCauseCode` to have a span when they can't recompute the information later). Unsure this is the right approach, but we've already been using it. I will create an MCP about it, but that should not affect this PR, which is fairly limited in where it does those kind of tricks.
Especially https://github.com/rust-lang/rust/commit/b862d8828e375ab8c128a9d9e93bf98b77cb5928 is interesting here, because I think it improves spans in all cases
|
|
`rustc_layout_scalar_valid_range_start` and `rustc_layout_scalar_valid_range_end`
|
|
infrastructure
|
|
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
|
|
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
|
|
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
|
|
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
|
|
fixes issue 143203
|
|
|
|
|
|
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
Split exported_symbols for generic and non-generic symbols
This reduces metadata decoder overhead during the monomorphization collector.
|
|
|
|
|
|
|
|
|
|
Port `#[rustc_layout_scalar_valid_range_start/end]` to the new attrib…
Ports `rustc_layout_scalar_valid_range_start` and `rustc_layout_scalar_valid_range_end` to the new attribute parsing infrastructure for https://github.com/rust-lang/rust/issues/131229#issuecomment-2971353197
r? `@jdonszelmann`
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#143125 (Disable f16 on Aarch64 without neon for llvm < 20.1.1)
- rust-lang/rust#143156 (inherit `#[align]` from trait method prototypes)
- rust-lang/rust#143178 (rustdoc default faviocon)
- rust-lang/rust#143234 (Replace `ItemCtxt::report_placeholder_type_error` match with a call to `TyCtxt::def_descr`)
- rust-lang/rust#143245 (mbe: Add tests and restructure metavariable expressions)
- rust-lang/rust#143257 (Upgrade dependencies in run-make-support)
- rust-lang/rust#143263 (linkify CodeSuggestion in doc comments)
- rust-lang/rust#143264 (fix: Emit suggestion filename if primary diagnostic span is dummy)
Failed merges:
- rust-lang/rust#143251 (bootstrap: add build.tidy-extra-checks option)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
fix: Emit suggestion filename if primary diagnostic span is dummy
While working on using `annotate-snippets` as `rustc`'s emitter, I came across [`tests/ui/resolve/resolve-conflict-extern-crate-vs-extern-crate.stderr`](https://github.com/rust-lang/rust/blob/b03b3a7ec92682be2917540b679478d41c95a30c/tests/ui/resolve/resolve-conflict-extern-crate-vs-extern-crate.stderr), which lacked a filename for both the annotation and the suggestion, which seemed like a bug to me. After some investigation, I found that this is happening because the primary span is a dummy, so its filename doesn't get output, and its filename matches the one for the suggestion, so the suggestion's filename doesn't get output. To fix this issue, I made it so that the filename for a suggestion will get output if the primary span is a dummy.
|
|
r=compiler-errors
linkify CodeSuggestion in doc comments
|
|
r=petrochenkov
mbe: Add tests and restructure metavariable expressions
Add tests that show better diagnostics, and factor `concat` handling to a separate function. Each commit message has further details.
This performs the nonfunctional perparation for further changes such as https://github.com/rust-lang/rust/pull/142950 and https://github.com/rust-lang/rust/pull/142975 .
|
|
Replace `ItemCtxt::report_placeholder_type_error` match with a call to `TyCtxt::def_descr`
Fixes rust-lang/rust#143128.
We could likely use `tcx.def_descr` in more places (and therefore remove more `descr` methods). If it's something that we want to do, I can send a follow-up.
r? `@oli-obk`
|
|
r=workingjubilee
inherit `#[align]` from trait method prototypes
````@workingjubilee```` this seems straightforward enough. Now that we're planning to make `-Cmin-function-alignment` a target modifier, I don't think there are any cross-crate complications here?
````@Jules-Bertholet```` is this the behavior you had in mind? In particular the inheritance of the attribute of a default impl is maybe a bit unintuitive at first? (but I think it's ok if that behavior is explicitly documented).
r? ghost
|
|
Disable f16 on Aarch64 without neon for llvm < 20.1.1
This check was added unconditionally in c51b229140 ("Disable f16 on Aarch64 without `neon`") and reverted in 4a8d35709e ("Revert "Disable `f16` on Aarch64 without `neon`"") since it did not fail in Rust's build. However, it is still possible to hit this crash if using LLVM 19 built with assertions, so disable the type conditionally based on version here.
Note that for these builds, a similar patch is needed in the build script for `compiler-builtins` since it does not yet use `cfg(target_has_reliable_f16)` (hopefully to be resolved in the near future).
Report: https://github.com/rust-lang/rust/pull/139276#issuecomment-3014781652
Original LLVM issue: https://github.com/llvm/llvm-project/issues/129394
|
|
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.
|
|
|
|
|
|
|
|
Ensure they are always created using constructors.
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#143019 (Ensure -V --verbose processes both codegen_backend and codegen-backend)
- rust-lang/rust#143140 (give Pointer::into_parts a more scary name and offer a safer alternative)
- rust-lang/rust#143175 (Make combining LLD with external LLVM config a hard error)
- rust-lang/rust#143180 (Use `tracing-forest` instead of `tracing-tree` for bootstrap tracing)
- rust-lang/rust#143223 (Improve macro stats printing)
- rust-lang/rust#143228 (Handle build scripts better in `-Zmacro-stats` output.)
- rust-lang/rust#143229 ([COMPILETEST-UNTANGLE 1/N] Move some some early config checks to the lib and move the compiletest binary)
- rust-lang/rust#143246 (Subtree update of `rust-analyzer`)
- rust-lang/rust#143248 (Update books)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
Move this structure directly above the `parse_<expr>` functions that
return it to keep top-down flow.
This is a non-functional change.
|
|
Move the `concat` implementation to a separate function so it is easier
to work on. Other metavariable expressions are already split this way.
This is a non-functional change.
|
|
More diagnostic structs related to metavariable expressions will be
introduced. Introduce the abbreviation "mve" which is reasonably
unambiguous (`rg Mve` and `rg '(\b|_|-)mve(\b|_|-)'` return no results
outside of a Thumb target feature) and use it for these diagnostic
types. A new module is also created.
|
|
Handle build scripts better in `-Zmacro-stats` output.
Currently all build scripts are listed as `build_script_build` in the stats header. This commit uses `CARGO_PKG_NAME` to improve that.
I tried it on Bevy, it works well, giving output like this on the build script:
```
MACRO EXPANSION STATS: serde build script
```
and this on the crate itself:
```
MACRO EXPANSION STATS: serde
```
r? `@Kobzol`
|
|
r=petrochenkov
Improve macro stats printing
Fix a small formatting issue that has been annoying me.
r? ``@petrochenkov``
|
|
give Pointer::into_parts a more scary name and offer a safer alternative
`into_parts` is a bit too innocent of a name for a somewhat subtle operation.
r? `@oli-obk`
|
|
Ensure -V --verbose processes both codegen_backend and codegen-backend
|
|
r=GuillaumeGomez
GCC backend subtree update
cc `@antoyo`
r? ghost
|
|
|
|
`TyCtxt::def_descr`
|
|
|
