using relative paths allow testing the code of the compiler without building the compiler.
if we keep the require "compiler/crystal/**" the code that will be tested is the one in the compiler used to build the specs.

I would leave the require "../../.. ...." since it allows more unit test like of the compiler.

Checking in the code, I notice that it could be replaced with require "../../spec_helper" But maybe that could be handle in another PR and just leave this for enforcing the private methods/classes.

I'm pretty sure that's incorrect. The bin/crystal wrapper should edit the load path so that any part of the stdlib is loaded from the git repo, not the distribution. There's nothing special about the compiler requires.

@RX14 My comment applies when you do $ crystal spec spec/compiler/.../. i.e. no bin/crystal wrapper is called.

At least for a DRY about relative vs crystal path we should change this to require spec_helper. But again that is not about adding private to methods and classes.

@bcardiff as far as i'm concerned we shouldn't be supporting not using bin/crystal. All the specs for the stdlib use non-relative requires, so I don't see why the compiler should be special.

@bcardiff @RX14 I'll fix to use require "../../../spec_helper" instead of require "compiler/crystal/**" because other compiler's spec uses it. (And spec/spec_helper.cr requires compiler files with relative path. If you want to fix it, please open another pull request or issue.)

@RX14 you are probably right and things might be as they are because of evolution only and could be changed. There is no point in using bundled stdlib with compiler with current master code.