| Age | Commit message (Collapse) | Author | Lines |
|
Rollup of 7 pull requests
Successful merges:
- #104239 (Better debug logs for borrowck constraint graph)
- #108202 (Make sure `test_type_match` doesn't ICE with late-bound types)
- #108295 (Use DefKind to give more item kind information during BindingObligation note )
- #108306 (compiletest: up deps)
- #108313 (Fix compiletest possible crash in option only-modified)
- #108322 (Clean ConstProp)
- #108323 (hir-analysis: make one diagnostic translatable)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Revert #107834
This reverts commit [41c6c5d4996728b5a635319ef9b077a3d0ccc480](https://github.com/rust-lang/rust/pull/107834). Trying to check if this fixes building `rustc` for perf bot.
|
|
Fix compiletest possible crash in option only-modified
`fixed` files maybe removed, `unwrap` will crash in this scenario.
|
|
|
|
|
|
|
|
This reverts commit 6990ab9ad2cde9b67073ffac29ffecc2be8e722f.
|
|
|
|
deletes code
|
|
|
|
|
|
|
|
symlink for legacy rustfmt path"
This reverts commit 41c6c5d4996728b5a635319ef9b077a3d0ccc480.
|
|
|
|
Use `ThinVec` more in the AST
r? `@ghost`
|
|
Miri: basic dyn* support
As usual I am very unsure about the dynamic dispatch stuff, but it passes even the `Pin<&mut dyn* Trait>` test so that is something.
TBH I think it was a mistake to make `dyn Trait` and `dyn* Trait` part of the same `TyKind` variant. Almost everywhere in Miri this lead to the wrong default behavior, resulting in strange ICEs instead of nice "unimplemented" messages. The two types describe pretty different runtime data layout after all.
Strangely I did not need to do the equivalent of [this diff](https://github.com/rust-lang/rust/pull/106532#discussion_r1087095963) in Miri. Maybe that is because the unsizing logic matches on `ty::Dynamic(.., ty::Dyn)` already? In `unsized_info` I don't think the `target_dyn_kind` can be `DynStar`, since then it wouldn't be unsized!
r? `@oli-obk` Cc `@eholk` (dyn-star) https://github.com/rust-lang/rust/issues/102425
|
|
|
|
parallel_compiler mode.
|
|
|
|
|
|
This commit changes the sequence parsers to produce `ThinVec`, which
triggers numerous conversions.
|
|
Because 0.2.10 added supports for `ThinVec::splice`, and 0.2.12 is the
latest release.
|
|
Rollup of 6 pull requests
Successful merges:
- #108241 (Fix handling of reexported macro in doc hidden items)
- #108254 (Refine error span for trait error into borrowed expression)
- #108255 (Remove old FIXMEs referring to #19596)
- #108257 (Remove old FIXME that no longer applies)
- #108276 (small `opaque_type_origin` cleanup)
- #108279 (Use named arguments for `{,u}int_impls` macro)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
r=notriddle
Fix handling of reexported macro in doc hidden items
Fixes https://github.com/rust-lang/rust/issues/108231.
Fixes #59368.
r? `@notriddle`
|
|
|
|
:arrow_up: rust-analyzer
r? `@ghost`
|
|
|
|
|
|
|
|
|
|
Improve building compiler artifacts output
Fixes #108051
``@Manishearth,`` ``@jyn514`` mentioned you might be interested in these changes to the outputs.
|
|
|
|
|
|
This allows loading some essential functions (e.g. read/write file) at load time instead of lazily.
|
|
|
|
|
|
Including unstable lints in the lint group produces unintuitive behavior
on stable (see #106289). Meanwhile, if we only included unstable lints
on nightly and not on stable, we could end up with confusing bugs that
were hard to compare across versions of Rust that lacked code changes.
I think that only including stable lints in `rustdoc::all`, no matter
the release channel, is the most intuitive option. Users can then
control unstable lints individually, which is reasonable since they have
to enable the feature gates individually anyway.
|
|
Make codegen choose whether to emit overflow checks
ConstProp and DataflowConstProp currently have a specific code path not to propagate constants when they overflow. This is meant to have the correct behaviour when inlining from a crate with overflow checks (like `core`) into a crate compiled without.
This PR shifts the behaviour change to the `Assert(Overflow*)` MIR terminators: if the crate is compiled without overflow checks, just skip emitting the assertions. This is already what happens with `OverflowNeg`.
This allows ConstProp and DataflowConstProp to transform `CheckedBinaryOp(Add, u8::MAX, 1)` into `const (0, true)`, and let codegen ignore the `true`.
The interpreter is modified to conform to this behaviour.
Fixes #35310
|
|
|
|
Download rustfmt regardless of rustc being set in config.toml
Fixes #81155
cc : https://github.com/rust-lang/rust/issues/108210 for exact error details
|
|
Change src/etc/vscode_settings.json to always treat ./library as the sysroot source
See
https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/False.20error.20report.20for.20.60rust-analyzer.28private-field.29.60 for further discussion; previously this had various bugs.
I tested go-to-definition on:
- `use std::io::Write` in `src/bootstrap/setup.rs`
- `use std::cell::RefCell` in `src/librustdoc/core.rs`
- `use rustc_span::symbol::sym` in `src/librustdoc/core.rs`
- `use std::fmt` in `compiler/rustc_span/src/symbol.rs`
- `Global` in `library/alloc/src/alloc/tests.rs`
The following things still don't work:
- `Global.deallocate` in alloc/tests.rs. This function is under `cfg(not(test))`, so it can't be enabled without disabling RA in `tests.rs` altogether. I think this might be fixable by moving `library/alloc/src/alloc/tests.rs` to `library/alloc/tests/alloc/lib.rs`, so it's in a different crate, but I'd like to avoid blocking this improvement on that change.
cc `@thomcc` `@BoxyUwU` `@spastorino` - you've had issues with RA in the past, does this fix them? Are there any other use cases I should test? You can try these changes out by running `cp src/etc/vscode_settings.json .vscode/settings.json`, or running `x setup` and picking a random profile (it won't overwrite config.toml if it already exists). See https://github.com/rust-lang/rust/pull/108135 for plans to make updating the config easier.
r? `@Veykril`
|
|
GuillaumeGomez:correctly-handle-links-starting-with-whitespace, r=petrochenkov
Correctly handle links starting with whitespace
Part of https://github.com/rust-lang/rust/issues/107995.
I just got this issue, wrote a fix and then saw the issue. So here's the PR. ^^'
r? `@petrochenkov`
|
|
GuillaumeGomez:fix-json-reexports-of-different-items-with-same-name, r=aDotInTheVoid
Fix json reexports of different items with same name
Fixes #107677.
I renamed `from_item_id*` functions into `id_from_item` instead because it makes more sense now. I also simplified the logic around it a bit so that the `ids` function will now directly pass `&clean::Item` to `id_from_item` and the ID will be consistently generated (it caused an issue when I updated the ID for imports).
So now, the big change of this PR: I changed how imports' ID is generated: it now includes the target item's ID at the end of the ID. It's to prevent two reexported items with the same name (but different types).
r? `@aDotInTheVoid`
|
|
|
|
r=GuillaumeGomez
rustdoc: hide `reference` methods in search index
They're hidden in the HTML, so it makes no sense in the search engine for `reference::next` or `reference::shrink` to be shown.
https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/What.20is.20.60reference.3A.3Ashrink.60.3F
|
|
rustdoc: simplify DOM for `.item-table`
This switches from using `<div>` to the more semantic `<ul>`, and using class names that rhyme with the classes the search results table uses.
|
|
|
|
|
|
|
|
Add tests for moving data across await point
This patch adds a few tests to assert the current behavior when passing data across an await point. This will help to test out an upcoming fix for the issue of arguments in async functions growing in size because of the generator upvar that is generated when we desugar the async function.
See https://github.com/rust-lang/rust/issues/62958
Also relates to https://github.com/rust-lang/rust/pull/107500
FYI `@oli-obk` `@pnkfelix`
|