-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Parse native moules names #222
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
I'm a bit torn on this. At very least you need to make the str an option.t[str] so we're not imbuing the empty string with extra meaning (native / non-native). In rustboot we initially had a whole parallel sub-AST for native modules and native items, then we backed off that and wound up just "marking" those modules and items that were native. But in practice this change wound up with a lot of implicit invariants that were non-obvious, because all the 'native-ness' was marked in a external tables and "coincidental" meanings like "functions in native modules happen to have empty body-blocks and happen to be translated completely differently". I think we might have done better with the split AST after all. Particularly given that modules are so very limited now. Part of the original motive for merging the native and non-native module handling in rustboot was that, at the time, we had no obj types, and modules were very rich in functionality: they were first-class types that you could pass around, and they supported existential types, and so there was just a ton of duplicated machinery handling the native and non-native versions. Now modules are relatively simple and I'm not sure the machinery-duplication would hurt as much as it would clarify. |
Btw. if you do keep a single AST with optional decorations (also possible), at least make a native_mod_info record type, and store an option.t[native_mod_info] so that future additions (ABI / calling convention) will not require adding more fields to mod. Likewise for native fns, add a single option.t[native_fn_info] for some helper record type native_fn_info. This might be enough to make matters explicit, and certainly will save some duplication. So if you want to take the quick way, do that. I'm really unsure whether the split-AST or optional-fields approach is better here. |
Obsolete with yesterday's changes (thanks!) |
Correct closures PR link
Address comments to previous PR
…xcrichton Fix DragonFly: clock_gettime() expects CLOCK_* constants as ulong. While there add all CLOCK_ constants as found on DragonFly.
…#223) * Adds extract_unchecked + replace_unchecked + len (rust-lang#222 ) * [x86] Fixes the return types + uses extract_unchecked for: * _mm_extract_epi8 * _mm_extract_epi16 * _mm256_extract_epi8 * _mm256_extract_epi16 * Minor changes to the other extract_epi* intrinsics for style consistency These should now zero-extend the extracted int and behave appropriately. An old typo makes these a bit confusing, See this llvm issue.
Write well-formedness checking chapter
Add support for global variable expressions in debug info
* Add vtable drop_in_place * Fix __VERIFIER_expect_fail
Let me know if you would like me to create a new item_native_mod or something.