search

rust-lang / rfcs

RFCs for changes to Rust
https://rust-lang.github.io/rfcs/
Apache License 2.0
5.89k stars 1.56k forks source link

Rust, Windows, and MSVC #1061

Closed retep998 closed 4 years ago

retep998 commented 9 years ago

High priority tasks

Lower priority tasks

Completed tasks

Wishlist

https://github.com/rust-lang/rust/issues/1768

briansmith commented 9 years ago

Maybe I am misunderstanding, but I think most projects that are building using the Rust MSVC toolchain will want to use msvcrt for math and other standard library functions like malloc and memcpy. In particular, lots of these projects will be a mix of Rust and C/C++ code and the C/C++ code will almost definitely only work with msvcrt. For example, for Rust code within Firefox, the right thing to do is use msvcrt, and that's also the case with my projects. IMO, it is only worth avoid msvcrt once it is also possible to build things for the MSVC ABI without needing link.exe, which is a ways off, IIUC.

In other words, regardless if there is a configuration for using OpenLibm and other alternatives, there should be a way to avoid using OpenLibm and use msvcrt instead.

retep998 commented 9 years ago

Perhaps using a design similar to https://github.com/rust-lang/rfcs/pull/1183 we could have a pair of crates, or maybe we could just expand rlibc, and it would provide a pure Rust entry point and openlibm for the math functions. It would also probably need to be used in combination with the system allocator crate instead of jemalloc as well as not linking to msvcrt.

tkelman commented 9 years ago

There are some applications where you'd want to use say Intel's libm implementation instead of glibc or msvcrt, so trying to make things more pluggable for libm functions would be useful.

abonander commented 9 years ago

@retep998 Can dllexport be checked off after rust-lang/rust#27416 (which closed rust-lang/rust#7196)?

ruffianeo commented 9 years ago

If there is any relevance to GPL in the context of making rust usable on other operating systems (e.g. Windows, proprietary embedded OS, such as QNX), I strongly suggest to switch Rust to another open source license which is less restrictive. E.g. BSD style licenses. In the long run, it will help to get RUST accepted and any formal roadblocks such as licences which block progress on making Rust viable on multiple platforms should be avoided. This remark refers to the small GPL discussion above.

Manishearth commented 9 years ago

Rust uses MIT/Apache. Not sure how GPL is relevant here.

ruffianeo commented 9 years ago

While this topic is focused on making good choices to make Rust usable on Windows platforms (which these days more than ever before is a moving target, given the shift to Universal runtime etc.), I feel urged to point out that after having Rust working on Windows (and linux, which was the first target), there will come up the next OS to support and very likely also the bare metal scenarios. In that light, I feel, it could be beneficial if the mindset was not "next OS" but "how to factor rust technology such, that its architecture allows for the other relevant scenarios for a system programming language". It could save a lot of work and quite some future changes of the tool chain.

tshepang commented 9 years ago

Can you give an example @ruffianeo. I don't understand.

ruffianeo commented 9 years ago

I will try. Above, there is the topic of whether some libm or windows standard lib math functions should be used, right? With the mindset of "strategic refactoring", the question might arise, whether or not any of both discussed options would hold. How would the answer likely be for a bare - metal system? Would that bare-metal solution also allow for a windows-based solution? In the end, it might possibly be concluded that those math functions would better be moved out of the "system dependencies" scope entirely. Also topics like msys would be viewed in a new light. How would the architecture have to look like for a e.g. T-engine system where static libs get linked at the target after download (in development mode) and Rust would have to cope with the fact, that it is not holding any options in the link-business at all on that system? Would not - in that light - any attempt to treat the windows platform as a badly behaving not-quite-unix system look less adequate?

So the basic idea to approach with a different mind set could be encouraged by widening the context of the effort. Create a list of 4-5 very very different usage-scenarios and verify any possible solution option for windows port against each of them. This would be about the basic idea behind my previous comment. Hope I found the right words, if not, I apologize.

There is the "no architecture before 3 implementations" - rule, many will be aware of. If we count Linux as first implementation, windows as the second, it might possibly be that my suggestion might be premature.

Diggsey commented 9 years ago

@ruffianeo This is not a problem with rust's architecture, the problem is that windows (pre-universal-runtime) does not have an up-to-date C standard library which is (uncontroversially) compatible with the GPL: this is not a problem for rust itself, because rust isn't GPL, but it is a problem if you want to write GPL code in rust, which will run on windows.

This is a problem for all compilers which depend on the C standard library for their runtime, including C and C++ compilers. The currently "solution" (which all GPL code running on windows uses) is to use MSVCRT.DLL, which is not kept up-to-date, and shouldn't really be used by applications, but counts as a core component of the OS, for which GPL permits an excemption.

Now that the universal runtime exists, this is effectively solved as soon as rust gets support for it: GPL code can link to the universal runtime, which also counts as a core OS component, and everyone is happy! As for other OSes, AFAIK, there are no other OSes which have non-GPL-compatible C runtime libraries, so there's no issue.

tkelman commented 9 years ago

The ucrt isn't deployed by default through windows update on win7 or win8 yet, is it? So users would still need to manually install a separate redistributable which could not be packaged together with a piece of gpl software? Thats the big advantage of msvcrt.dll, and many places where it is out of date have replacements in mingw-w64 libgcc.

kuza55 commented 9 years ago

My apologies if this is off-topic or this is already supported, I couldn't really find any info.

Is there any plan to support COM in Rust?

I would like to use Rust to write a Browser Helper Object, which would need to be its own COM object and would need to interact with a pile of IE's COM objects.

retep998 commented 9 years ago

Implementing COM interfaces yourself in Rust is very difficult, but can be done. One of my goals is to write a library that assists in implementing COM interfaces (in particular the hellish thing that is QueryInterface).

If all you want to do is use existing COM stuff, then you already can already do that really easily using just winapi.

Diggsey commented 9 years ago

@tkelman

The ucrt isn't deployed by default through windows update on win7 or win8 yet, is it? So users would still need to manually install a separate redistributable which could not be packaged together with a piece of gpl software?

That only matters if there's any ambiguity about whether it's a core system component: that mattered for the versioned MSVCRT, because microsoft have never claimed it to be a core system component, and it doesn't come preinstalled on windows: having to package it in would be enough to suggest that it's not a core system component, and would arguably violate the GPL. However, they've explicitly said that the universal CRT is a core system component, and so whether you have to distribute it yourself or not, there's no ambiguity.

Regardless, I think it's possible to tell windows to automatically install the universal CRT via windows update when your application is installed, by listing it as a dependency, so there's actually no need to package them together.

alexchandel commented 8 years ago

@Diggsey That doesn't help installations where there is no internet connection, a common sight in mission critical systems (which horrifyingly run windows)

@retep998 When will invoking link.exe make it into the nightlies? Currently --target i686-pc-windows-gnu -C linker=link.exe fails, and just sends it GCC arguments.

Diggsey commented 8 years ago

@alexchandel If there's no internet connection, then 1) you can still use windows update, it supports installing software offline 2) you're also able to distribute the universal CRT with the application, since it still counts as a core system component.

retep998 commented 8 years ago

@alexchandel There is currently an entirely separate target triple for making Rust use the MSVC toolchain instead of MinGW. x86_64-pc-windows-msvc and i686-pc-windows-msvc. Nightlies for both are available (although not linked on the download page).

alexchandel commented 8 years ago

@briansmith #1183 added allocator selection, and I imagine something similar will happen for math functions (libmath_system and libmath_openlibm, interfaced by libmath). And memcpy isn't in msvcrt anyway so that doesn't matter. Moreover, using msvcrt has absolutely nothing to do with using link.exe; you can link against msvcrt.dll with LLD, and you can link directly to ntdll.dll with link.exe. And we already match the "MSVC ABI", in that MSVC code can safely call extern'd Rust symbols.

@retep998 I did see that, but it sends bad options to LLD, and I can't get it to work with VC6 (which unlike newer ones like VS2015, actually can be linked by LLD): it tries to link the nonexistent userenv.lib.

@Diggsey Actually I'm having trouble statically linking the crt with i686-pc-windows-msvc; it defaults to dynamically linking msvcrt even though I didn't specify -C prefer-dynamic, and rustc doesn't accept a -C prefer-static to prefer static system libraries.

retep998 commented 8 years ago

@alexchandel It needs userenv.lib for one of the functions in libstd and that import library is provided by the Windows SDK. While -gnu bundles the needed system import libraries, -msvc does not and instead depends on having a valid Windows SDK installed. Currently Rust is only designed to work with the Windows 8.1 SDK or the Windows 10 SDK although it might work with earlier versions. Also not Rust's fault if LLD is unable to handle linking to things.

memcpy and friends are definitely provided by the CRT, at least the versioned CRT's that MSVC uses do. Maybe you're looking at msvcrt.dll which is not the CRT you're supposed to use but MinGW uses it anyway.

Regarding statically linking msvcrt, on Windows you cannot choose whether to link a native library statically or dynamically. You just link an import library and that library either happens to have symbols which are linked statically and/or imports which are linked dynamically. In order to link to a native library differently you have to pass an entirely different import library to the linker which has the symbols in the way you want. On Windows -C prefer-dynamic only applies to Rust dependencies, because there's simply no way to make it work with non-Rust libraries. To statically link the CRT you just have to link to libcmt.lib instead of msvcrt.lib. Currently liblibc specifies #[link(name = "msvcrt")] which I think is a poor idea and needs to be replaced with rustc performing the logic of choosing which CRT to link to.

One hacky workaround I found for that is if I'm using the universal CRT (aka with the Windows 10 SDK), msvcrt.lib and libcmt.lib now only handle the entry point which then implicitly links in the relevant UCRT libraries. If I use a custom entry point via passing /ENTRY to the linker, the UCRT is not implicitly linked by the CRT entry point and I can choose to link the static version of the UCRT instead. Note that skipping the CRT entry point is okay only if you're writing pure Rust which doesn't use things from the CRT that depend on the CRT runtime being initialized.

alexchandel commented 8 years ago

@retep998 Disassembling the msvcrt I have just reveals a jump into ntdll.dll, so maybe.

Also not Rust's fault if LLD is unable to handle linking to things.

True, though we could be more compatible, but I'm more worried that it sends optimization options even when no optimization is requested: rust-lang/rust#29126

It needs userenv.lib for one of the functions in libstd and that import library is provided by the Windows SDK.

Which function? VC6 was before MS split the compiler/crt from what's currently in the Windows Kits.

Edit: improving cross-linking errors suggest it's _AddVectoredExceptionHandler@8 and _RtlCaptureContext@4. Any idea where those were before userenv.lib?

In order to link to a native library differently you have to pass an entirely different import library to the linker which has the symbols in the way you want.

I figured as much, I was just hoping there was a rustc flag I could use, but evidently not: #[link(name = "msvcrt")].

the universal CRT (aka with the Windows 10 SDK)

I really don't understand the layers of Microsoft SDKs/Windows SDKs/Windows Kits (and MS's changing its naming convention every year doesn't help), but say if I had VS2015 and linked against the UCRT (for a CRT) and the Windows 10 Kit's headers/libraries (for kernel32 & friends), would that run on XP? Is there some NT version macro I need to define? I didn't see a Windows XP Kit get installed, yet VS2015 claims it targets XP.

If I use a custom entry point via passing /ENTRY to the linker, the UCRT is not implicitly linked by the CRT entry point and I can choose to link the static version of the UCRT instead.

Is your entry point posted somewhere? My hack attempt at one worked for console IO, but segfaults if I try to draw a window (from Rust, no C present).

Note that skipping the CRT entry point is okay only if you're writing pure Rust which doesn't use things from the CRT that depend on the CRT runtime being initialized.

Assuming our libc dependency can be factored into some liballoc/libmath/libsystem/libstart fashion, it would be nice if rustc could detect whether it was safe to supply its own entry point. Linux doesn't really need libstart, and OSX's entry point is literally in libSystem.dylib these days, but for Windows and bare-metal some libstart would make sense.

retep998 commented 8 years ago

VC6 was before MS split the compiler/crt from what's currently in the Windows Kits.

VC6 is abysmally old, as in from 1998. I'm not sure why you need such an ancient setup considering LLVM has a minimum requirement of VS 2013 and is even removing support for running LLVM on XP. If you want to support such obscure setups, then you'd have to have rustc output a .obj and then manually invoke the linker yourself.

The function which needs userenv.lib is GetUserProfileDirectory.

Supporting XP is a matter of passing a special /SUBSYSTEM flag to the linker which tells it to output a PE which can run on XP. You still have to avoid referencing any symbols which don't exist on XP though. std mostly works on XP, although it'll currently panic if you try to use some functionality with regards to mutexes and locks on XP.

I haven't tested using a custom entry point with creating windows, I'll have to look into that more later.

retep998 commented 8 years ago

I just disassembled both msvcr120.dll and msvcrt.dll and both of them had a memcpy which was defined in terms of memmove which was not just a shim to some other DLL but had the full fancy implementation with the vectorized branches and whatnot.

retep998 commented 8 years ago

Regarding the universal CRT on Windows XP, it should entirely be possible to install the universal CRT on XP and then run programs that link against it on XP (so long as they passed the correct /SUBSYSTEM to the linker and don't reference symbols that don't exist on XP).

alexchandel commented 8 years ago

@retep998 Yeah it's quite possible this DLL is ancient, and unlike the others.

VC6 is the least common denominator, though it's only 17 years old. Sadly it still sees widespread use in certain areas, thanks to the fact that MS goes out of their way not to break it. I don't plan on compiling LLVM with it; I'm using it only for its libraries, because LLD is capable of cross-linking rustc output against it. But I'm trying with the Win10 ones again.

So it's possible to successfully link against missing symbols from Rust when targeting XP, using MS's currently supported libraries?

GetUserProfileDirectory hasn't given me trouble, just the two I mentioned. But it's possible they're just not in VC6's kernel32.lib.

Update: so, linking rustc's output with VC6's msvcrt.dll and Win10's kernel32.lib & friends worked and produces an executable that runs on XP & win10. I'm running this on OS X 10.10, and link.exe is just a symlink to lld, so if would could fix rust-lang/rust#29126 (as in just pass "/OPT:REF" "/OPT:ICF" instead of "/OPT:REF,ICF") then that would mean rustc + lld can natively cross-compile (at least something) from OSX to Windows.

retep998 commented 8 years ago

So it's possible to successfully link against missing symbols from Rust when targeting XP, using MS's currently supported libraries?

You can successfully link against any symbol so long as some import library exports it. The program will still crash at runtime if the specified DLL doesn't exist or it doesn't have that symbol. Telling link to target XP via /SUBSYSTEM:CONSOLE,5.01 or /SUBSYSTEM:CONSOLE,5.02 just tells it to not use newer PE features which XP doesn't support. You can still reference symbols that XP doesn't have and crash at runtime. Rust's libstd does not link against any symbols which XP does not have, however it still depends on some symbols for some functionality, so it dynamically loads them using LoadLibrary and panics or resorts to a fallback implementation if it fails to load the symbol.

The recommended way to cross-compile to Windows is using the MinGW toolchain as several people have done it successfully, although it is poorly documented. Feel free to talk to @steveklabnik about getting better documentation on the cross-compiling fiasco.

Diggsey commented 8 years ago

@alexchandel

@Diggsey Actually I'm having trouble statically linking the crt with i686-pc-windows-msvc; it defaults to dynamically linking msvcrt even though I didn't specify -C prefer-dynamic, and rustc doesn't accept a -C prefer-static to prefer static system libraries.

You can distribute the universal CRT without statically linking: Microsoft recently caved to popular demand and added support for distributing the universal CRT in DLL form alongside your application, in addition to the other methods (windows update or separate UCRT installer). The only requirement is that the DLLs be in the same directory as your executable.

alexchandel commented 8 years ago

@retep998 I've never had success crossing from OSX to 32bit windows via MinGW. The lack of SEH support (I don't think it's acceptable to pass around a libgcc_s_dw2-1.dll with your executable) combined with people's love for exceptions gives me segfaults, plus I dislike the idea of installing a binutils for every target I need. Moreover, Rust's i686-pc-windows-gnu target ships a Windows binary for gcc.exe which can't be natively run on OSX, and LLD doesn't yet play nicely with MinGW's libraries (this week it's giving the error: -aligncomm:_hInst,2 is not allowed in .drectve).

But this is working well. CPATH="$HOME/i686-pc-windows-msvc-w10/include:$HOME/i686-pc-windows-msvc-vc6/include" clang -target i686-pc-windows-msvc -c ... and LIB="$HOME/i686-pc-windows-msvc-w10/lib;$HOME/i686-pc-windows-msvc-vc6/lib" link.exe ... (where link.exe is a symlink to LLD) can compile a C Win32 GUI application, and the latter LLD invocation can link a console-based Rust program that grabs screenshots and sends keyboard/mouse events.

The trouble was really figuring out which of the infinite permutations would work. I didn't try, but linking against UCRT instead of VC6 may work too. It's too bad Microsoft can't just provide a minimalist zip file that we could redistribute for cross-compiling: the VS2015 download I extracted the Win10 libraries & headers from was multiple gigabytes of bloat.

alexchandel commented 8 years ago

@Diggsey That's pretty amusing. They deserve all the trouble they're enduring and more for not having included a stable C library in their os 30 years ago. It's a "code smell" to me to deliver shared objects alongside executables, especially when they're things like the standard C library, but I managed to link against the evil msvcrt.dll instead via VC6. Although I suspect that manually invoking the linker would let me statically link against the UCRT...

Diggsey commented 8 years ago

@alexchandel

They deserve all the trouble they're enduring and more for not having included a stable C library in their os 30 years ago.

Windows has always included a stable C library, the problems stem from the fact that it must maintain binary compatibility across all versions of windows, and that it combines both the compiler runtime and the language runtime in one.

The compiler runtime must, necessarily, be updated for each new version of the compiler. That means the entire runtime must be versioned according to the compiler version, so frequently you need a runtime that is newer than the version of windows on which you are running. This means you can't rely on it being pre-installed, and that is grounds for discounting it as a "core system component", which makes it incompatible with the GPL.

The UCRT solves the problem by splitting the compiler runtime and C runtime into separate DLLs, which allows the C runtime part to be the same regardless of the compiler version.

Linux doesn't have the problem only because it doesn't attempt to maintain binary compatibility for programs which rely on shared libraries: you can't just copy a program from one linux machine to another and have any guarantee of it working, unless absolutely everything is statically linked and the kernel versions match. For platforms where most software is distributed only in binary form, this obviously can't work.

alexchandel commented 8 years ago

@Diggsey Then it is not stable. It is an incorrect presumption that the compiler runtime "must, necessarily, be updated for each new version". I can use an (x86) crt1 Mach-O crosscompiled for OS X 10.1 with El Capitan's libSystem and a bleeding edge 3.8trunk clang with absolutely no problems whatsoever. In fact I just linked a Rust program with it.

Linux doesn't have the problem only because it doesn't attempt to maintain binary compatibility for programs which rely on shared libraries: you can't just copy a program from one linux machine to another and have any guarantee of it working, unless Moderately everything is statically linked and the kernel versions match.

This is so false that I don't even. Linux famously does not break userspace, so kernel versions aren't generally a problem. Moreover, except for rare cases, glibc maintains backwards compatibility. As does OS X, which also guarantees libSystem compatibility, and strives for (but does not guarantee) syscall compatibility. You can play the ancient x86 build of StarCraft, linked against 10.2's libSystem.dylib, on 10.11. It actually runs better than the wine version. Obviously there is no guarantee, to use your word, if there are missing sos or if Apple decided not to ship some dylib anymore. But you are quite mistaken to assume that other platforms are as broken as Windows.

Diggsey commented 8 years ago

@alexchandel

Then it is not stable. It is an incorrect presumption that the compiler runtime "must, necessarily, be updated for each new version".

The compiler runtime is completely different from the C runtime... Obviously using an old CRT will work, that's the whole point: the CRT has a stable API, the compiler runtime does not. Windows does have a stable C runtime, because as long as you only use the C runtime parts (of any version of msvcrt) it will continue to work forever. The part that changes is the compiler runtime.

This is so false that I don't even.

Obviously there is no guarantee.

Make up your mind, either there is a guarantee or there's not. If there isn't a guarantee, than what I said is true. Windows does provide backwards compatibility guarantees, to a fault.

You seem to be missing the important distinction between should work, and does work.

alexchandel commented 8 years ago

@Diggsey

Make up your mind, either there is a guarantee or there's not.

If you examine the rest of that sentence, instead of cutting it out for cute rhetorical purposes like "Make up your mind", you'd see I'm referring to dylibs that are not guaranteed, unlike libSystem. libSystem is guaranteed, and does work. (And consulting Apple's dev site suggests that they don't remove dylibs after all; just the headers so new apps can't be compiled against them.) The point stands.

The compiler runtime is completely different from the C runtime...

Wrong for clang/libSystem. There are (non-MS) platforms that do not make these distinctions, and the existence of the former demonstrates that the latter should not be necessary. Binary compatibility does not have to be an issue, and distinguishing "compiler runtimes" from other stable components is meaningless or inconsequential on platforms that don't suffer from the nuanced design flaws of Windows. Not everyone is forced to accept MS's terminology, nor their justifications for instability.

And just to hammer the point home (and because you clearly misunderstood this), the functions in Apple's crt0/crt1 correspond to what MS calls the "compiler runtime", not what MS calls the "CRT" which corresponds to (part of) Apple's libSystem: I compiled an el cap binary against the current "CRT" with a HEAD compiler and a Cretaceous era "compiler runtime", because these libraries are permanently stable on non-broken platforms.

retep998 commented 8 years ago

It's worth noting that crt0.o is statically linked and so there's no stability concerns there. Microsoft puts some of the stuff which would typically be in crt0.o in a DLL instead, and as such that ends up having to be versioned with each compiler version. If Microsoft didn't version those bits, then they'd be forced to never change them and maintain them backwards compatibly for a very long time. Look at these functions that are in vcruntime140.dll. Do they look like the kind of things you'd want to keep stable?

__AdjustPointer
__BuildCatchObject
__BuildCatchObjectHelper
__C_specific_handler
__C_specific_handler_noexcept
_CreateFrameInfo
__current_exception
__current_exception_context
__CxxDetectRethrow
__CxxExceptionFilter
__CxxFrameHandler
__CxxFrameHandler2
__CxxFrameHandler3
__CxxQueryExceptionSize
__CxxRegisterExceptionObject
_CxxThrowException
__CxxUnregisterExceptionObject
__DestructExceptionObject
_FindAndUnlinkFrame
__FrameUnwindFilter
_get_purecall_handler
_get_unexpected
__GetPlatformExceptionInfo
__intrinsic_setjmp
__intrinsic_setjmpex
_is_exception_typeof
_IsExceptionObjectToBeDestroyed
_local_unwind
__NLG_Dispatch2
__NLG_Return2
__processing_throw
_purecall
__report_gsfailure
__RTCastToVoid
__RTDynamicCast
__RTtypeid
_set_purecall_handler
_set_se_translator
set_unexpected
_SetWinRTOutOfMemoryExceptionCallback
__std_exception_copy
__std_exception_destroy
__std_terminate
__std_type_info_compare
__std_type_info_destroy_list
__std_type_info_hash
__std_type_info_name
__telemetry_main_invoke_trigger
__telemetry_main_return_trigger
__TypeMatch
__uncaught_exception
__uncaught_exceptions
__unDName
__unDNameEx
unexpected
__vcrt_GetModuleFileNameW
__vcrt_GetModuleHandleW
__vcrt_InitializeCriticalSectionEx
__vcrt_LoadLibraryExW
alexchandel commented 8 years ago

@retep998 Hah that's quite a good list. But OS X puts all of those in a DLL too. For example for the C++ exception stuff, /usr/lib/system/libunwind.dylib, which is linked behind-the-scenes by libSystem, is permanently stable, and contains similar OS X functions. Who knows how hard it is to keep it stable, but Apple does it. /usr/lib/libc++.dylib also has some exception things too. crt0.o/crt1.o have only a handful of symbols like EH_Frame1, ___keymgr_dwarf2_register_sections, func.eh, and the entry point.

Edit: But crt0.o/crt1.o are never even used on OS X. Since 10.7 it's been part of libSystem.dylib, which is dynamically linked, and executables compiled for 10.7+ simply rely on the (permanently stable) entry point in there. But even so, the fact that I can statically link against an old, pre-10.7 version of crt0.o with a different compiler and a different libSystem shows that it, too, is permanently stable.

There is simply no justifiable reason for what Microsoft did.

brson commented 8 years ago

@retep998 What's the state of this metabug? Looks a bit stale. Can remaining items be moved to rust-lang/rust as individual bugs?

brson commented 8 years ago

I went ahead and dropped the P-high tag since this bug is inactive.

retep998 commented 8 years ago

I do update the issue every so often. Feel free to point out anything you feel should be added or was completed and I'll update the list.

Diggsey commented 8 years ago

What's left to do re: the first wishlist item? :stuck_out_tongue_winking_eye:

retep998 commented 8 years ago

I'm not sure. I'll have to try debugging a Rust program and see how good the local variable info is.

briansmith commented 8 years ago

I'm not sure. I'll have to try debugging a Rust program and see how good the local variable info is.

I have noticed when debugging with MSVC's debugger, stepping into any line that uses try!(...) makes MSVC confused until you step again. It seems like it steps into the macro's code, but it does not nagivate the editor to the macro's code. Thus, debugging pretty much everything is a very confusing experience.

alexchandel commented 8 years ago

All of the "Remaining tasks" still appear unfinished, so presumably it's still active. Perhaps the metabug itself could be moved to rust-lang/rust.

alexchandel commented 8 years ago

@retep998 I've heard that the COM ABI is slightly different from the usual Win32 ABI, in ways that resulted in MSVC's C (not C++) compiler historically not being able to call it correctly. Is this true / does rustc need to do anything to support it?

retep998 commented 8 years ago

@alexchandel stdcall for C++ methods is slightly different than stdcall for regular functions. Since COM is based on C++ methods, that means that for some of those COM methods, the C equivalent is in fact incorrect. I already opened an issue for this https://github.com/rust-lang/rfcs/issues/1342 which is even listed in this meta issue.

liranringel commented 5 years ago

Could someone elaborate in what way the quality of PDB debug info should be improved?

gnzlbg commented 5 years ago

https://github.com/rust-lang/rfcs/issues/2625 covers __intrinsic_setjmp .

retep998 commented 4 years ago

This list has stagnated for a while, and I don't think this repo is really the right place for it anyway.

A new list will be maintained the Windows WG repo: https://github.com/rust-windows/wg/issues/3