@@ -75,9 +75,9 @@ internally. The result is the compiling `rustc` is done in stages.
75
75
For hacking, often building the stage 1 compiler is enough, but for
76
76
final testing and release, the stage 2 compiler is used.
77
77
78
- ` ./x.py check ` is really fast to build the rust compiler.
79
- It is, in particular, very useful when you're doing some kind of
80
- "type-based refactoring", like renaming a method, or changing the
78
+ ` ./x.py check ` is really fast to build the rust compiler.
79
+ It is, in particular, very useful when you're doing some kind of
80
+ "type-based refactoring", like renaming a method, or changing the
81
81
signature of some function.
82
82
83
83
Once you've created a config.toml, you are now ready to run
@@ -155,3 +155,21 @@ in other sections:
155
155
more details):
156
156
- ` ./x.py test --stage 1 src/libstd ` – runs the ` #[test] ` tests from libstd
157
157
- ` ./x.py test --stage 1 src/test/run-pass ` – runs the ` run-pass ` test suite
158
+
159
+ ### ctags
160
+
161
+ One of the challenges with rustc is that the RLS can't handle it, making code
162
+ navigation difficult. One solution is to use ` ctags ` . The following script can
163
+ be used to set it up: [ https://github.com/nikomatsakis/rust-etags ] [ etags ] .
164
+
165
+ CTAGS integrates into emacs and vim quite easily. The following can then be
166
+ used to build and generate tags:
167
+
168
+ ```
169
+ rust-ctags src/lib* && ./x.py build <something>
170
+ ```
171
+
172
+ This allows you to do "jump-to-def" with whatever functions were around when
173
+ you last built, which is ridiculously useful.
174
+
175
+ [ etags ] : https://github.com/nikomatsakis/rust-etags
0 commit comments