| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #138483 (Target modifiers fix for bool flags without value)
- #138818 (Don't produce debug information for compiler-introduced-vars when desugaring assignments.)
- #138898 (Mostly parser: Eliminate code that's been dead / semi-dead since the removal of type ascription syntax)
- #138930 (Add bootstrap step diff to CI job analysis)
- #138954 (Ensure `define_opaque` attrs are accounted for in HIR hash)
- #138959 (Revert "Make MatchPairTree::place non-optional")
- #138967 (Fix typo in error message)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Note that issue-111692.rs was incorrectly named: It's a regression test for
issue [#]112278, not for [#]111692. That's been addressed, too.
|
|
|
|
|
|
|
|
GuillaumeGomez:proc-macro_add_value_retrieval_methods, r=Amanieu"
This reverts commit 08dfbf49e30d917c89e49eb14cb3f1e8b8a1c9ef, reversing
changes made to 10bcdad7df0de3cfb95c7bdb7b16908e73cafc09.
|
|
GuillaumeGomez:proc-macro_add_value_retrieval_methods, r=Amanieu
Add `*_value` methods to proc_macro lib
This is the implementation of https://github.com/rust-lang/libs-team/issues/459.
It allows to get the actual value (unescaped) of the different string literals.
Part of https://github.com/rust-lang/rust/issues/136652.
r? libs-api
|
|
|
|
The original reason to exclude it was so it could run before submodules
were initialized. However, those have all been converted to subtrees
now, so the entire workspace is always ready to go.
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Add `#[define_opaques]` attribute and require it for all type-alias-impl-trait sites that register a hidden type
Instead of relying on the signature of items to decide whether they are constraining an opaque type, the opaque types that the item constrains must be explicitly listed.
A previous version of this PR used an actual attribute, but had to keep the resolved `DefId`s in a side table.
Now we just lower to fields in the AST that have no surface syntax, instead a builtin attribute macro fills in those fields where applicable.
Note that for convenience referencing opaque types in associated types from associated methods on the same impl will not require an attribute. If that causes problems `#[defines()]` can be used to overwrite the default of searching for opaques in the signature.
One wart of this design is that closures and static items do not have generics. So since I stored the opaques in the generics of functions, consts and methods, I would need to add a custom field to closures and statics to track this information. During a T-types discussion we decided to just not do this for now.
fixes #131298
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #136395 (Update to rand 0.9.0)
- #137279 (Make some invalid codegen attr errors structured/translatable)
- #137585 (Update documentation to consistently use 'm' in atomic synchronization example)
- #137926 (Add a test for `-znostart-stop-gc` usage with LLD)
- #138074 (Support `File::seek` for Hermit)
- #138238 (Fix dyn -> param suggestion in struct ICEs)
- #138270 (chore: Fix some comments)
- #138286 (triagebot.toml: Don't label `test/rustdoc-json` as A-rustdoc-search (…)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Update cargo
22 commits in 2622e844bc1e2e6123e54e94e4706f7b6195ce3d..ab1463d632528e39daf35f263e10c14cbe590ce8
2025-02-28 12:33:57 +0000 to 2025-03-08 01:45:05 +0000
- test: redact host target when comparing CARGO_ENV path (rust-lang/cargo#15279)
- feat: add completions for install --path (rust-lang/cargo#15266)
- fix(package): report lockfile / workspace manifest is dirty (rust-lang/cargo#15276)
- feat(tree): Add `--depth public` behind `-Zunstable-options` (rust-lang/cargo#15243)
- Don't use `$CARGO_BUILD_TARGET` in `cargo metadata` (rust-lang/cargo#15271)
- feat: show extra build description from bootstrap (rust-lang/cargo#15269)
- Upgrade to `rustc-stable-hash v0.1.2` (rust-lang/cargo#15268)
- fix: Respect --frozen everywhere --offline or --locked is accepted (rust-lang/cargo#15263)
- feat(tree): Color the output (rust-lang/cargo#15242)
- fix(vendor): dont remove non-cached source (rust-lang/cargo#15260)
- docs: lockfile is always included since 1.84 (rust-lang/cargo#15257)
- Remove `Cargo.toml` from `package.include` in example (rust-lang/cargo#15253)
- Small cleanup: remove unneeded result (rust-lang/cargo#15256)
- Fix typo in build-scripts.md (rust-lang/cargo#15254)
- chore(deps): update rust crate pulldown-cmark to 0.13.0 (rust-lang/cargo#15250)
- chore(deps): update compatible (rust-lang/cargo#15249)
- feat(cli): forward bash completions of third party subcommands (rust-lang/cargo#15247)
- feat: add completions for `--lockfile-path` (rust-lang/cargo#15238)
- fix: reset $CARGO if the running program is real `cargo[.exe]` (rust-lang/cargo#15208)
- Get all members as `available targets` even though default-members was specified. (rust-lang/cargo#15199)
- refactor: control byte display precision with std::fmt options (rust-lang/cargo#15246)
- fix(package): Ensure we can package directories ending with '.rs' (rust-lang/cargo#15240)
|
|
|
|
|
|
tidy: add triagebot checks
Validates triagebot.toml to have existing paths:
`[mentions."*"]` sections, i.e.
```toml
[mentions."compiler/rustc_const_eval/src/"]
```
or
```toml
[assign.owners]
"/.github/workflows" = ["infra-ci"]
```
or
```toml
trigger_files = [
"src/librustdoc/html/static/js/search.js",
"tests/rustdoc-js",
"tests/rustdoc-js-std",
]
```
Looked at #137876 and implemented check.
|
|
|
|
|
|
Retire the legacy `Makefile`-based `run-make` test infra
The final piece of [porting run-make tests to use Rust #121876](https://github.com/rust-lang/rust/issues/121876).
Closes #121876.
Closes #40713.
Closes #81791 (no longer using `wc`).
Closes #56475 (no longer a problem in current form of that test; we don't ignore the test on `aarch64-unknown-linux-gnu`).
### Summary
This PR removes the legacy `Makefile`-based `run-make` test infra which has served us well over the years. The legacy infra is no longer needed since we ported all of `Makefile`-based `run-make` tests to the new `rmake.rs` infra.
Additionally, this PR:
- Removes `tests/run-make/tools.mk` since no more `Makefile`-based tests remain.
- Updates `tests/run-make/README.md` and rustc-dev-guide docs to remove mention about `Makefile`-based `run-make` tests
- Update test suite requirements in rustc-dev-guide on Windows to no longer need MSYS2 (they should also now run successfully on native Windows MSVC).
- Update `triagebot.toml` to stop backlinking to #121876.
**Thanks to everyone who helped in this effort to modernize the `run-make` test infra and test suite!**
r? bootstrap
|
|
|
|
The rustdoc-json test syntax often requires very long lines, so the checks
for long lines aren't really useful.
|
|
|
|
|
|
|
|
|
|
Suggest replacing `.` with `::` in more error diagnostics.
First commit makes the existing "help: use the path separator to refer to an item" also work when the base is a type alias, not just a trait/module/struct.
The existing unconditional `DefKind::Mod | DefKind::Trait` match arm is changed to a conditional `DefKind::Mod | DefKind::Trait | DefKind::TyAlias` arm that only matches if the `path_sep` suggestion-adding closure succeeds, so as not to stop the later `DefKind::TyAlias`-specific suggestions if the path-sep suggestion does not apply. This shouldn't change behavior for `Mod` or `Trait` (due to the default arm's `return false` etc).
This commit also updates `tests/ui/resolve/issue-22692.rs` to reflect this, and also renames it to something more meaningful.
This commit also makes the `bad_struct_syntax_suggestion` closure take `err` as a parameter instead of capturing it, since otherwise caused borrowing errors due to the change to using `path_sep` in a pattern guard.
<details> <summary> Type alias diagnostic example </summary>
```rust
type S = String;
fn main() {
let _ = S.new;
}
```
```diff
error[E0423]: expected value, found type alias `S`
--> diag7.rs:4:13
|
4 | let _ = S.new;
| ^
|
- = note: can't use a type alias as a constructor
+ help: use the path separator to refer to an item
+ |
+4 | let _ = S::new;
+ | ~~
```
</details>
Second commit adds some cases for `enum`s, where if there is a field/method expression where the field/method has the name of a unit/tuple variant, we assume the user intended to create that variant[^1] and suggest replacing the `.` from the field/method suggestion with a `::` path separator. If no such variant is found (or if the error is not a field/method expression), we give the existing suggestion that suggests adding `::TupleVariant(/* fields */)` after the enum.
<details> <summary> Enum diagnostic example </summary>
```rust
enum Foo {
A(u32),
B,
C { x: u32 },
}
fn main() {
let _ = Foo.A(42); // changed
let _ = Foo.B; // changed
let _ = Foo.D(42); // no change
let _ = Foo.D; // no change
let _ = Foo(42); // no change
}
```
```diff
error[E0423]: expected value, found enum `Foo`
--> diag8.rs:8:13
|
8 | let _ = Foo.A(42); // changed
| ^^^
|
note: the enum is defined here
--> diag8.rs:1:1
|
1 | / enum Foo {
2 | | A(u32),
3 | | B,
4 | | C { x: u32 },
5 | | }
| |_^
-help: you might have meant to use the following enum variant
- |
-8 | let _ = Foo::B.A(42); // changed
- | ~~~~~~
-help: alternatively, the following enum variant is available
+help: use the path separator to refer to a variant
|
-8 | let _ = (Foo::A(/* fields */)).A(42); // changed
- | ~~~~~~~~~~~~~~~~~~~~~~
+8 | let _ = Foo::A(42); // changed
+ | ~~
error[E0423]: expected value, found enum `Foo`
--> diag8.rs:9:13
|
9 | let _ = Foo.B; // changed
| ^^^
|
note: the enum is defined here
--> diag8.rs:1:1
|
1 | / enum Foo {
2 | | A(u32),
3 | | B,
4 | | C { x: u32 },
5 | | }
| |_^
-help: you might have meant to use the following enum variant
- |
-9 | let _ = Foo::B.B; // changed
- | ~~~~~~
-help: alternatively, the following enum variant is available
+help: use the path separator to refer to a variant
|
-9 | let _ = (Foo::A(/* fields */)).B; // changed
- | ~~~~~~~~~~~~~~~~~~~~~~
+9 | let _ = Foo::B; // changed
+ | ~~
error[E0423]: expected value, found enum `Foo`
--> diag8.rs:10:13
|
10 | let _ = Foo.D(42); // no change
| ^^^
|
note: the enum is defined here
--> diag8.rs:1:1
|
1 | / enum Foo {
2 | | A(u32),
3 | | B,
4 | | C { x: u32 },
5 | | }
| |_^
help: you might have meant to use the following enum variant
|
10 | let _ = Foo::B.D(42); // no change
| ~~~~~~
help: alternatively, the following enum variant is available
|
10 | let _ = (Foo::A(/* fields */)).D(42); // no change
| ~~~~~~~~~~~~~~~~~~~~~~
error[E0423]: expected value, found enum `Foo`
--> diag8.rs:11:13
|
11 | let _ = Foo.D; // no change
| ^^^
|
note: the enum is defined here
--> diag8.rs:1:1
|
1 | / enum Foo {
2 | | A(u32),
3 | | B,
4 | | C { x: u32 },
5 | | }
| |_^
help: you might have meant to use the following enum variant
|
11 | let _ = Foo::B.D; // no change
| ~~~~~~
help: alternatively, the following enum variant is available
|
11 | let _ = (Foo::A(/* fields */)).D; // no change
| ~~~~~~~~~~~~~~~~~~~~~~
error[E0423]: expected function, tuple struct or tuple variant, found enum `Foo`
--> diag8.rs:12:13
|
12 | let _ = Foo(42); // no change
| ^^^ help: try to construct one of the enum's variants: `Foo::A`
|
= help: you might have meant to construct the enum's non-tuple variant
note: the enum is defined here
--> diag8.rs:1:1
|
1 | / enum Foo {
2 | | A(u32),
3 | | B,
4 | | C { x: u32 },
5 | | }
| |_^
error: aborting due to 5 previous errors
```
</details>
[^1]: or if it's a field expression and a tuple variant, that they meant to refer the variant constructor.
|
|
When `Foo.field` or `Foo.method()` exprs are encountered, suggest `Foo::field` or `Foo::method()` when Foo is a type alias, not just
a struct, trait, or module.
Also rename test for this suggestion from issue-22692.rs to something more meaningful.
|
|
I believe this is trying to say there is something that is in the file,
but shouldn't be.
|
|
I had forgotten that error_index_generator is using mdbook. This moves
it to be part of the rustbook workspace so that it can share the
dependency with rustbook.
|
|
Also add Zlib to Cargo's license exception
|
|
|
|
deps list
|
|
r=Mark-Simulacrum
Removed dependency on the field-offset crate, alternate approach
This is an alternate approach to reach the same goals as #136003. As it touches the core of the query system, this too probably should be evaluated for performance.
r? ``@Mark-Simulacrum``
|
|
|
|
|
|
Rename and Move some UI tests to more suitable subdirs
## Affected Tests
- tests/ui/issues/issue-48838.rs -> tests/ui/enum/closure-in-enum-issue-48838.rs https://github.com/rust-lang/rust/issues/48838
- tests/ui/issues/issue-40350.rs -> tests/ui/enum/enum-inside-enum-issue-40350.rs https://github.com/rust-lang/rust/issues/40350
- tests/ui/issues/issue-41272.rs -> tests/ui/expr/if/if-let-no-match-guards-issue-41272.rs https://github.com/rust-lang/rust/issues/41272
- tests/ui/issues/issue-40408.rs -> tests/ui/lexer/floating-point-0e10-issue-40408.rs https://github.com/rust-lang/rust/issues/40408
- tests/ui/issues/issue-40136.rs -> tests/ui/macros/const-expr-invocations-issue-40136.rs https://github.com/rust-lang/rust/issues/40136
- tests/ui/issues/issue-40845.rs -> tests/ui/macros/macros-in-trait-positions-issue-40845.rs https://github.com/rust-lang/rust/issues/40845
- tests/ui/issues/issue-41213.rs -> tests/ui/match/enum-and-break-in-match-issue-41213.rs https://github.com/rust-lang/rust/issues/41213
- tests/ui/issues/issue-40782.rs -> tests/ui/suggestions/for-loop-missing-in.rs https://github.com/rust-lang/rust/issues/40782
- tests/ui/issues/issue-40827.rs -> tests/ui/trait-bounds/deep-level-Send-bound-check-issue-40827.rs https://github.com/rust-lang/rust/issues/40827
- tests/ui/issues/issue-40610.rs -> tests/ui/typeck/coercion-check-for-addition-issue-40610.rs https://github.com/rust-lang/rust/issues/40610
- tests/ui/issues/issue-40883.rs -> tests/ui/codegen/StackColoring-not-blowup-stack-issue-40883.rs https://github.com/rust-lang/rust/issues/40883
- tests/ui/issues/issue-40861.rs -> tests/ui/typeck/coercion-check-for-indexing-expression-issue-40861.rs https://github.com/rust-lang/rust/issues/40861
- tests/ui/issues/issue-41139.rs -> tests/ui/typeck/unsized-rvalue-issue-41139.rs https://github.com/rust-lang/rust/issues/41139
- tests/ui/issues/issue-40749.rs -> tests/ui/wf/range-expr-root-of-constant-issue-40749.rs https://github.com/rust-lang/rust/issues/40749
- tests/ui/issues/issue-40235.rs -> tests/ui/while/while-let-scope-issue-40235.rs https://github.com/rust-lang/rust/issues/40235
|
|
tests: Port `split-debuginfo` to rmake.rs
Part of #121876.
This PR supersedes #128754 and is co-authored with `@Oneirical.`
## Known limitations
- In general, like the `Makefile` version, this test in its present form is also somewhat funny because for the most part it merely checks for existence/absence of output artifacts but makes no attempt to actually check if the debuginfo is at all usable.
## Changes
This PR ports `tests/run-make/split-debuginfo` to rmake.rs. This is an **initial** port, and certainly could be cleaned up and/or enhanced.
The original Makefile version had several functional problems. I fixed some of them, but also left some existing issues as-is.
1. The linux/non-linux final branch had a conditional interpolation of `UNSTABLE_OPTIONS := -Zunstable-options`. However, one of the use sites was `-C $(UNSTABLE_OPTIONS) split-debuginfo`. This indicates to me that this run-make test is not run in CI under a non-linux + non-windows + non-darwin environment, because that would've failed as this would expand to `-C -Zunstable-options split-debuginfo`. I fixed this in the rmake.rs version, but I'm not sure if this distinction is worth keeping at all if it's not tested in CI.
2. There are several comments that were discovered to be wrong. I tried to fix them in the rmake.rs version as well.
3. The check for path remapping / lack of path remapping through
```make
objdump -Wi $(TMPDIR)/foo | grep DW_AT_GNU_dwo_name | (! grep $(TMPDIR)) || exit 1
```
is incorrect, because that looks at the single line of that contains `DW_AT_GNU_dwo_name`. This is unfortunately wrong because empirical evidence shows that with `objdump`[^objdump], the check actually needs to look at the attribute value of `DW_AT_comp_dir` on the previous line not `DW_AT_GNU_dwo_name`[^gnu-ext]. Example output of `objdump`:
```text
<10> DW_AT_comp_dir : (indirect string, offset: 0xafb48): /home/joe/repos/rust
<14> DW_AT_GNU_dwo_name: (indirect string, offset: 0x5d1b0): foo.foo.fc848df41df7a00d-cgu.0.rcgu.dwo
```
In the rmake.rs version I used a 2-line sliding window to check for `DW_AT_comp_dir` and `DW_AT_GNU_dwo_name`, but to look at `DW_AT_comp_dir` specifically.
4. I included a bunch of FIXMEs and ENHANCEMENTs I noticed regarding the test because I didn't want to fix them in this initial port[^enhancement].
5. The Makefile version didn't test *anything* on Windows (both windows-msvc and windows-gnu). I added some *very* basic and *very* sparse checks for windows-msvc, but I am not willing to spend the effort to expand test coverage to windows-gnu in this initial port.
6. This run-make test is way too big. But I didn't want to expend the effort of breaking this up in this initial port.
[^objdump]: the output format differs between `objdump` and `llvm-objdump`, but the same is true for `llvm-objdump` that this is looking at the wrong line.
[^gnu-ext]: AFAICT that is a GNU DWARF attribute extension, since it isn't mentioned in DWARFv5 spec
[^enhancement]: For instance, the previous path remapping check could in theory be precisely inspected by inspecting `.debug_info` section to look for attribute value of `DW_AT_comp_dir`. But that involves resolving the value of the indirect string, which means you have to: (1) look for offset into string offset table and (2) use *that* offset to find the string itself in the string table. The split part of "split-debuginfo" makes this murky for me, so I wasn't able to replace `llvm-objdump` textual output substring matches with more precise `object` + `gimli` inspections.
## Review advice
- I'm sorry for how long the rmake.rs test ended up, but a lot of it is comments and just vertical space due to formatting. If there's any ways to make this test less long / convoluted, advice would be appreciated.
- This PR *intentionally* introduces several intermediate commits for the `Makefile`, mostly to illustrate the problems I discovered when looking at the original `Makefile` version. This is intended to highlight the existing problems in the `Makefile` version for the reviewer[^squash].
- There are several intentional non-functional commits:
1. Reindent the `Makefile` to make the platform conditional gating more obvious.
2. Collapse nested if-else branches into an else if construct, which is not supported by GNU Make 3.80.
3. Remove all redundant `-C debuginfo=2` when `-g` is already specified.
- This PR is best reviewed commit-by-commit.
[^squash]: I intend to squash these intermediate commits away after the reviewer concludes that the current form of the rmake.rs test is acceptable for merge. Before then, I'll keep them to help with review.
---
try-job: x86_64-msvc
try-job: i686-msvc
try-job: i686-mingw
try-job: x86_64-mingw-1
try-job: x86_64-apple-1
try-job: aarch64-apple
try-job: test-various
|
|
|
|
Extract `core::ffi` primitives to a separate (internal) module
### Introduce library/core/src/ffi/primitives.rs
The regex preprocessing for PR #133944 would be more robust if the relevant types from core/src/ffi/mod.rs were first moved to library/core/src/ffi/primitives.rs, then there isn't a need to deal with traits / c_str / va_list / whatever might wind up in that module in the future
r? `@tgross35`
|
|
Add new tool for dumping feature status based on tidy
sequel to https://github.com/rust-lang/rust/pull/133514
meaning ...
supercedes https://github.com/rust-lang/rust/pull/133351
part of https://github.com/rust-lang/rust/issues/129485
r? `@jieyouxu`
cc `@estebank`
|
|
|
|
Ignore NLL boring locals in polonius diagnostics
Another easy one ``@jackh726`` (the diff is inflated by blessed test expectations don't worry :)
NLLs don't compute liveness for boring locals, and therefore cannot find them in causes explaining borrows. In polonius, we don't have this liveness optimization (we may be able to do something partially similar in the future, e.g. for function parameters and the like), so we do encounter these in diagnostics even though we don't want to. This PR:
- restructures the polonius context into per-phase data, in spirit as you requested in an earlier review
- stores the locals NLLs would consider boring into the errors/diagnostics data
- ignores these if a boring local is found when trying to explain borrows
This PR fixes around 80 cases of diagnostics differences between `-Zpolonius=next` and NLLs. I've also added explicit revisions to a few polonius tests (both for the in-tree implementation as well as the datalog implementation -- even if we'll eventually remove them). I didn't do this for all the "dead" expectations that were removed from #136112 for that same reason, it's fine. I'll soon/eventually add explicit revisions where they're needed: there's only a handful of tests left to fix.
r? ``@jackh726``
|
|
Co-authored-by: Oneirical <manchot@videotron.ca>
|
|
also add explicit revisions for -Zpolonius=next
|
|
- Use `object` based test logic instead of processing `nm`
human-readable textual output.
- Try to expand test coverage to not be limited to only linux + x86_64.
Co-authored-by: binarycat <binarycat@envs.net>
|
|
[rustdoc] Add sans-serif font setting
Fixes https://github.com/rust-lang/rust/issues/52449.
This PR adds a new setting introducing the possibility to switch to a sans-serif font (`Fira Sans`) for the text.
Can be tested [here](https://rustdoc.crud.net/imperio/sans-serif/std/index.html).
cc ```@rust-lang/rustdoc-frontend```
r? ```@notriddle```
|
