Skip to content

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

Closed
wants to merge 1 commit into from
Closed

Parse native moules names #222

wants to merge 1 commit into from

Conversation

espindola
Copy link

Let me know if you would like me to create a new item_native_mod or something.

@graydon
Copy link
Contributor

graydon commented Feb 1, 2011

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.

@graydon
Copy link
Contributor

graydon commented Feb 1, 2011

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.

@graydon
Copy link
Contributor

graydon commented Feb 2, 2011

Obsolete with yesterday's changes (thanks!)

arielb1 pushed a commit to arielb1/rust that referenced this pull request Apr 10, 2015
oli-obk added a commit to oli-obk/rust that referenced this pull request Jul 19, 2017
keeperofdakeys pushed a commit to keeperofdakeys/rust that referenced this pull request Dec 12, 2017
…xcrichton

Fix DragonFly: clock_gettime() expects CLOCK_* constants as ulong.

While there add all CLOCK_ constants as found on DragonFly.
kazcw pushed a commit to kazcw/rust that referenced this pull request Oct 23, 2018
…#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.
rchaser53 pushed a commit to rchaser53/rust that referenced this pull request Jan 19, 2019
Write well-formedness checking chapter
djtech-dev pushed a commit to djtech-dev/rust that referenced this pull request Dec 9, 2021
Add support for global variable expressions in debug info
celinval pushed a commit to celinval/rust-dev that referenced this pull request Jun 4, 2024
* Add vtable drop_in_place

* Fix __VERIFIER_expect_fail
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants