-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Rollup of 10 pull requests #142490
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
Closed
Rollup of 10 pull requests #142490
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The unexpected configs are now unused or known to `rustc` in our CI.
This allows UTF-8 characters to be printed without escapes, rather than just ASCII.
Replace `build.rs` Rust generation with macros, using the unstable `${concat(...)}`. Fixes: rust-lang/compiler-builtins#947
After adding tests, the current implementation for fminimum fails when provided a negative zero and NaN as inputs: ---- math::fminimum_fmaximum_num::tests::fmaximum_num_spec_tests_f64 stdout ---- thread 'math::fminimum_fmaximum_num::tests::fmaximum_num_spec_tests_f64' panicked at libm/src/math/fminimum_fmaximum_num.rs:240:13: fmaximum_num(-0x0p+0, NaN) l: NaN (0x7ff8000000000000) r: -0.0 (0x8000000000000000) ---- math::fminimum_fmaximum_num::tests::fmaximum_num_spec_tests_f32 stdout ---- thread 'math::fminimum_fmaximum_num::tests::fmaximum_num_spec_tests_f32' panicked at libm/src/math/fminimum_fmaximum_num.rs:240:13: fmaximum_num(-0x0p+0, NaN) l: NaN (0x7fc00000) r: -0.0 (0x80000000) Add more thorough spec tests for these functions and correct the implementations. Canonicalization is also moved to a trait method to centralize documentation about what it does and doesn't do.
Use a consistent ordering for top-level manifest keys, and remove those that are now redundant (`homapage` isn't supposed to be the same as `repository`, and `documentation` automatically points to docs.rs now).
Now that this repository is a subtree, we have no need to continue publishing `compiler-builtins`.
Signed-off-by: Jonathan Brouwer <[email protected]>
…anchor Signed-off-by: Jonathan Brouwer <[email protected]>
The config file is not needed anymore since compiler-builtins is no longer published. Removing it will resolve a CI failure.
To prepare for merging from rust-lang/rust, set the version file to: d087f11 Auto merge of rust-lang#134841 - estebank:serde-attr-4, r=wesleywiser
Out-of-tree testing is broken with the most recent update from rust-lang/rust because it makes `compiler-builtins` depend on `core` by path, which isn't usually available. In order to enable testing outside of rust-lang/rust, add a new crate `builtins-shim` that uses the same source as `compiler-builtins` but drops the `core` dependency. This has replaced `compiler-builtins` as the workspace member and entrypoint for tests.
Temporary lifetime extension through tuple struct and tuple variant constructors This makes temporary lifetime extension work for tuple struct and tuple variant constructors, such as `Some()`. Before: ```rust let a = &temp(); // Extended let a = Some(&temp()); // Not extended :( let a = Some { 0: &temp() }; // Extended ``` After: ```rust let a = &temp(); // Extended let a = Some(&temp()); // Extended let a = Some { 0: &temp() }; // Extended ``` So, with this change, this works: ```rust let a = Some(&String::from("hello")); // New: String lifetime now extended! println!("{a:?}"); ``` Until now, we did not extend through tuple struct/variant constructors (like `Some`), because they are function calls syntactically, and we do not want to extend the String lifetime in: ```rust let a = some_function(&String::from("hello")); // String not extended! ``` However, it turns out to be very easy to distinguish between regular functions and constructors at the point where we do lifetime extension. In practice, constructors nearly always use UpperCamelCase while regular functions use lower_snake_case, so it should still be easy to for a human programmer at the call site to see whether something qualifies for lifetime extension or not. This needs a lang fcp. --- More examples of what will work after this change: ```rust let x = Person { name: "Ferris", job: Some(&Job { // `Job` now extended! title: "Chief Rustacean", organisation: "Acme Ltd.", }), }; dbg!(x); ``` ```rust let file = if use_stdout { None } else { Some(&File::create("asdf")?) // `File` now extended! }; set_logger(file); ``` ```rust use std::path::Component; let c = Component::Normal(&OsString::from(format!("test-{num}"))); // OsString now extended! assert_eq!(path.components.first().unwrap(), c); ```
…r=aDotInTheVoid [rustdoc] Give more information into extracted doctest information Follow-up of rust-lang#134531. This update fragment the doctest code into its sub-parts to give more control to the end users on how they want to use it. The new JSON looks like this: ```json { "format_version":2, "doctests":[ { "file":"$DIR/extract-doctests-result.rs", "line":8, "doctest_attributes":{ "original":"", "should_panic":false, "no_run":false, "ignore":"None", "rust":true, "test_harness":false, "compile_fail":false, "standalone_crate":false, "error_codes":[], "edition":null, "added_css_classes":[], "unknown":[] }, "original_code":"let x = 12;\nOk(())", "doctest_code":{ "crate_level":"#![allow(unused)]\n", "code":"let x = 12;\nOk(())", "wrapper":{ "before":"fn main() { fn _inner() -> core::result::Result<(), impl core::fmt::Debug> {\n", "after":"\n} _inner().unwrap() }", "returns_result":true } }, "name":"$DIR/extract-doctests-result.rs - (line 8)" } ] } ``` for this doctest: ```rust let x = 12; Ok(()) ``` With this, I think it matches what you need `@ojeda?` If so, once merged I'll update the patch I sent to RfL. r? `@aDotInTheVoid`
…riplett Delegate `<SocketAddr as Debug>` to `ByteStr` This allows UTF-8 characters to be printed without escapes, rather than just ASCII. r? `@joshtriplett`
Unimplement unsized_locals Implements rust-lang/compiler-team#630 Tracking issue here: rust-lang#111942 Note that this just removes the feature, not the implementation, and does not touch `unsized_fn_params`. This is because it is required to support `Box<dyn FnOnce()>: FnOnce()`. There may be more that should be removed (possibly in follow up prs) - the `forget_unsized` function and `forget` intrinsic. - the `unsized_locals` test directory; I've just fixed up the tests for now - various codegen support for unsized values and allocas cc `@JakobDegen` `@oli-obk` `@Noratrieb` `@programmerjake` `@bjorn3` `@rustbot` label F-unsized_locals Fixes rust-lang#79409
…enton Stabilize "file_lock" feature Closes rust-lang#130994 r? `@joshtriplett`
float tests: deduplicate min, max, and rounding tests Part of rust-lang#141726 Best reviewed commit-by-commit. - Use `assert_biteq!` in the `mod.rs` tests. This requires some trickery to make shadowing macros with imports work. - The min, max, minimum, maximum tests in `tests/floats/f*.rs` are entirely subsumed by what we already have in `tests/float/mod.rs`, so I just removed them. - The rounding tests (floor etc) in `f*.rs` had more test points, so I copied them over. They didn't have `0.5` and `-0.5` though which seem like interesting points in particular regarding the sign of the resulting zero if that's what it sounds to, and they didn't max min/max/inf/nan tests, so this was really a merger of both tests. r? `@tgross35`
…workingjubilee variadic functions: remove list of supported ABIs from error I think this list is problematic for multiple reasons: - It is bound to go out-of-date as it is in a very different place from where we actually define which functions support varagrs (`fn supports_varargs`). - Many of the ABIs we list only work on some targets; it makes no sense to mention "aapcs" as a possible ABI when building for x86_64. (This led to a lot of confusion in rust-lang#110505 where the author thought they should use "cdecl" and then were promptly told that "cdecl" is not a legal ABI on their target.) - Typically, when the programmer wrote `extern "foobar"`, it is because they need the "foobar" ABI. It is of little use to tell them that there are other ABIs with which varargs would work. Cc `@workingjubilee`
…ggestion, r=WaffleLapkin Fix incorrect suggestion when calling an associated type with a type anchor `sugg_span` here is the span of the call expression. That span here is the `<Self>::Assoc`, which is exactly what we need here (even though I would expect it to include the arguments, but I guess it doesn't) r? `@WaffleLapkin` One commit with failing tests and one that fixes it for reviewability closes rust-lang#142473
Remove unneeded lifetime bound from signature of BTreeSet::extract_if One way to observe the difference between these signatures, using 0 explicit lifetimes and 0 contrived where-clauses: ```rust use std::collections::btree_set::{BTreeSet, ExtractIf}; use std::ops::RangeFull; fn repro( set: &mut BTreeSet<i32>, predicate: impl Fn(i32) -> bool, ) -> ExtractIf<i32, RangeFull, impl FnMut(&i32) -> bool> { set.extract_if(.., move |x| predicate(*x)) } ``` **Before:** ```console error[E0311]: the parameter type `impl Fn(i32) -> bool` may not live long enough --> src/lib.rs:8:5 | 5 | set: &mut BTreeSet<i32>, | ------------------ the parameter type `impl Fn(i32) -> bool` must be valid for the anonymous lifetime defined here... ... 8 | set.extract_if(.., move |x| predicate(*x)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ...so that the type `impl Fn(i32) -> bool` will meet its required lifetime bounds | help: consider adding an explicit lifetime bound | 4 ~ fn repro<'a>( 5 ~ set: &'a mut BTreeSet<i32>, 6 ~ predicate: impl Fn(i32) -> bool + 'a, 7 ~ ) -> ExtractIf<'a, i32, RangeFull, impl FnMut(&i32) -> bool> { | ``` **After:** compiles success. - Tracking issue: rust-lang#70530
Update the `compiler-builtins` subtree Update the Josh subtree to rust-lang/compiler-builtins@7c46e921c117. r? `@ghost`
@bors r+ rollup=never p=5 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-compiler-builtins
Area: compiler-builtins (https://github.com/rust-lang/compiler-builtins)
A-rustc-dev-guide
Area: rustc-dev-guide
A-tidy
Area: The tidy tool
O-unix
Operating system: Unix-like
rollup
A PR which is a rollup
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
T-bootstrap
Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
T-libs
Relevant to the library team, which will review and decide on the PR/issue.
T-rustdoc
Relevant to the rustdoc team, which will review and decide on the PR/issue.
T-rustdoc-frontend
Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
<SocketAddr as Debug>
toByteStr
#141493 (Delegate<SocketAddr as Debug>
toByteStr
)compiler-builtins
subtree #142489 (Update thecompiler-builtins
subtree)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup