This commit updates the compiler to allow the `#[no_mangle]` (and
`#[export_name]` attributes) to be located anywhere within a crate.
These attributes are unconditionally processed, causing the compiler to
always generate an exported symbol with the appropriate name.
After some discussion on #54135 it was found that not a great reason
this hasn't been allowed already, and it seems to match the behavior
that many expect! Previously the compiler would only export a
`#[no_mangle]` symbol if it were *publicly reachable*, meaning that it
itself is `pub` and it's otherwise publicly reachable from the root of
the crate. This new definition is that `#[no_mangle]` *is always
reachable*, no matter where it is in a crate or whether it has `pub` or
not.
This should make it much easier to declare an exported symbol with a
known and unique name, even when it's an internal implementation detail
of the crate itself. Note that these symbols will persist beyond LTO as
well, always making their way to the linker.
Along the way this commit removes the `private_no_mangle_functions` lint
(also for statics) as there's no longer any need to lint these
situations. Furthermore a good number of tests were updated now that
symbol visibility has been changed.
Closes#54135
Fix Once perf regression
Because `call_once` is generic, but `is_completed` is not, we need
`#[inline]` annotation to allow LLVM to inline `is_completed` into
`call_once` in downstream crates.
cc https://github.com/rust-lang/rust/pull/53027/files#r221418859
Because `call_once` is generic, but `is_completed` is not, we need
`#[inline]` annotation to allow LLVM to inline `is_completed` into
`call_once` in downstream crates.
Switch wasm math symbols to their original names
The names `Math_*` were given to help undefined symbol messages indicate how to
implement them, but these are all implemented in compiler-rt now so there's no
need to rename them! This change should make it so wasm binaries by default, no
matter the math symbols used, will not have unresolved symbols.
Fix `thread` `park`/`unpark` synchronization
Previously the code below would not be guaranteed to exit when the
second unpark took the `return, // already unparked` path because there
was no write to synchronize with a read in `park`.
EDIT: doesn't actually require third thread
```
use std::sync::atomic::{AtomicBool, Ordering};
use std:🧵:{current, spawn, park};
static FLAG: AtomicBool = AtomicBool::new(false);
fn main() {
let thread_0 = current();
spawn(move || {
thread_0.unpark();
FLAG.store(true, Ordering::Relaxed);
thread_0.unpark();
});
while !FLAG.load(Ordering::Relaxed) {
park();
}
}
```
I have some other ideas on how to improve the performance of `park` and `unpark` using fences, avoiding any atomic RMW when the state is already `NOTIFIED`, and also how to avoid calling `notify_one` without the mutex locked. But I need to write some micro benchmarks first, so I'll submit those changes at a later date if they prove to be faster.
Fixes https://github.com/rust-lang/rust/issues/53366 I hope.
Update to a new pinning API.
~~Blocked on #53843 because of method resolution problems with new pin type.~~
@r? @cramertj
cc @RalfJung @pythonesque anyone interested in #49150
OsStr: Document that it's not NUL terminated
I somehow got confused into thinking this was the case, but
it's definitely not. Let's help the common case of people who
have an `OsStr` and need to call e.g. Unix APIs.
Add doc for impl From for Addr
As part of issue #51430 (cc @skade).
The impl is very simple, let me know if we need to go into any details.
Additionally, I added `#[inline]` for the conversion method, let me know if it is un-necessary or might break something.
I somehow got confused into thinking this was the case, but
it's definitely not. Let's help the common case of people who
have an `OsStr` and need to call e.g. Unix APIs.
Improve output if no_lookup_host_duplicates test fails
If the test fails, output the offending addresses and a helpful error message.
Also slightly improve legibility of the preceding line that puts the addresses
into a HashMap.
fix some uses of pointer intrinsics with invalid pointers
[Found by miri](https://github.com/solson/miri/pull/446):
* `Vec::into_iter` calls `ptr::read` (and the underlying `copy_nonoverlapping`) with an unaligned pointer to a ZST. [According to LLVM devs](https://bugs.llvm.org/show_bug.cgi?id=38583), this is UB because it contradicts the metadata we are attaching to that pointer.
* `HashMap` creation calls `ptr:.write_bytes` on a NULL pointer with a count of 0. This is likely not currently UB *currently*, but it violates the rules we are setting in https://github.com/rust-lang/rust/pull/53783, and we might want to exploit those rules later (e.g. with more `nonnull` attributes for LLVM).
Probably what `HashMap` really should do is use `NonNull::dangling()` instead of 0 for the empty case, but that would require a more careful analysis of the code.
It seems like ideally, we should do a review of usage of such intrinsics all over libstd to ensure that they use valid pointers even when the size is 0. Is it worth opening an issue for that?
The names `Math_*` were given to help undefined symbol messages indicate how to
implement them, but these are all implemented in compiler-rt now so there's no
need to rename them! This change should make it so wasm binaries by default, no
matter the math symbols used, will not have unresolved symbols.
If the test fails, output the offending addresses and a helpful error message.
Also slightly improve legibility of the preceding line that puts the addresses
into a HashMap.
re-mark the never docs as unstable
Fixes https://github.com/rust-lang/rust/issues/54198
This stability attribute was removed in https://github.com/rust-lang/rust/pull/47630, but not replaced with a `#[stable]` attribute, and when https://github.com/rust-lang/rust/pull/50121 reverted that stabilization, it didn't set the docs back to unstable. I'm concerned as to why it was allowed to not have the stability attribute at all, but at least this can put it back.
I'm nominating this for beta backport because it's a really small change, and right now our docs are in an awkward position where the `!` type is technically unstable to use, but the docs don't say so the same way any other library feature would. (And this is also the case *on stable* now, but i'm not suggesting a stable backport for a docs fix.)
Fix the stable release of os_str_str_ref_eq
This was added and stabilized in commit 02503029b8, but while that
claimed to be for 1.28.0, it didn't actually make it until 1.29.0.
Fixes#54195.
Rollup of 11 pull requests
Successful merges:
- #53371 (Do not emit E0277 on incorrect tuple destructured binding)
- #53829 (Add rustc SHA to released DWARF debuginfo)
- #53950 (Allow for opting out of ThinLTO and clean up LTO related cli flag handling.)
- #53976 (Replace unwrap calls in example by expect)
- #54070 (Add Error::description soft-deprecation to RELEASES)
- #54076 (miri loop detector hashing)
- #54119 (Add some unit tests for find_best_match_for_name)
- #54147 (Add a test that tries to modify static memory at compile-time)
- #54150 (Updated 1.29 release notes with --document-private-items flag)
- #54163 (Update stage 0 to latest beta)
- #54170 (COMPILER_TESTS.md has been moved)
Add rustc SHA to released DWARF debuginfo
This commit updates the debuginfo that is encoded in all of our released
artifacts by default. Currently it has paths like `/checkout/src/...` but these
are a little inconsistent and have changed over time. This commit instead
attempts to actually define the file paths in our debuginfo to be consistent
between releases.
All debuginfo paths are now intended to be `/rustc/$sha` where `$sha` is the git
sha of the released compiler. Sub-paths are all paths into the git repo at that
`$sha`.
Add target thumbv7a-pc-windows-msvc
This is an early draft of support for Windows/ARM. To test it,
1. Install Visual Studio 2017 and Windows SDK version 17134.
1. Obtain alexcrichton/xz2-rs#35, rust-lang-nursery/compiler-builtins#256, and the fix for [LLVM Bug 38620](https://bugs.llvm.org/show_bug.cgi?id=38620).
2. Open a command prompt and run
```
set CC_thumbv7a-pc-windows-msvc=C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.11.25503\bin\HostX64\arm\CL.exe
set CFLAGS_thumbv7a-pc-windows-msvc=/D_ARM_WINAPI_PARTITION_DESKTOP_SDK_AVAILABLE=1 /nologo
c:\python27\python.exe x.py build --host x86_64-pc-windows-msvc --build x86_64-pc-windows-msvc --target thumbv7a-pc-windows-msvc
```
It will build the stage 2 compiler, but fail building stage 2 test. To build an executable targeting windows/arm,
1. Copy `build\x86_64-pc-windows-msvc\stage0\bin\cargo.exe` to `build\x86_64-pc-windows-msvc\stage2\bin`
2. Open a command prompt and run
```
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Auxiliary\Build\vcvars64.bat"
set PATH=build\x86_64-pc-windows-msvc\stage2\bin;%PATH%
cargo new hello
cd hello
cargo build --target thumbv7a-pc-windows-msvc –release
```
Copy target\thumbv7a-pc-windows-msvc\release\hello.exe to your platform and run.
There are a number of open issues that I'm hoping to get help with:
- Error when compiling the `test` crate: `error: cannot link together two panic runtimes: panic_abort and panic_unwind`
- Warnings when building the compiler_builtins crate: `warning: cl : Command line warning D9002 : ignoring unknown option '-fvisibility=hidden'`. It looks like the build system is passing GCC-style flags to MSVC.
- How to specify the LIBPATH entries for ARM. Right now they are hardcoded as absolute paths in the target spec.
This pull request depends on
- alexcrichton/xz2-rs#35 - update vcxproj to Visual Studio 2017
- rust-lang-nursery/compiler-builtins#256 - fix compile errors when building for windows/arm
- [Bug 38620 - ARM: Incorrect COFF relocation type for thumb bl instruction](https://bugs.llvm.org/show_bug.cgi?id=38620)
This PR updates #52659
Previously the code below would not be guaranteed to exit when the first
spawned thread took the `return, // already unparked` path because there
was no write to synchronize with a read in `park`.
```
use std::sync::atomic::{AtomicBool, Ordering};
use std:🧵:{current, spawn, park};
static FLAG: AtomicBool = AtomicBool::new(false);
fn main() {
let thread_0 = current();
spawn(move || {
FLAG.store(true, Ordering::Relaxed);
thread_0.unpark();
});
let thread_0 = current();
spawn(move || {
thread_0.unpark();
});
while !FLAG.load(Ordering::Relaxed) {
park();
}
}
```
Fix typos in libstd hash map
modified growth algo description to read "the first table overflows into the second, and the second into the first." plus smaller typos
Update documentation for fill_buf in std::io::BufRead
Brings the documentation in line with the BufReader implementation.
Fixes#48022.
This is my first PR, and I think the `E-easy` label is very cool, as so is the practice of describing the fix but leaving it for someone else; it really makes it a lot less intimidating to get started with something!
This commit updates the debuginfo that is encoded in all of our released
artifacts by default. Currently it has paths like `/checkout/src/...` but these
are a little inconsistent and have changed over time. This commit instead
attempts to actually define the file paths in our debuginfo to be consistent
between releases.
All debuginfo paths are now intended to be `/rustc/$sha` where `$sha` is the git
sha of the released compiler. Sub-paths are all paths into the git repo at that
`$sha`.
