-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Rollup of 8 pull requests #123762
Rollup of 8 pull requests #123762
Conversation
This PR aims to pin down exactly what restricted_std is meant to achieve and what it isn't. This commit fixes rust-lang/wg-cargo-std-aware#87 by explaining why the error appears and what the choices the user has. The error describes how std cannot function without knowing about some form of OS/platform support. Any features of std that work without an OS should be moved to core/alloc (see rust-lang#27242 rust-lang#103765). Note that the message says "platform" and "environment" because, since rust-lang#120232, libstd can be built for some JSON targets. This is still unsupported (all JSON targets probably should be unstable rust-lang/wg-cargo-std-aware#90), but a JSON target with the right configuration should hopefully have some partial libstd support. I propose closing rust-lang/wg-cargo-std-aware#69 as "Won't fix" since any support of std without properly configured os, vendor or env fields is very fragile considering future upgrades of Rust or dependencies. In addition there's no likely path to it being fixed long term (making std buildable for all targets being the only solution). This is distinct from tier 3 platforms with limited std support implemented (and as such aren't restricted_std) because these platforms can conceptually work in the future and std support should mainly improve over time. The alternative to closing rust-lang/wg-cargo-std-aware#69 is a new crate feature for std which escapes the restricted_std mechanism in build.rs. It could be used with the -Zbuild-std-features flag if we keep it permanently unstable, which I hope we can do anyway. A minor side-effect in this scenario is that std wouldn't be marked as unstable if documentation for it were generated with build-std.
Newly stable API: ```rust impl CStr { pub fn count_bytes(&self) -> usize; } ``` Const stabilization has not yet been decided, so that will continue to be gated under <rust-lang#113219>. Fixes: <rust-lang#114441>
When suggesting a type on inference error, do not use `{closure@..}`. Instead, replace with an appropriate `fn` ptr. On the error message, use `short_ty_string` and write long types to disk. ``` error[E0284]: type annotations needed for `Select<{closure@lib.rs:2782:13}, _, Expression<'_>, _>` --> crates/lang/src/parser.rs:41:13 | 41 | let lit = select! { | ^^^ 42 | Token::Int(i) = e => Expression::new(Expr::Lit(ast::Lit::Int(i.parse().unwrap())), e.span()), | ---- type must be known at this point | = note: the full type name has been written to '/home/gh-estebank/iowo/target/debug/deps/lang-e2d6e25819442273.long-type-4587393693885174369.txt' = note: cannot satisfy `<_ as chumsky::input::Input<'_>>::Span == SimpleSpan` help: consider giving `lit` an explicit type, where the type for type parameter `I` is specified | 41 | let lit: Select<for<'a, 'b> fn(tokens::Token<'_>, &'a mut MapExtra<'_, 'b, _, _>) -> Option<Expression<'_>>, _, Expression<'_>, _> = select! { | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ``` instead of ``` error[E0284]: type annotations needed for `Select<{closure@/home/gh-estebank/.cargo/registry/src/index.crates.io-6f17d22bba15001f/chumsky-1.0.0-alpha.6/src/lib.rs:2782:13: 2782:28}, _, Expression<'_>, _>` --> crates/lang/src/parser.rs:41:13 | 41 | let lit = select! { | ^^^ 42 | Token::Int(i) = e => Expression::new(Expr::Lit(ast::Lit::Int(i.parse().unwrap())), e.span()), | ---- type must be known at this point | = note: cannot satisfy `<_ as chumsky::input::Input<'_>>::Span == SimpleSpan` help: consider giving `lit` an explicit type, where the type for type parameter `I` is specified | 41 | let lit: Select<{closure@/home/gh-estebank/.cargo/registry/src/index.crates.io-6f17d22bba15001f/chumsky-1.0.0-alpha.6/src/lib.rs:2782:13: 2782:28}, _, Expression<'_>, _> = select! { | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ``` Fix rust-lang#123630.
This reverts commit 049a917. The resolution to <rust-lang#123282> is that the `f16`/`f128` regression in the beta compiler was fixable without a revert, so the commit adding `#[cfg(not(bootstrap))]` is no longer useful (added in <rust-lang#123390>). Revert this commit because not having these basic impls bootstrap-gated simplifies everything else that uses them.
Implement basic operation traits that get lowered to intrinsics. This includes codegen tests for implemented operations.
Create empty modules so `rustdoc` has someplace to link to for these types.
…r=Amanieu `f16` and `f128` step 4: basic library support This is the next step after rust-lang#121926, another portion of rust-lang#114607 Tracking issue: rust-lang#116909 This PR adds the most basic operations to `f16` and `f128` that get lowered as LLVM intrinsics. This is a very small step but it seemed reasonable enough to add unopinionated basic operations before the larger modules that are built on top of them. r? ```@Amanieu``` since you were pretty involved in the RFC cc ```@compiler-errors``` ```@rustbot``` label +T-libs-api +S-blocked +F-f16_and_f128
…r=petrochenkov Be more specific when flagging imports as redundant due to the extern prelude There are multiple distinct kinds of [preludes](https://doc.rust-lang.org/reference/names/preludes.html). Be more specific when flagging imports as redundant due to the [extern prelude](https://doc.rust-lang.org/reference/names/preludes.html#extern-prelude). r? Nilstrieb or compiler
Skip `unused_parens` report for `Paren(Path(..))` in macro. fixes rust-lang#120642 In following code, `unused_parens` suggest change `<($($rest),*)>::bar()` to `<$rest>::bar()` which will cause another err: `error: variable 'rest' is still repeating at this depth`: ```rust trait Foo { fn bar(); } macro_rules! problem { ($ty:ident) => { impl<$ty: Foo> Foo for ($ty,) { fn bar() { <$ty>::bar() } } }; ($ty:ident $(, $rest:ident)*) => { impl<$ty: Foo, $($rest: Foo),*> Foo for ($ty, $($rest),*) { fn bar() { <$ty>::bar(); <($($rest),*)>::bar() } } problem!($($rest),*); } } ``` I think maybe we can handle this by avoid warning for `Paren(Path(..))` in the macro. Is this reasonable approach?
…d-std, r=ehuss Document restricted_std This PR aims to pin down exactly what restricted_std is meant to achieve and what it isn't. This commit fixes rust-lang/wg-cargo-std-aware#87 by explaining why the error appears and what the choices the user has. The error describes how std cannot function without knowing about some form of OS/platform support. Any features of std that work without an OS should be moved to core/alloc (see rust-lang#27242 rust-lang#103765). Note that the message says "platform" and "environment" because, since rust-lang#120232, libstd can be built for some JSON targets. This is still unsupported (all JSON targets probably should be unstable rust-lang/wg-cargo-std-aware#90), but a JSON target with the right configuration should hopefully have some partial libstd support. I propose closing rust-lang/wg-cargo-std-aware#69 as "Won't fix" since any support of std without properly configured os, vendor or env fields is very fragile considering future upgrades of Rust or dependencies. In addition there's no likely path to it being fixed long term (making std buildable for all targets being the only solution). This is distinct from tier 3 platforms with limited std support implemented (and as such aren't restricted_std) because these platforms can conceptually work in the future and std support should mainly improve over time. The alternative to closing rust-lang/wg-cargo-std-aware#69 is a new crate feature for std which escapes the restricted_std mechanism in build.rs. It could be used with the -Zbuild-std-features flag if we keep it permanently unstable, which I hope we can do anyway. A minor side-effect in this scenario is that std wouldn't be marked as unstable if documentation for it were generated with build-std. cc ```@ehuss```
…s, r=dtolnay Stabilize `cstr_count_bytes` Newly stable API: ```rust impl CStr { pub fn count_bytes(&self) -> usize; } ``` Const stabilization has not yet been decided, so that will continue to be gated under <rust-lang#113219>. FCP finished at rust-lang#114441 (comment). Fixes: <rust-lang#114441>
Use `fn` ptr signature instead of `{closure@..}` in infer error When suggesting a type on inference error, do not use `{closure@..}`. Instead, replace with an appropriate `fn` ptr. On the error message, use `short_ty_string` and write long types to disk. ``` error[E0284]: type annotations needed for `Select<{closure@lib.rs:2782:13}, _, Expression<'_>, _>` --> crates/lang/src/parser.rs:41:13 | 41 | let lit = select! { | ^^^ 42 | Token::Int(i) = e => Expression::new(Expr::Lit(ast::Lit::Int(i.parse().unwrap())), e.span()), | ---- type must be known at this point | = note: the full type name has been written to '/home/gh-estebank/iowo/target/debug/deps/lang-e2d6e25819442273.long-type-4587393693885174369.txt' = note: cannot satisfy `<_ as chumsky::input::Input<'_>>::Span == SimpleSpan` help: consider giving `lit` an explicit type, where the type for type parameter `I` is specified | 41 | let lit: Select<for<'a, 'b> fn(tokens::Token<'_>, &'a mut MapExtra<'_, 'b, _, _>) -> Option<Expression<'_>>, _, Expression<'_>, _> = select! { | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ``` instead of ``` error[E0284]: type annotations needed for `Select<{closure@/home/gh-estebank/.cargo/registry/src/index.crates.io-6f17d22bba15001f/chumsky-1.0.0-alpha.6/src/lib.rs:2782:13: 2782:28}, _, Expression<'_>, _>` --> crates/lang/src/parser.rs:41:13 | 41 | let lit = select! { | ^^^ 42 | Token::Int(i) = e => Expression::new(Expr::Lit(ast::Lit::Int(i.parse().unwrap())), e.span()), | ---- type must be known at this point | = note: cannot satisfy `<_ as chumsky::input::Input<'_>>::Span == SimpleSpan` help: consider giving `lit` an explicit type, where the type for type parameter `I` is specified | 41 | let lit: Select<{closure@/home/gh-estebank/.cargo/registry/src/index.crates.io-6f17d22bba15001f/chumsky-1.0.0-alpha.6/src/lib.rs:2782:13: 2782:28}, _, Expression<'_>, _> = select! { | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ``` Address rust-lang#123630 (test missing).
clean up docs for `File::sync_*` * Clarify that `sync_all` also writes data and not just metadata. * Clarify that dropping a file is not equivalent to calling `sync_all` and ignoring the result. `sync_all` the still the recommended way to detect errors before closing, because we don't have a dedicated method for that. * Add a link from `sync_all` to `sync_data`, because that's what the user might want to use instead. * Add doc aliases for `fsync` -> `sync_all` and `fdatasync` -> `sync_data`. Those are the POSIX standard names for these functions. I was trying to find out what we call `fsync` in Rust and had to search through the source code to find it, so this alias should help with that in the future.
…trait, r=estebank Use `suggest_impl_trait` in return type suggestion on type error Discovered while doing other refactoring. Review with whitespace disabled. r? estebank
@bors r+ rollup=never p=5 |
Rollup of 8 pull requests Successful merges: - rust-lang#122470 (`f16` and `f128` step 4: basic library support) - rust-lang#122954 (Be more specific when flagging imports as redundant due to the extern prelude) - rust-lang#123314 (Skip `unused_parens` report for `Paren(Path(..))` in macro.) - rust-lang#123360 (Document restricted_std) - rust-lang#123661 (Stabilize `cstr_count_bytes`) - rust-lang#123703 (Use `fn` ptr signature instead of `{closure@..}` in infer error) - rust-lang#123756 (clean up docs for `File::sync_*`) - rust-lang#123761 (Use `suggest_impl_trait` in return type suggestion on type error) r? `@ghost` `@rustbot` modify labels: rollup
💔 Test failed - checks-actions |
@bors retry |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: aa067fb984 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (4435924): comparison URL. Overall result: ❌✅ regressions and improvements - ACTION NEEDEDNext Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 675.211s -> 675.519s (0.05%) |
The @rustbot label: +perf-regression-triaged |
Successful merges:
f16
andf128
step 4: basic library support #122470 (f16
andf128
step 4: basic library support)unused_parens
report forParen(Path(..))
in macro. #123314 (Skipunused_parens
report forParen(Path(..))
in macro.)cstr_count_bytes
#123661 (Stabilizecstr_count_bytes
)fn
ptr signature instead of{closure@..}
in infer error #123703 (Usefn
ptr signature instead of{closure@..}
in infer error)File::sync_*
#123756 (clean up docs forFile::sync_*
)suggest_impl_trait
in return type suggestion on type error #123761 (Usesuggest_impl_trait
in return type suggestion on type error)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup