Glossary

[mark-i-m]

Are there any other terms that should be added to the glossary? Please make suggestions.

• filemap (What are "filemaps"? #35)
• soundness (Add soundness and completeness to glossary #54)
• completeness (Add soundness and completeness to glossary #54)
• skolemization (rework and vastly expand the MIR section #67)
• sigil (Add a few more terms to the glossary #57)
• LTO, ThinLTO, FatLTO (Add some codegen related terminology to glossary #56)
• TLS (Add some codegen related terminology to glossary #56)
• LLVM (Add some codegen related terminology to glossary #56)
• IR (Add some codegen related terminology to glossary #56)
• Fat pointer (Add definitions of fat, double, and wide pointers #112)
• region (Add a few more terms to the glossary #57)
• HIR map (Add HIR MAP to glossary #63)
• CTFE (compile-time function evaluation)... This just needs a link to the const eval/miri sections (add a bunch of type-related terms to glossary (and few others) #152)
• rib (see name resolution chapter) (add a bunch of type-related terms to glossary (and few others) #152)
• upvar (I believe an "upvar" is just a variable captured by a closure) (add a bunch of type-related terms to glossary (and few others) #152)
• early-bound lifetime (Add various terms to the glossary #281)
• interned (Add various terms to the glossary #281)
• item (Add various terms to the glossary #281)
• late-bound lifetime (Add various terms to the glossary #281)
• lang item (Add various terms to the glossary #281)
• memoized (Add various terms to the glossary #281)
• string interning (Add various terms to the glossary #281)
• drop glue (Add various terms to the glossary #281)
• late-bound regions/lifetimes (Add various terms to the glossary #281)
• gensym
• landing pad
• skolemization leak

[phansch]

One thing I have been wondering is if 'soundness' means something special in the compiler context or if it is just a different word for correctness. There are lot's of issues mentioning 'soundness bugs' and 'soundness fixes'. So maybe it makes sense to add this too or explain it somewhere?

[mark-i-m]

Yes, soundness is a technical term in programming languages literature. You will usually read about proving "soundness" and "completeness".

Roughly, IIRC, soundness means that if a program type-checks, it is type-safe; i.e. I can never (in safe rust) force a value into a variable if the wrong type. Completeness means that every type-safe program also type-checks. Having both is very hard, and usually soundness is more important.

[samWson]

I've found a good definition of Fat Pointers in the Programming Rust book. I can enter that in the glossary this weekend if it's OK with you team.

[steveklabnik]

We've been using "double pointer" or "wide pointer" as well; might be worth considering as "double pointer" at least is significantly more descriptive, IMO.

[hanna-kruppe]

FWIW "double pointer" can also be read as "pointer-to-pointer" (and I've definitely seen it used in that sense in other languages). Besides, double becomes inaccurate with custom DSTs (which can add more data than just one word to the pointer). One precise and universal phrase is "pointer with metadata" but that's probably a bit too verbose.

[samWson]

"Pointer with metadata" is what I've found the definition of a fat pointer to be. A two word value with an address and some extra information needed to put the value to use.

[mark-i-m]

I think we could add all of these terms to the glossary.

[samWson]

Is this a case with of several phrases with the same meaning? Or are these the names of different things?

[mark-i-m]

I believe "fat pointer", "wide pointer", and "double pointer" are all intended to be synonyms.

[samWson]

I can enter this in the glossary as a single entry e.g.

Term	Meaning
Fat pointer, wide pointer, double pointer	"definition goes here"

Or I could make them separate entries, each referencing a single definition:

Term	Meaning
Fat pointer	Two word pointer with address and metadata
Wide pointer	see fat pointer
double pointer	see fat pointer

The second style makes it easier to find each individual term, as it keeps things in alphabetical order.

[Michael-F-Bryan]

@samWson I think the second option is best. "Fat pointer" is by far the most popular name for the concept of a pointer with some extra "metadata" attached, so if people want to lookup the term "wide pointer" we should redirect them to the canonical term.

[mark-i-m]

Perhaps we could also add that they are used for dyn Trait and slices?

[samWson]

@mark-i-m Of course. I'll put in a longer definition in the glossary. I only omitted it in my comment for brevity. I'll have a PR ready soon.

[samWson]

Just submitted pull request #112 . Let me know what you think.

[varkor]

"Rib" and "upvar" should probably be mentioned too.

[mark-i-m]

Yeah, upvar is one that has mystified me too...

[mark-i-m]

Is an upvar basically a variable that is captured by a closure?

[varkor]

DST and ZST might also be worth including.

[mark-i-m]

@varkor added in #152

[varkor]

It'd be good to explicitly define "item" too, as it's not immediately clear from the source exactly what things can be items.

And "early-bound lifetime" and "late-bound lifetime".

Edit: and "lang item".

[mark-i-m]

Thanks :)

@varkor would you mind opening a PR for that?

[alexreg]

It would be really nice to have a definition for "late-bound regions/lifetimes" in the glossary... I still have no bloody clue what these things are!

[mark-i-m]

Unfortunately, there is a lack of people who know definitions to things, so this list is just getting longer... Not sure what to do about that...

[alexreg]

I can probably help with some of these... though I wouldn't call myself an authority. Borrow checking is pretty arcane magic as far as I'm concerned. We might have to draft in @nikomatsakis for this. Even if he (or someone like him) could leave comments on this post, then someone could formalise the definitions and create a PR maybe. :-)

[varkor]

@alexreg: most of these definitions can be found with a little sleuthing. I think this post explains early- and late-bound lifetimes, for example.

[oli-obk]

There are also some (albeit not necessarily easy to decipher) explanations in the internals docs: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.RegionKind.html#bound-regions

[alexreg]

@varkor @oli-obk Thanks. I'm not very good at searching. There are too many "references" rather than "definitions", which makes grepping harder than it should be.

[alexreg]

@mark-i-m Can we add "gensym" to the list please? That's a weird term that I'm still not entirely sure what it means.

[mark-i-m]

Added "landing pad" to the list

[tshepang]

@alexreg did you refer to the (now removed) compiler flag ?

[alexreg]

@tshepang I think you meant to tag @mark-i-m?

[tshepang]

indeed I did

[tshepang]

@alexreg what about gensym... it did itself get removed.

[alexreg]

@tshepang Yep, good point. We can remove that from the list now.

[mark-i-m]

I think the concept of landing pads still exists... not 100% sure, but I think they are code emitted for unwinding.

[mark-i-m]

Closing this in favor of #707