A signature check is crashing the program about jfstmerge HOT 16 CLOSED

@guilhermejccavalcanti, você pode me passar a lista de repositórios que você minerou (ou se souber o repositório que causou o erro, é ainda melhor)?

from jfstmerge.

@pauloborba @guilhermejccavalcanti Encontrei o erro. Vou explicá-lo.

@GET
@Path("max/{campo}")
@Produces("application/json")
public String maxREST(@PathParam("campo") String campo, @Context UriInfo uriInfo) {
    return "{ \"max\": " + super.max(campo, uriInfo) + "}";
}

O projeto que minerei usa construções como acima.
Para pegar a assinatura do método, o programa busca o primeiro { (que demarcaria o início do corpo). Após isso, buscamos na assinatura o nome dele com o indexOf. Porém, o { é usado na 2ª linha.

from jfstmerge.

from jfstmerge.

por que é mesmo que você não pega a assinatura via a árvore criada pelo s3m?

Eu busco saber se o prefixo (modificadores, tipo de retorno) e o sufixo (argumentos) dos métodos a serem comparados são iguais. A assinatura na árvore só me dá o sufixo.

from jfstmerge.

from jfstmerge.

from jfstmerge.

from jfstmerge.

Ok, mudarei então. Já já lanço um PR.

from jfstmerge.

Bem, isso resolve o problema da assinatura. Mas quando buscamos por corpos iguais/similares, usamos a mesma estratégia. Uma alternativa segura é alterar a árvore de parsing para fornecer o corpo também, uma vez que buscar por símbolos ou palavras parece suscetível a erros como acima. Vocês sugerem algo?

from jfstmerge.

from jfstmerge.

(anotações, assinatura, corpo?)

Tem tudo isso em um atributo só (a declaração do método). A assinatura é a única fora. Seria interessante separar, até porque dá pra atacar o problema das anotações depois (a issue #42 fala sobre isso).

from jfstmerge.

from jfstmerge.

@pauloborba @guilhermejccavalcanti Ei, vocês não se confundiram ao dizer que a assinatura armazenada no nó da árvore contém o tipo de retorno, não? Ao meu ver, ele só duplica os argumentos mesmo.

(ignorem o "m" e "n1", são os mesmos métodos em diferentes contribuições)

from jfstmerge.

from jfstmerge.

Acho que é isso mesmo, @guilhermejccavalcanti.

from jfstmerge.

from jfstmerge.