| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Update Trusty target maintainers
Remove Stephen Crane from the list of Trusty target maintainers and add Andrei Homescu (`@ahomescu)` and Chris Wailes.
|
|
Add new_cyclic_in for Rc and Arc
Currently, new_cyclic_in does not exist for Rc and Arc. This is an oversight according to https://github.com/rust-lang/wg-allocators/issues/132.
This PR adds new_cyclic_in for Rc and Arc. The implementation is almost the exact same as new_cyclic with some small differences to make it allocator-specific. new_cyclic's implementation has been replaced with a call to `new_cyclic_in(data_fn, Global)`.
Remaining questions:
* ~~Is requiring Allocator to be Clone OK? According to https://github.com/rust-lang/wg-allocators/issues/88, Allocators should be cheap to clone. I'm just hesitant to add unnecessary constraints, though I don't see an obvious workaround for this function since many called functions in new_cyclic_in expect an owned Allocator. I see Allocator.by_ref() as an option, but that doesn't work on when creating Weak { ptr: init_ptr, alloc: alloc.clone() }, because the type of Weak then becomes Weak<T, &A> which is incompatible.~~ Fixed, thank you `@zakarumych!` This PR no longer requires the allocator to be Clone.
* Currently, new_cyclic_in's documentation is almost entirely copy-pasted from new_cyclic, with minor tweaks to make it more accurate (e.g. Rc<T> -> Rc<T, A>). The example section is removed to mitigate redundancy and instead redirects to cyclic_in. Is this appropriate?
* ~~The comments in new_cyclic_in (and much of the implementation) are also copy-pasted from new_cyclic. Would it be better to make a helper method new_cyclic_in_internal that both functions call, with either Global or the custom allocator? I'm not sure if that's even possible, since the internal method would have to return Arc<T, Global> and I don't know if it's possible to "downcast" that to an Arc<T>. Maybe transmute would work here?~~ Done, thanks `@zakarumych`
* Arc::new_cyclic is #[inline], but Rc::new_cyclic is not. Which is preferred?
* nit: does it matter where in the impl block new_cyclic_in is defined?
|
|
Fix fluent diagnostics
This line number calculation was both wrong and unnecessary.
|
|
This line number calculation was both wrong and unnecessary.
|
|
|
|
Relate receiver invariantly in method probe for `Mode::Path`
Effectively reverts part of #126128
Fixes #126227
This PR changes method probing to use equality for fully path-based method lookup, and subtyping for receiver `.` method lookup.
r? lcnr
|
|
Remove semi-nondeterminism of `DefPathHash` ordering from inliner
Déjà vu or something because I kinda thought I had put this PR up before. I recall a discussion somewhere where I think it was `@saethlin` mentioning that this check was no longer needed since we have "proper" cycle detection. Putting that up as a PR now.
This may slighlty negatively affect inlining, since the cycle breaking here means that we still inlined some cycles when the def path hashes were ordered in certain ways, this leads to really bad nondeterminism that makes minimizing ICEs and putting up inliner bugfixes difficult.
r? `@cjgillot` or `@saethlin` or someone else idk
|
|
`RepeatN`: use MaybeUninit
Closes #130140. Closes #130141.
Use `MaybeUninit` instead of `ManuallyDrop` for soundness.
|
|
Rollup of 4 pull requests
Successful merges:
- #130380 (coverage: Clarify some parts of coverage counter creation)
- #130427 (run_make_support: rectify symlink handling)
- #130447 (rustc_llvm: update for llvm/llvm-project@2ae968a0d9fb61606b020e898d88…)
- #130448 (fix: Remove duplicate `LazyLock` example.)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
fix: Remove duplicate `LazyLock` example.
The top-level docs for `LazyLock` included two lines of code, each with an accompanying comment, that were identical and with nearly- identical comments. This looks like an oversight from a past edit which was perhaps trying to rewrite an existing example but ended up duplicating rather than replacing, though I haven't gone back through the Git history to check.
This commit removes what I personally think is the less-clear of the two examples.
|
|
rustc_llvm: update for llvm/llvm-project@2ae968a0d9fb61606b020e898d88…
…4c82dd0ed8b5
Just a simple header move.
`@rustbot` label: +llvm-main
|
|
run_make_support: rectify symlink handling
Avoid confusing Unix symlinks and Windows symlinks. Since their
semantics are quite different, we should avoid trying to make it
automagic in how symlinks are created and deleted. Notably, the tests
should reflect what type of symlinks are to be created to match what std
does to make it less surprising for test readers.
|
|
coverage: Clarify some parts of coverage counter creation
This is a series of semi-related changes that are trying to make the `counters` module easier to read, understand, and modify.
For example, the existing code happens to avoid ever using the count for a `TerminatorKind::Yield` node as the count for its sole out-edge (since doing so would be incorrect), but doesn't do so explicitly, so seemingly-innocent changes can result in baffling test failures.
This PR also takes the opportunity to simplify some debug-logging code that was making its surrounding code disproportionately hard to read.
There should be no changes to the resulting coverage instrumentation/mappings, as demonstrated by the absence of changes to the coverage test suite.
|
|
|
|
layout computation: gracefully handle unsized types in unexpected locations
This PR reworks the layout computation to eagerly return an error when encountering an unsized field where a sized field was expected, rather than delaying a bug and attempting to recover a layout. This is required, because with trivially false where clauses like `[T]: Sized`, any field can possible be an unsized type, without causing a compile error.
Since this PR removes the `delayed_bug` method from the `LayoutCalculator` trait, it essentially becomes the same as the `HasDataLayout` trait, so I've also refactored the `LayoutCalculator` to be a simple wrapper struct around a type that implements `HasDataLayout`.
The majority of the diff is whitespace changes, so viewing with whitespace ignored is advised.
implements https://github.com/rust-lang/rust/pull/123169#issuecomment-2025788480
r? `@compiler-errors` or compiler
fixes https://github.com/rust-lang/rust/issues/123134
fixes https://github.com/rust-lang/rust/issues/124182
fixes https://github.com/rust-lang/rust/issues/126939
fixes https://github.com/rust-lang/rust/issues/127737
|
|
Co-authored-by: David Tolnay <dtolnay@gmail.com>
|
|
llvm/llvm-project@2ae968a0d9fb61606b020e898d884c82dd0ed8b5
Just a simple header move.
@rustbot label: +llvm-main
|
|
|
|
[library/std/src/process.rs] `PartialEq` for `ExitCode`
Converting a third-party CLI to a library so started passing around [`std::process::ExitCode`](https://doc.rust-lang.org/std/process/struct.ExitCode.html) in an `Either`. Then I realised the tests can't be modified to compare equality of `ExitCode`s.
This PR fixes this oversight.
|
|
For structs that cannot be unsized, the layout algorithm sometimes moves
unsized fields to the end of the struct, which circumvented the error
for unexpected unsized fields and returned an unsized layout anyway.
This commit makes it so that the unexpected unsized error is always
returned for structs that cannot be unsized, allowing us to remove an
old hack and fixing some old ICE.
|
|
|
|
The top-level docs for `LazyLock` included two lines of code, each
with an accompanying comment, that were identical and with nearly-
identical comments. This looks like an oversight from a past edit
which was perhaps trying to rewrite an existing example but ended
up duplicating rather than replacing, though I haven't gone back
through the Git history to check.
This commit removes what I personally think is the less-clear of
the two examples.
Signed-off-by: Andrew Lilley Brinker <alilleybrinker@gmail.com>
|
|
Rollup of 3 pull requests
Successful merges:
- #130033 (Don't call `fn_arg_names` query for non-`fn` foreign items in resolver)
- #130282 (Do not report an excessive number of overflow errors for an ever-growing deref impl)
- #130437 (Avoid crashing on variadic functions when producing arg-mismatch errors)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Avoid crashing on variadic functions when producing arg-mismatch errors
Fixes #130372 by accommodating how variadic functions change the argument list length between HIR body and FnDecls.
Also degrades the zip_eq to a debug_assert! to match other asserts in the area to avoid being disruptive to users. There is at least one other crash in this area I am working on in #130400 and also considering how we might refactor some of this code to hoist some of this logic up higher.
r? `@compiler-errors`
|
|
Do not report an excessive number of overflow errors for an ever-growing deref impl
Check that we don't first hit the recursion limit in `get_field_candidates_considering_privacy` before probing for methods when we have a method lookup failure and we want to see if `.field.method()` exists. We also silence overflow error messages if we're probing for methods for diagnostics.
Also renames some functions to make it clearer that they're only for diagnostics, and sprinkle some `Autoderef::silence_errors` around to silence unnecessary overflow errors that come from diagnostics.
Fixes #130224.
|
|
Don't call `fn_arg_names` query for non-`fn` foreign items in resolver
Fixes #130015
|
|
|
|
Rollup of 4 pull requests
Successful merges:
- #123436 (linker: Allow MSVC to use import libraries following the Meson/MinGW convention)
- #130410 (Don't ICE when generating `Fn` shim for async closure with borrowck error)
- #130412 (Don't ICE when RPITIT captures more method args than trait definition)
- #130436 (Ignore reduce-fadd-unordered on SGX platform)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
r=RalfJung
Ignore reduce-fadd-unordered on SGX platform
#130325 added the `tests/assembly/simd/reduce-fadd-unordered.rs` test. Unfortunately, the use of `CHECK: ret` makes that this test is not compatible with LVI mitigations applied for the SGX target. This PR makes sure this test is ignored for the SGX target, until a nicer solution is available.
|
|
Don't ICE when RPITIT captures more method args than trait definition
Make sure we don't ICE when an RPITIT captures more method args than the trait definition, which is not allowed. This was because we were using the wrong def id for error reporting.
Due to the default lifetime capture rules of RPITITs (capturing everything in scope), this is only doable if we use precise capturing, which isn't currently allowed for RPITITs anyways but we still end up reaching the relevant codepaths.
Fixes #129850
|
|
Don't ICE when generating `Fn` shim for async closure with borrowck error
Turn an assumption that I had originally written as an assert into a delayed bug, because this shim code is reachable even if we have borrowck errors via the MIR inliner.
Fixes #129262.
|
|
amyspark:allow-msvc-to-use-meson-and-mingw-import-libraries, r=petrochenkov
linker: Allow MSVC to use import libraries following the Meson/MinGW convention
Hi all,
This PR implements support for `MsvcLinker` to use import libraries following Meson and the MinGW toolchain's naming convention. Meson [follows the `libfoo.dll.a` naming convention](https://mesonbuild.com/FAQ.html#why-does-building-my-project-with-msvc-output-static-libraries-called-libfooa) to disambiguate between static and import libraries.
This support already existed for static libraries (see #100101), but not for dynamic libraries. The latter case was added by duplicating the logic in `native_libs::find_native_static_library`, but a separate case was added in `link_dylib_by_name` for the Windows CRT libraries which must be handled by the linker itself.
See for prerequisites #129366, #126094, and #128370.
All feedback is appreciated!
Fixes #122455
cc `@sdroege` `@nirbheek`
|
|
Do precise capturing arg validation in resolve
Moves the validation of precise capturing args (`use<T, N>`) out of `resolve_bound_vars` and into `rustc_resolve`. This both simplifies the impl and fixes a bug when we have `use<arg>` where `arg` is one of the function args.
This also introduces new error codes specifically for precise capturing, to avoid reusing the other error codes which are not as accurate.
Fixes #130399
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Avoid confusing Unix symlinks and Windows symlinks, and since their
semantics are quite different we should avoid trying to make it to
automagic in how symlinks are created and deleted. Notably, the tests
should reflect what type of symlinks are to be created to match what std
does to make it less surprising for test readers.
|
|
Don't use `typeck_root_def_id` in codegen for finding closure's root
Generating debuginfo in codegen currently peels off all the closure-specific generics (which presumably is done because they're redundant). This doesn't currently work correctly for the bodies we synthesize for async closures's returned coroutines (#128506), leading to #129702.
Specifically, `typeck_root_def_id` for some `DefKind::SyntheticCoroutineBody` just returns itself (because it loops while `is_typeck_child` is `true`, and that returns `false` for this defkind), which means we don't end up peeling off the coroutine-specific generics, and we end up encountering an otherwise unreachable `CoroutineWitness` type leading to an ICE.
This PR fixes `is_typeck_child` to consider `DefKind::SyntheticCorotuineBody` to be a typeck child, fixing `typeck_root_def_id` and suppressing this debuginfo bug.
Fixes #129702
|
|
Rollup of 5 pull requests
Successful merges:
- #127879 (Document futility of printing temporary pointers)
- #130325 (Use -0.0 in `intrinsics::simd::reduce_add_unordered`)
- #130336 (simplify `Build::update_existing_submodule`)
- #130398 (Add system libs for LLVM when cross compiling for Windows)
- #130420 (Register tool docs for `src/tools/build_helper`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Register tool docs for `src/tools/build_helper`
Fixes #130355.
|
|
Add system libs for LLVM when cross compiling for Windows
Windows uses "import libraries" to link to system libraries. These are a kind of static lib that are distributed with the Windows SDK and therefore they don't rely on the host. All that matters is you have the right SDK installed for the target.
|
|
simplify `Build::update_existing_submodule`
`Build::update_existing_submodule` is already doing the same thing..
|
|
r=RalfJung,jieyouxu
Use -0.0 in `intrinsics::simd::reduce_add_unordered`
-0.0 is the actual neutral additive float, not +0.0, and this matters to codegen.
try-job: aarch64-gnu
|
|
Document futility of printing temporary pointers
In the user forum I've seen a few people trying to understand how borrowing and moves are implemented by peppering their code with printing of `{:p}` of references to variables and expressions. This is a bad idea. It gives misleading and confusing results, because of autoderef magic, printing pointers of temporaries on the stack, and/or causes LLVM to optimize code differently when values had their address exposed.
|
