Skip to content

Commit 1afa907

Browse files
nagisanagisa
committed
Adjust keys make small tweaks to text
1 parent 68aa1d2 commit 1afa907

File tree

1 file changed

+52
-51
lines changed

1 file changed

+52
-51
lines changed

‎text/0000-target-bundles.md

Lines changed: 52 additions & 51 deletions
Original file line numberDiff line numberDiff line change
@@ -28,7 +28,7 @@ use-cases.
2828
We’ve observed a considerable amount of desire by users of the language to customize targets they
2929
use in the ways currently not supported by our current infrastructure (sans making changes to the
3030
compiler itself, of course), and noted that the current scheme is not very feasible in the long
31-
run. This RFC should go a great amount towards fixing the issues.
31+
run. This RFC should go a long way towards fixing the issues.
3232

3333
Then, there also is a strong need to be able to inspect arbitrary parts of target specification,
3434
regardless of their origin. For example, in a cross-compilation setting, when the crate uses a
@@ -94,13 +94,14 @@ while LLVM appears to use the highest supported version of Dwarf by default.
9494
* similarly for many other variables which tweak the way compilation is done.
9595

9696
¹: Technically, `target_pointer_width` is used in trans, but it does not provide any extra
97-
information over `data_layout`, which is what it should be using.
97+
information over `data_layout`, which is already used elsewhere in the compiler to calculate
98+
layout, sizing information and alignment of all types, including the pointers.
9899

99100
This would allow selectively reusing various conditional implementations that are present in the
100101
compiler for a custom target, when none of the `is_like_*` variables would fully suit the target.
101102
Moreover, being able to specify arbitrary cfg variables would allow easily adapting for various
102103
miniscule details related to the targets. For example, the targets for ARM CPUs with NEON support
103-
could export `target_has_neon` without any extra language support.
104+
could export `target_has_neon` without any extra language or compiler support.
104105

105106
That being said, it might make sense to have a whitelist of stable options and cfg variables and
106107
keep everything else unstable for some duration.
@@ -110,11 +111,11 @@ keep everything else unstable for some duration.
110111
```js
111112
{
112113
// REQUIRED
113-
"llvm-target": "x86_64-unknown-linux-gnu", // LLVM target triple (does not need to match with rustc triple)
114-
"data-layout": "e-m:e-i64:64-f80:128-n8:16:32:64-S128", // DataLayout for the target
114+
"llvm_target": "x86_64-unknown-linux-gnu", // LLVM target triple (does not need to match with rustc triple)
115+
"data_layout": "e-m:e-i64:64-f80:128-n8:16:32:64-S128", // DataLayout for the target
115116
"arch": "x86_64", // Architecture of the target
116117

117-
// OPTIONAL
118+
// OPTIONAL (should have sane defaults)
118119
// Configuration variables injected into the compilation units.
119120
"cfg": {
120121
"target_os": "linux",
@@ -131,64 +132,59 @@ keep everything else unstable for some duration.
131132
},
132133

133134
// Type of, and the linker used
134-
"linker-kind": "gnu", // previously linker_is_gnu: bool
135+
"linker_kind": "gnu", // previously linker_is_gnu: bool
136+
// possible values: "gnu", "msvc", "osx"
135137
"linker": "cc",
136138
"ar": "ar",
137-
"archive-format": "gnu",
138-
139-
// Various stuff adjusting how compilation is done
140-
"function-sections": true,
141-
"dynamic-linking": true,
142-
"disable-redzone": false,
143-
"obj-is-bitcode": false,
144-
"allow-asm": true,
145-
"allows-weak-linkage": true,
146-
"no-default-libraries": true,
147-
"custom-unwind-resume": false, // might make sense to merge into below
148-
"eh-method": "dwarf", // NEW: what EH method to use
149-
"dll-storage-attrs": false, // NEW: should use dll storage attrs?
150-
"debug-info": ["Dwarf", 4], // NEW: what debug info format
151-
"system-abi": "C", // NEW: what "system" ABI means
152-
"c-abi-kind": "cabi_x86_64", // NEW: what C-ABI implementation to use
153-
154-
// Various stuff adjusting how linkage is done
155-
"pre-link-args": ["-Wl,--as-needed", "-Wl,-z,noexecstack"],
156-
"post-link-args": [],
157-
"pre-link-objects-dll": [],
158-
"pre-link-objects-exe": [],
159-
"post-link-objects": [],
160-
"late-link-args": [],
161-
"gc-sections-args": [], // NEW: how to strip sections
162-
"rpath-prefix": "$ORIGIN", // CHANGED: to allow specifying rpath prefix, null to disable rpath altogether
163-
"no-compiler-rt": false,
164-
"metadata-section": ".note.rustc", // NEW: name of section for metadata
165-
"has-frameworks": false, // NEW: is concept of frameworks supported?
166-
"position-independent-executables": true, // should become a plain linker argument?
139+
"archive_format": "gnu",
140+
141+
"function_sections": true,
142+
"dynamic_linking": true,
143+
"disable_redzone": false,
144+
"obj_is_bitcode": false,
145+
"allow_asm": true,
146+
"allows_weak_linkage": true,
147+
"no_default_libraries": true,
148+
"custom_unwind_resume": false, // might make sense to merge into below
149+
"eh_method": "dwarf", // NEW: what EH method to use
150+
"dll_storage_attrs": false, // NEW: should use dll storage attrs?
151+
"debug_info": ["Dwarf", 4], // NEW: what debug info format
152+
"system_abi": "C", // NEW: what "system" ABI means
153+
"c_abi_kind": "cabi_x86_64", // NEW: what C_ABI implementation to use
154+
155+
"pre_link_args": ["_Wl,__as_needed", "_Wl,_z,noexecstack"],
156+
"post_link_args": [],
157+
"pre_link_objects_dll": [],
158+
"pre_link_objects_exe": [],
159+
"post_link_objects": [],
160+
"late_link_args": [],
161+
"gc_sections_args": [], // NEW: how to strip sections
162+
"rpath_prefix": "$ORIGIN", // CHANGED: to allow specifying rpath prefix, null to disable rpath altogether
163+
"no_compiler_rt": false,
164+
"metadata_section": ".note.rustc", // NEW: name of section for metadata
165+
"has_frameworks": false, // NEW: is concept of frameworks supported?
166+
"position_independent_executables": true, // should become a plain linker argument?
167167
"lib_allocation_crate": "alloc_system",
168168
"exe_allocation_crate": "alloc_jemalloc",
169-
// should become templates? `lib{}.so` is much nicer
169+
// should become a template? `lib{}.so` is much nicer
170170
"dll_prefix": "lib",
171171
"dll_suffix": ".so",
172172
"exe_suffix": "",
173173
"staticlib_prefix": "lib",
174174
"staticlib_suffix": ".a",
175175

176-
// LLVM options
177-
"cpu": "x86-64", // CPU of the target
176+
"cpu": "x86_64", // CPU of the target
178177
"features": "", // LLVM features
179178
"relocation_model": "pic",
180179
"code_model": "default",
181-
"eliminate-frame-pointer": true,
182-
183-
// Apparently OS X is so much of a special case that even moving all the special cases into
184-
// configuration is painful.
185-
is_like_osx: false,
186-
187-
// is_like_solaris is handled by the extra gc-sections key
188-
// is_like_msvc is handled by the extra metadata-section, linker-kind, eh-method,
189-
// dll-storage-attrs, debug-info keys
190-
// is_like_windows is handled by the extra system-abi and c-abi-kind keys
191-
// is_like_android is handled by the extra debug-info key
180+
"eliminate_frame_pointer": true,
181+
182+
// is_like_solaris is handled by the extra gc_sections_args key
183+
// is_like_msvc is handled by the extra metadata_section, linker_kind, eh_method,
184+
// dll_storage_attrs, debug_info keys
185+
// is_like_windows is handled by the extra system_abi and c_abi_kind keys
186+
// is_like_android is handled by the extra debug_info key
187+
// is_like_osx is handled by linker_kind: "osx", rpath_prefix, has_frameworks, c_abi_kind
192188
}
193189
```
194190

@@ -241,5 +237,10 @@ values, though.
241237
This RFC is still very viable without the proposed changes to JSON keys (the “target quirks and
242238
cfg” as well as the “proposed JSON key-values” sections).
243239

240+
Keep distributing all the built-in targets with the rustc package.
241+
242+
Since we’re already tweaking the structure of the target json spec, instead of allowing comments in
243+
JSON, just switch to TOML.
244+
244245
# Unresolved questions
245246
[unresolved]: #unresolved-questions

0 commit comments

Comments
 (0)