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>