Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Niko Matsakis
    @nikomatsakis
    @bkchr anyway, my point is, that impl doesn't actually apply to Box<Error>, I don't thikn
    Bastian Köcher
    @bkchr
    You can search for the person
    Niko Matsakis
    @nikomatsakis
    you can also just click on their icon
    but I started a private chat with @mikeyhew
    Bastian Köcher
    @bkchr
    Okay, so we need a special implementation for Box<Error> and the termination trait
    Niko Matsakis
    @nikomatsakis
    @bkchr I suspect so, yeah
    Bastian Köcher
    @bkchr
    Anyone has an idea, how to check in libtest if the termination_trait is activated?
    Niko Matsakis
    @nikomatsakis
    @bkchr the feature gate you mean? I'm not sure if that's possible
    at least as things are setup now
    by libtest, you mean the "runtime" that backs unit tests, right?
    I haven't looked at this code in a while :/
    Bastian Köcher
    @bkchr
    libtest is the thing that runs the tests
    Niko Matsakis
    @nikomatsakis
    right
    probably we have to setup how it calls into libtest
    Bastian Köcher
    @bkchr
    libsyntax is backing the tests
    Niko Matsakis
    @nikomatsakis
    I guess I'm not sure precisely why libtest needs to know about the termination trait; I would think that the test itself reports success/failure, and it could capture the return value and deal with it
    i.e., during the code generation phase we could make a wrapper function or something if we have to
    Bastian Köcher
    @bkchr
    Yeah that is possible
    Niko Matsakis
    @nikomatsakis
    maybe that's not annoying though, as I said I've not looked at the code in a while
    like, years :)
    Bastian Köcher
    @bkchr
    I just thought, that we need to disable the stuff if the termination_trait feature is not enabled
    Niko Matsakis
    @nikomatsakis
    yes, but I would think that would happen in the compiler
    that is, during the type-checking and other phases
    Bastian Köcher
    @bkchr
    hmm okay
    Niko Matsakis
    @nikomatsakis
    that is, during the normal stability checks :)
    and/or we could have a check for #[test] functions that are not unit
    and gate that
    Bastian Köcher
    @bkchr
    in the compiler?
    that is done by libsyntax at the moment
    Niko Matsakis
    @nikomatsakis
    I consider that in the compiler :)
    point is, it would be not be done by the libtest runtime
    Bastian Köcher
    @bkchr
    okay
    any idea where that could be done in the compiler?
    Niko Matsakis
    @nikomatsakis
    I would think that libsytnax
    that is, the standard feature-gating place
    when we visit a fn, you could check if it is tagged with #[test]
    and then check its return type
    gimme a sec and I can point you at the code I mean
    Bastian Köcher
    @bkchr
    okay, it is already done in libsyntax
    @nikomatsakis bkchr/rust@e66a7de
    my work so far, but if I can check there for the termination_trait
    I will change that
    Niko Matsakis
    @nikomatsakis
    sounds right
    at least the right spot :)
    Bastian Köcher
    @bkchr
    But I don't know how to get the TyCtxt there to get active features.
    Niko Matsakis
    @nikomatsakis
    @bkchr hmm, I expect we can find the data in the ExtCtxt, but I don't know if it's in there now or not
    Bastian Köcher
    @bkchr
    @nikomatsakis I already found what I search :)
    Niko Matsakis
    @nikomatsakis
    @bkchr excellent
    Sebastian Malton
    @Nokel81
    So I can build my current version fine but when I try to run x.py test I get the following error:
    fatal: Could not write new index file.
    Stopping at 'src/tools/miri'; script returned non-zero status.
    failed to run: git submodule -q foreach git reset -q --hard
    Niko Matsakis
    @nikomatsakis
    @Nokel81 .... um :)