In E0716, there is a code block that is equivalent to the erroneous
code example. Especially when viewed with `rustc --explain`, it's
not obvious that it is also erroneous, and some users have been
confused when they try to change their code to match the erroneous
equivalent.
core: add unstable no_fp_fmt_parse to disable float formatting code
In some projects (e.g. kernel), floating point is forbidden. They can disable
hardware floating point support and use `+soft-float` to avoid fp instructions
from being generated, but as libcore contains the formatting code for `f32`
and `f64`, some fp intrinsics are depended. One could define stubs for these
intrinsics that just panic [1], but it means that if any formatting functions
are accidentally used, mistake can only be caught during the runtime rather
than during compile-time or link-time, and they consume a lot of space without
LTO.
This patch provides an unstable cfg `no_fp_fmt_parse` to disable these.
A panicking stub is still provided for the `Debug` implementation (unfortunately)
because there are some SIMD types that use `#[derive(Debug)]`.
[1]: https://lkml.org/lkml/2021/4/14/1028
Stabilize `str::from_utf8_unchecked` as `const`
This stabilizes `unsafe fn str::from_utf8_unchecked` as `const` pending FCP on #75196. By the time FCP finishes, the beta will have already been cut, so I've set 1.55 as the stable-since version.
(should also be +relnotes but I don't have the permission to do that)
r? `@m-ou-se`
Closes#75196
Support allocation failures when interpreting MIR
This closes#79601 by handling the case where memory allocation fails during MIR interpretation, and translates that failure into an `InterpError`. The error message is "tried to allocate more memory than available to compiler" to make it clear that the memory shortage is happening at compile-time by the compiler itself, and that it is not a runtime issue.
Now that memory allocation can fail, it would be neat if Miri could simulate low-memory devices to make it easy to see how much memory a Rust program needs.
Note that this breaks Miri because it assumes that allocation can never fail.
Warn when `rustdoc::` group is omitted from lint names
When rustdoc lints were first made a tool lint, they gave an unconditional warning when you used the original name:
```
warning: lint `broken_intra_doc_links` has been renamed to `rustdoc::broken_intra_doc_links`
--> $DIR/renamed-lint-still-applies.rs:2:9
|
LL | #![deny(broken_intra_doc_links)]
| ^^^^^^^^^^^^^^^^^^^^^^ help: use the new name: `rustdoc::broken_intra_doc_links`
|
= note: `#[warn(renamed_and_removed_lints)]` on by default
```
That was reverted in https://github.com/rust-lang/rust/pull/83203 because adding `rustdoc::x` lints would cause the code to break on old versions of the compiler (due to https://github.com/rust-lang/rust/issues/66079#issuecomment-788589193, "fixed" in https://github.com/rust-lang/rust/pull/83216 in the sense that you can now opt-in to not breaking on nightly, which is not ideal but `register_tool` is a long way from stabilizing). Since https://github.com/rust-lang/rust/pull/80527 is now on 1.52.0 stable, we can re-enable the warning. For nightly users, they can change immediately and still have their code work on stable; for stable users, they can change their code in 12 weeks and still have it work up to 3 releases back (about 18 weeks). That seems reasonable to me.
r? `@Manishearth` cc `@rust-lang/rustdoc`
Remove the deprecated `core::raw` and `std::raw` module.
A few months has passed since #84207. I think now it's time for the final removal.
Closes#27751.
r? `@m-ou-se`
- Don't print the exact command run by rustbuild unless `--verbose` is set.
This is almost always unhelpful, since it's just cargo with a lot of
arguments.
- Don't print "Build completed unsuccessfully" unless --verbose is set.
You can already tell the build failed by the errors above, and the
time isn't particularly helpful.
- Don't print the full path to bootstrap. This is useless to everyone,
even including when working on x.py itself. You can still opt-in to
this being shown with `--verbose`, since it will throw an exception.
Before:
```
error[E0432]: unresolved import `x`
--> library/std/src/lib.rs:343:5
|
343 | use x;
| ^ no external crate `x`
error: aborting due to previous error
For more information about this error, try `rustc --explain E0432`.
error: could not compile `std`
To learn more, run the command again with --verbose.
command did not execute successfully: "/home/joshua/rustc4/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "check" "--target" "x86_64-unknown-linux-gnu" "-Zbinary-dep-depinfo" "-j" "8" "--release" "--features" "panic-unwind backtrace" "--manifest-path" "/home/joshua/rustc4/library/test/Cargo.toml" "--message-format" "json-render-diagnostics"
expected success, got: exit status: 101
failed to run: /home/joshua/rustc4/build/bootstrap/debug/bootstrap check
Build completed unsuccessfully in 0:00:13
```
After:
```
error[E0432]: unresolved import `x`
--> library/std/src/lib.rs:343:5
|
343 | use x;
| ^ no external crate `x`
error: aborting due to previous error
For more information about this error, try `rustc --explain E0432`.
error: could not compile `std`
To learn more, run the command again with --verbose.
```
When using `process::Command` on Windows, environment variable names must be case-preserving but case-insensitive
When using `Command` to set the environment variables, the key should be compared as uppercase Unicode but when set it should preserve the original case.
Fixes#85242
Return `EvaluatedToOk` when type in outlives predicate is global
A global type doesn't reference any local regions or types, so it's
guaranteed to outlive any region.
Update cargo
5 commits in 4952979031e2cf1d901c817a32e25a156a19db4c..3ebb5f15a940810f250b68821149387af583a79e
2021-07-01 01:14:50 +0000 to 2021-07-02 20:35:38 +0000
- Adjust the edition2021 resolver diff report. (rust-lang/cargo#9649)
- Include the linker in the fingerprint. (rust-lang/cargo#9647)
- Temporarily disable windows env test. (rust-lang/cargo#9646)
- Handle git deleted files with dirty worktree. (rust-lang/cargo#9645)
- Adjust error message with offline and frozen. (rust-lang/cargo#9644)
Avoid byte to char position conversions in `is_multiline`
Converting a byte position into a char position is currently linear in
the number of multibyte characters in the source code. Avoid it when
checking if a range spans across lines.
This makes it feasible to compile source files with a large number of
multibyte characters.
alloc: `no_global_oom_handling`: disable `new()`s, `pin()`s, etc.
They are infallible, and could not be actually used because
they will trigger an error when monomorphized, but it is better
to just remove them.
Link: https://github.com/Rust-for-Linux/linux/pull/402
Suggested-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
add owned locked stdio handles
Add stderr_locked, stdin_locked, and stdout_locked free functions
to obtain owned locked stdio handles in a single step. Also add
into_lock methods to consume a stdio handle and return an owned
lock. These methods will make it easier to use locked stdio
handles without having to deal with lifetime problems or keeping
bindings to the unlocked handles around.
Fixes#85383; enables #86412.
r? `@joshtriplett`
`@rustbot` label +A-io +C-enhancement +D-newcomer-roadblock +T-libs-api
Downgrade nonstandard_macro_braces to nursery
Due to the large number of crates impacted by #7422, I don't think this lint can be enabled by default right now until the false positive is fixed.
---
changelog: remove [`nonstandard_macro_braces`] from default set of enabled lints
deny using default function in impl const Trait
Fixes#79450.
I don't know if my implementation is correct:
- The check is in `rustc_passes::check_const`, should I put it somewhere else instead?
- Is my approach (to checking the impl) optimal? It works for the current tests, but it might have some issues or there might be a better way of doing this.
