The tupling only happens for actual closures, same for the untupling.
The only code that actually sees the tupled types is some debugging
output for which it is actually rather confusing to have the types
tupled, because neither the function signature in Rust nor the
function signature for LLVM has them tupled.
This is a simple addition, shouldn't change behavior.
Fixes#26704
I don't know if the coercion for `Rc` is tested, if it is this probably needs the same test with `Weak`.
This doesn't add a test for the main problem in #8640 since it seems that
was already fixed (including a test) in PR https://github.com/rust-lang/rust/pull/19522. This just adds a test
for a program mentioned in the comments that used to erroneously compile.
Closes#8640.
This patch implements the next chunk of flattening out the type checking context. In a series of patches I moved around the necessary state and logic in order to delete the `Typer` and `ClosureTyper` traits. My next goal is to clean the interfaces and start to move the normalization code behind them.
r? @nrc I hope my PR is coherent, doing this too late at night ;)
This was added after Windows 7 SP1, so it's not always available. Instead use
the `SetHandleInformation` function to flag a socket as not inheritable. This is
not atomic with respect to creating new processes, but it mirrors what Unix does
with respect to possibly using the atomic option in the future.
Closes#26543
This doesn't add a test for the main problem in #8640 since it seems that
was already fixed (including a test) in PR #19522. This just adds a test
for a program mentioned in the comments that used to erroneously compile.
Closes#8640.
Just like the original article our Windows TLS support is based on predicted,
this symbol must be linked in on MSVC to pull in the necessary support for TLS
variables. This commit fixes a number of unit tests which require that TLS
destructors are run.
This commit alters the compiler to no longer "just run link.exe" but instead
probe the system's registry to find where the linker is located. The default
library search path (normally found through LIB) is also found through the
registry. This also brings us in line with the default behavior of Clang, and
much of the logic of where to look for information is copied over from Clang as
well. Finally, this commit removes the makefile logic for updating the
environment variables for the compiler, except for stage0 where it's still
necessary.
The motivation for this change is rooted in two positions:
* Not having to set up these environment variables is much less hassle both for
the bootstrap and for running the compiler itself. This means that the
compiler can be run outside of VS shells and be run inside of cmd.exe or a
MSYS shell.
* When dealing with cross compilation, there's not actually a set of environment
variables that can be set for the compiler. This means, for example, if a
Cargo compilation is targeting 32-bit from 64-bit you can't actually set up
one set of environment variables. Having the compiler deal with the logic
instead is generally much more convenient!
This commit turns on landing pads for MSVC by default, which means that we'll
now be running cleanups for values on the stack when an exception is thrown.
This commit "fixes" the previously seen LLVM abort by attaching the `noinline`
attribute to all generated drop glue to prevent landing pads from being inlined
into other landing pads.
The performance of MSVC is highly likely to decrease from this commit, but there
are various routes we can taken in the future if this ends up staying for quite
a while, such as generating a shim function only called from landing pads which
calls the actual drop glue, and this shim is marked noinline.
For now, however, this patch enables MSVC to successfully bootstrap itself!
Like explained in #26016, typing `?` had no effect with non-english keyboard layouts in the docs.
This patch seems to resolve this issue, **tested with AZERTY keyboard in Google Chrome and Firefox**. I haven't tested it with more exotic keyboard layouts or with other browsers though.
This code is based on the information found on: http://javascript.info/tutorial/keyboard-events
**More specifically:**
> The only event which reliably provides the character is keypress.
**And**
>```
// event.type must be keypress
function getChar(event) {
if (event.which == null) {
return String.fromCharCode(event.keyCode) // IE
} else if (event.which!=0 && event.charCode!=0) {
return String.fromCharCode(event.which) // the rest
} else {
return null // special key
}
}
```
`?` and `S` work, `escape` however does not (on an Azerty keyboard).
It would be good if some people could test it with other browsers and keyboard layouts: http://www.mathieudavid.org/test/rustdoc/std/index.html
**Edit:**
- swedish layout works on Firefox and Chromium
- french (azerty) mac layout works on Safari
This was added after Windows 7 SP1, so it's not always available. Instead use
the `SetHandleInformation` function to flag a socket as not inheritable. This is
not atomic with respect to creating new processes, but it mirrors what Unix does
with respect to possibly using the atomic option in the future.
Closes#26543
