It looks like compiler-rt has a cmake build sytem inside its source, but I have
been unable to figure out how to use it and actually build the right library.
For now this commit hard-wires MSVC-targeting builds of libcompiler-rt to
continue using `make` as the primary bulid system, but some frobbing of the
flags are necessary to ensure that the right compiler is used.
Currently the MSVC compilers don't have any cross prefixes and we're only able
to make an MSVC compiler with a cross compile, so just avoid this logic on msvc
for now.
We have a number of support C/C++ files in Rust that we link into the standard
library and other various locations, and these all need to be built with cl.exe
instead of gcc.exe when targeting MSVC. This commit adds helper macros for this
functionality to use different sets of programs/flags/invocations on MSVC than
on GNU-like platforms.
This commit modifies the makefiles to enable building LLVM with cmake and Visual
Studio to generate an LLVM that targets MSVC. Rust's configure script requires
cmake to be installed when targeting MSVC and will configure LLVM with cmake
instead of the normal `./configure` script LLVM provides. The build will then
run cmake to execute the build instead of the normal `make`.
Currently `make clean-llvm` isn't supported on MSVC as I can't figure out how to
run a "clean" target for the Visual Studio files.
This commit starts to add MSVC support to the ./configure script to enable the
build system to detect and build an MSVC target with the cl.exe compiler and
toolchain. The primary change here is a large sanity check when an MSVC target
is requested (and currently only `x86_64-pc-windows-msvc` is recognized).
When building an MSVC target, the configure script either requires the
`--msvc-root` argument or for `cl.exe` to be in `PATH`. It also requires that if
in the path `cl.exe` is the 64-bit version of the compiler.
Once detected the configure script will run the `vcvarsall.bat` script provided
by Visual Studio to learn about the `INCLUDE` and `LIB` variables needed by the
`cl.exe` compiler to run (the default include/lib paths for the
compiler/linker). These variables are then reexported when running `make` to
ensure that our own compiles are running the same toolchain.
The purpose of this detection and environment variable scraping is to avoid
requiring the build itself to be run inside of a `cmd.exe` shell but rather
allow it to run in the currently expected MinGW/MSYS shell.
We use a script called `mklldeps.py` to run `llvm-config` to generate a list
of LLVM libraries and native dependencies needed by LLVM, but all cross-compiled
LLVM builds were using the *host triple's* `llvm-config` instead of the
*target's* `llvm-config`. This commit alters this to require the right
`llvmdeps.rs` to be generated which will run the correct `llvm-config`.
Previously libmorestack.a and libcompiler-rt.a were installed, but link.exe
looks for morestack.lib and compiler-rt.lib by default, so we need to install
these with the correct name
* Detect the #define _MSC_VER in addition to __WIN32__
* Don't include valgrind.h for windows
* Remove unused `rust_valgrind_stack_{un,}register` functions
* Add stub definition for `rust_running_on_valgrind` for windows
* Conditionally define `rust_dbg_extern_empty_struct` as empty structures are
not allowed by cl.exe apparently.
I think I didn't run tests properly - my second call to
select_all_obligations_or_error has made 3 tests fail. However, this is
just an error message change - integer fallback never worked with casts.
This should hopefully fix all cast-related ICEs once and for all.
I managed to make diagnostics hate me and give me spurious "decoder error"
- removing $build/tmp/extended-errors seems to fix it.
This adds strictly more information to the source files and reduces the need for customized tooling to render the book. (While this should not change the output of _rustbook_, it is very useful when rendering the sources with external tools like Pandoc.)
This only adds the language marker to "first level" code blocks (and not to code blocks in comments inside of code examples).
r? @steveklabnik
Currently the table of contents for `rustbook` doesn't signify which page you are on.
This PR adds an 'active' class to the link for the current page, and defines the CSS rule for that class to make the link underlined and bold.
Not sure about two things:
1) Is `current_page` is a good name for the function parameter? At first I thought `current_item` would be good, but then in the `walk_item` function, you'd have `item` and `current_item`.
2) For the CSS, is both bold and underline too much? At first I had it just be underlined, but that's also how the links look when they're hovered over.
The source code snippet uses `"whatever".as_bytes()` but the compilation error message uses `b"whatever"`. Both should be consistent with each other.
r? @steveklabnik
Minor tweak: the text explaining the Borrow trait talks about slices, but the example immediately following just uses a simple reference; there are no slices involved.
r? @steveklabnik
When taking the address of an unsized field we generate a rvalue datum
for the field and then convert it to an lvalue datum. At that point,
cleanup is scheduled for the field, leading to multiple drop calls.
The problem is that we generate an rvalue datum for the field, since the
pointer does not own the data and there's already cleanup scheduled
elsewhere by the true owner. Instead, an lvalue datum must be created.
Thanks to @eddyb for identifying the underlying cause and suggesting the
correct fix.
Fixes#25549Fixes#25515
Prefer String::from over from_str; String::from_str is unstable while
String::from is stable. Promote the latter by using it in examples.
Simply migrating unstable function to the closest alternative.
Debug overflow checks for arithmetic negation landed in #24500, at which time
the `abs` method on signed integers was changed to using `wrapping_neg` to
ensure that the function never panicked. This implied that `abs` of `INT_MIN`
would return `INT_MIN`, another negative value. When this change was back-ported
to beta, however, in #24708, the `wrapping_neg` function had not yet been
backported, so the implementation was changed in #24785 to `!self + 1`. This
change had the unintended side effect of enabling debug overflow checks for the
`abs` function. Consequently, the current state of affairs is that the beta
branch checks for overflow in debug mode for `abs` and the nightly branch does
not.
This commit alters the behavior of nightly to have `abs` always check for
overflow in debug mode. This change is more consistent with the way the standard
library treats overflow as well, and it is also not a breaking change as it's
what the beta branch currently does (albeit if by accident).
cc #25378
Debug overflow checks for arithmetic negation landed in #24500, at which time
the `abs` method on signed integers was changed to using `wrapping_neg` to
ensure that the function never panicked. This implied that `abs` of `INT_MIN`
would return `INT_MIN`, another negative value. When this change was back-ported
to beta, however, in #24708, the `wrapping_neg` function had not yet been
backported, so the implementation was changed in #24785 to `!self + 1`. This
change had the unintended side effect of enabling debug overflow checks for the
`abs` function. Consequently, the current state of affairs is that the beta
branch checks for overflow in debug mode for `abs` and the nightly branch does
not.
This commit alters the behavior of nightly to have `abs` always check for
overflow in debug mode. This change is more consistent with the way the standard
library treats overflow as well, and it is also not a breaking change as it's
what the beta branch currently does (albeit if by accident).
cc #25378
