| Age | Commit message (Collapse) | Author | Lines |
|---|
|
rustdoc book
|
|
other items
|
|
Subtree update of `rust-analyzer`
r? `@ghost`
|
|
|
|
minor: Sync from downstream
|
|
|
|
|
|
|
|
Rollup of 12 pull requests
Successful merges:
- #129409 (Expand std::os::unix::fs::chown() doc with a warning)
- #133320 (Add release notes for Rust 1.83.0)
- #133368 (Delay a bug when encountering an impl with unconstrained generics in `codegen_select`)
- #133428 (Actually use placeholder regions for trait method late bound regions in `collect_return_position_impl_trait_in_trait_tys`)
- #133512 (Add `as_array` and `as_mut_array` conversion methods to slices.)
- #133519 (Check `xform_ret_ty` for WF in the new solver to improve method winnowing)
- #133520 (Structurally resolve before applying projection in borrowck)
- #133534 (extend group-forbid-always-trumps-cli test)
- #133537 ([rustdoc] Fix new clippy lints)
- #133543 ([AIX] create shim for lgammaf_r)
- #133547 (rustc_span: Replace a `HashMap<_, ()>` with `HashSet`)
- #133550 (print generated doc paths)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
print generated doc paths
Resolves #133002
|
|
rustc_span: Replace a `HashMap<_, ()>` with `HashSet`
Now that `HashSet::entry()` exists, we don't need to fake it with a map.
|
|
[AIX] create shim for lgammaf_r
On AIX, we don't have 32bit floating point for re-entrant `lgammaf_r` but we do have the 64bit floating point re-entrant `lgamma_r` so we can use the 64bit version instead and truncate back to a 32bit float.
This solves the linker missing symbol for `.lgammaf_r` when testing and using these parts of the `std`.
|
|
[rustdoc] Fix new clippy lints
Lots of small things that clippy lints about.
r? `@fmease`
|
|
extend group-forbid-always-trumps-cli test
Test it not just for a lint group, but also an individual lint, or when mixing the lint and the group. And test both orders in which the flags could be passed.
|
|
r=lcnr
Structurally resolve before applying projection in borrowck
As far as I can tell, all other `.normalize` calls in borrowck are noops and can remain that way. This is the only one that actually requires structurally resolving the type.
r? lcnr
|
|
Check `xform_ret_ty` for WF in the new solver to improve method winnowing
This is a bit interesting. Method probing in the old solver is stronger than the new solver because eagerly normalizing types causes us to check their corresponding trait goals. This is important because we don't end up checking all of the where clauses of a method when method probing; just the where clauses of the impl. i.e., for:
```
impl Foo
where
WC1,
{
fn method()
where
WC2,
{}
}
```
We only check WC1 and not WC2. This is because at this point in probing the method is instantiated w/ infer vars, and checking the where clauses in WC2 will lead to cycles if we were to check them (at least that's my understanding; I could investigate changing that in general, incl. in the old solver, but I don't have much confidence that it won't lead to really bad overflows.)
This PR chooses to emulate the old solver by just checking that the return type is WF. This is theoretically stronger, but I'm not too worried about it. I think we alternatively have several approaches we can take here, though this one seems the simplest. Thoughts?
r? lcnr
|
|
Add `as_array` and `as_mut_array` conversion methods to slices.
Tracking issue: #133508
This PR unstably implements the `as_array` and `as_mut_array` converters to `[T]`, `*const [T]`, and `*mut [T]`.
|
|
Actually use placeholder regions for trait method late bound regions in `collect_return_position_impl_trait_in_trait_tys`
So in https://github.com/rust-lang/rust/pull/113182, I introduced a "diagnostics improvement" in the form of 473c88dfb69f95b2e8c5f71ba7f6b7b448d22dc2, which changes which signature we end up instantiating with placeholder regions and which signature we end up instantiating with fresh region vars so that we have placeholders corresponding to the names of the late-bound regions coming from the *impl*.
However, this is not sound, since now we're essentially no longer proving that *all* instantiations of the trait method are compatible with an instantiation of the impl method, but vice versa (which is weaker). Let's look at the example `tests/ui/impl-trait/in-trait/do-not-imply-from-trait-impl.rs`:
```rust
trait MkStatic {
fn mk_static(self) -> &'static str;
}
impl MkStatic for &'static str {
fn mk_static(self) -> &'static str { self }
}
trait Foo {
fn foo<'a: 'static, 'late>(&'late self) -> impl MkStatic;
}
impl Foo for str {
fn foo<'a: 'static>(&'a self) -> impl MkStatic + 'static {
self
}
}
fn call_foo<T: Foo + ?Sized>(t: &T) -> &'static str {
t.foo().mk_static()
}
fn main() {
let s = call_foo(String::from("hello, world").as_str());
println!("> {s}");
}
```
To collect RPITITs, we were previously instantiating the trait signature with infer vars (`fn(&'?0 str) -> ?1t` where `?1t` is the variable we use to infer the RPITIT) and the impl signature with placeholders (there are no late-bound regions in that signature, so we just have `fn(&'a str) -> Opaque`).
Equating the signatures works, since all we do is unify `?1t` with `Opaque` and `'?0` with `'a`. However, conceptually it *shouldn't* hold, since this definition is not valid for *all* instantiations of the trait method but just the one where `'0` (i.e. `'late`) is equal to `'a` :(
## So what
This PR effectively reverts 473c88dfb69f95b2e8c5f71ba7f6b7b448d22dc2 to fix the unsoundness.
Fixes #133427
Also fixes #133425, which is actually coincidentally another instance of this bug (but not one that is weaponized into UB, just one that causes an ICE in refinement checking).
|
|
compiler-errors:codegen-select-unconstrained-params, r=lcnr
Delay a bug when encountering an impl with unconstrained generics in `codegen_select`
Despite its name, `codegen_select` is what powers `Instance::try_resolve`, which is used in pre-codegen contexts to try to resolve a method where possible. One place that it's used is in the "recursion MIR lint" that detects recursive MIR bodies.
If we encounter an impl in `codegen_select` that contains unconstrained generic parameters, we expect that impl to caused an error to be reported; however, there's no temporal guarantee that this error is reported *before* we call `codegen_select`. This is what a delayed bug is *for*, and this PR makes us use a delayed bug rather than asserting something about errors already having been emitted.
Fixes #126646
|
|
Add release notes for Rust 1.83.0
Issues: https://github.com/rust-lang/rust/issues?q=is%3Aissue%20state%3Aopen%20label%3Arelnotes-tracking-issue%20milestone%3A1.83.0
r? `@Mark-Simulacrum`
cc `@rust-lang/release`
|
|
Expand std::os::unix::fs::chown() doc with a warning
Include warning about losing setuid/gid when chowning, per POSIX.
It is about the underlying system call but it is rather useful to mention it in the help in case someone accidentally forgets (don't look at me :)).
|
|
|
|
Rollup of 5 pull requests
Successful merges:
- #132410 (Some more refactorings towards removing driver queries)
- #133418 (coverage: Store coverage source regions as `Span` until codegen)
- #133498 (Add missing code examples on `LocalKey`)
- #133518 (Structurally resolve before checking `!` in HIR typeck)
- #133521 (Structurally resolve before matching on type of projection)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Structurally resolve before matching on type of projection
Another missing structural resolve in closure upvar analysis. I think it's better to place the normalization here rather than trying to guarantee that all types returned by the expr use visitor are structurally normalized, which I don't think we do now. Thoughts?
r? lcnr
|
|
Structurally resolve before checking `!` in HIR typeck
Some more missing structural resolves in HIR typeck :>
r? lcnr
|
|
Add missing code examples on `LocalKey`
r? ``@Amanieu``
|
|
coverage: Store coverage source regions as `Span` until codegen
Historically, coverage spans were converted into line/column coordinates during the MIR instrumentation pass.
This PR moves that conversion step into codegen, so that coverage spans spend most of their time stored as `Span` instead.
In addition to being conceptually nicer, this also reduces the size of coverage mappings in MIR, because `Span` is smaller than 4x u32.
---
There should be no changes to coverage output.
|
|
Some more refactorings towards removing driver queries
Follow up to https://github.com/rust-lang/rust/pull/127184
## Custom driver breaking change
The `after_analysis` callback is changed to accept `TyCtxt` instead of `Queries`. The only safe query in `Queries` to call at this point is `global_ctxt()` which allows you to enter the `TyCtxt` either way. To fix your custom driver, replace the `queries: &'tcx Queries<'tcx>` argument with `tcx: TyCtxt<'tcx>` and remove your `queries.global_ctxt().unwrap().enter(|tcx| { ... })` call and only keep the contents of the closure.
## Custom driver deprecation
The `after_crate_root_parsing` callback is now deprecated. Several custom drivers are incorrectly calling `queries.global_ctxt()` from inside of it, which causes some driver code to be skipped. As such I would like to either remove it in the future or if custom drivers still need it, change it to accept an `&rustc_ast::Crate` instead.
|
|
Recover some lost performence from #132732
This PR reorders some conditions in the `dangling_pointers_from_temporaries` lint to avoid some potentially expensive query call, in particular those who could involve some metadata decoding from disk.
cc https://github.com/rust-lang/rust/pull/132732#issuecomment-2499990683
cc `@Kobzol`
|
|
|
|
|
|
|
|
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Now that `HashSet::entry()` exists, we don't need to fake it with a map.
|
|
|
|
Do not unify dereferences of shared borrows in GVN
Repost of https://github.com/rust-lang/rust/pull/132461, the last commit applies my suggestions.
Fixes https://github.com/rust-lang/rust/issues/130853
|
|
Some minor dyn-related tweaks
Each commit should be self-explanatory, but I'm happy to explain what's going on if not. These are tweaks I pulled out of #133388, but they can be reviewed sooner than that.
r? types
|
|
|
|
Allow injecting a profiler runtime into `#![no_core]` crates
An alternative to #133300, allowing `-Cinstrument-coverage` to be used with `-Zbuild-std`.
The incompatibility between `profiler_builtins` and `#![no_core]` crates appears to have been caused by profiler_builtins depending on core, and therefore conflicting with core (or minicore).
But that's a false dependency, because the profiler doesn't contain any actual Rust code. So we can just mark the profiler itself as `#![no_core]`, and remove the incompatibility error.
---
For context, the error was originally added by #79958.
|
|
Rollup of 6 pull requests
Successful merges:
- #132979 (use `--exact` on `--skip` to avoid unintended substring matches)
- #133248 (CI: split x86_64-msvc-ext job)
- #133449 (std: expose `const_io_error!` as `const_error!`)
- #133453 (Commit license-metadata.json to git and check it's correct in CI)
- #133457 (miri: implement `TlsFree`)
- #133493 (do not constrain infer vars in `find_best_leaf_obligation`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
do not constrain infer vars in `find_best_leaf_obligation`
This ended up causing an ICE by making the following code path reachable by incorrectly constraining an inference variable while computing the best obligation for a preceding ambiguity. Closes #129444.
https://github.com/rust-lang/rust/blob/f2abf827c128120ed7a874d02973947968c158b8/compiler/rustc_trait_selection/src/solve/fulfill.rs#L312-L314
I have to be honest, I don't fully understand how that change removes all the additional diagnostics :3
r? `@compiler-errors`
|
|
miri: implement `TlsFree`
If the variable does not need a destructor, `std` uses racy initialization for creating TLS keys on Windows. With just the right timing, this can lead to `TlsFree` being called. Unfortunately, with #132654 this is hit quite often, so miri should definitely support `TlsFree` ([documentation](https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-tlsfree)).
I'm filing this here instead of in the miri repo so that #132654 isn't blocked for so long.
|
|
Commit license-metadata.json to git and check it's correct in CI
This PR adds `license-metadata.json` to the root of the git repo, and changes `mingw-check` to check that the file is still up-to-date.
By committing this file, we remove the need for developers to a) have reuse installed or b) run an expensive ~90 second analysis of the files on disk when they want generate the COPYRIGHT.html files which depend on this license metadata.
The file will need updating whenever `REUSE.toml` changes, or when git submodules are added, or when git submodules change their license information (as detected by REUSE).
You can now run:
* `./x run collect-license-metadata` to update the `./license-metadata.json` file
* `./x test collect-license-metadata` to test the `./license-metadata.json` file for correctness
The comparison is done with two `serde_json::Value` objects, so the map objects they contain should ignore differences in ordering.
|
|
std: expose `const_io_error!` as `const_error!`
ACP: https://github.com/rust-lang/libs-team/issues/205
Tracking issue: https://github.com/rust-lang/rust/issues/133448
Probably best reviewed commit-by-commit, the first one does the API change, the second does the mass-rename.
|
|
CI: split x86_64-msvc-ext job
try-job: x86_64-msvc-ext1
try-job: x86_64-msvc-ext3
|
|
use `--exact` on `--skip` to avoid unintended substring matches
Without the `--exact` flag, using `--skip tests/rustdoc` can unintentionally skip other tests that match as substrings such as `rustdoc-gui`, `rustdoc-js`, etc.
For debugging, run: `./x.py --stage 2 test rustdoc-ui --skip tests/rustdoc` and `./x.py --stage 2 test rustdoc-ui --skip tests/rustdoc -- --exact`
Resolves https://github.com/rust-lang/rust/issues/117721
try-job: x86_64-apple-1
|
|
|
|
Use edition of `macro_rules` when compiling the macro
This changes the edition assigned to a macro_rules macro when it is compiled to use the edition of where the macro came from instead of the local crate's edition.
This fixes a problem when a macro_rules macro is created by a proc-macro. Previously that macro would be tagged with the local edition, which would cause problems with using the correct edition behavior inside the macro. For example, the check for unsafe attributes would cause errors in 2024 when using proc-macros from older editions.
This is partially related to https://github.com/rust-lang/rust/issues/132906. Unfortunately this is only a half fix for that issue. It fixes the error that happens in 2024, but does not fix the lint firing in 2021. I'm still trying to think of some way to fix that, but I'm running low on ideas.
|
|
not WF
It's okay though b/c these are duplicated diagnostics.
|
